i-TegoDocumentationAuthentification > OpenID Connect OAuth Serveur dédié > Développer > OpenID Connect > Tests et certification

OAuthSD vers la Certification OpenID ®

  (publié initialement le jeudi 23 mai 2019) par i-Tego WM

OAuthSD a satisfait aux tests en vue de la certification OpenID.

L’auteur (B.D.) est membre de l’OpenID Foundation, ce qui lui permet d’introduire OAuthSD dans le processus de certification en vue d’obtenir le label "OpenID Certified".

 

Avril 2021 - Nouvelle série de tests

Les tests OIDF Conformance ont évolué, OAuthSD aussi, de nouveaux tests ont été effectués pour les flux OpenID Authorization Code et Implicit.

Tests de certification du flux Authorization Code (response_type ’code’)
Le résultat est visible à l’URL :
https://www.certification.openid.net/plan-detail.html?plan=5pu5MgJdbusGd&public=true

Commentaires :
- test "oidcc-unsigned-request-object-supported-correctly-or-rejected-as-unsupported" : EXPERIMENTAL : OAuthSD implémente le paramètre ’request’ sous sa forme JWT non signé et passé par valeur (comme l’attend ce test).
- test ’oidcc-claims-essential’ : Notre avis et qu’il s’agit là d’un écart inutile par rapport à la rigueur de la spécification générale, préjudiciable à la sécurité des données personnelles. OAuthSD n’implémente pas le paramètre ’claims’ ainsi que l’indique son document de découverte, le test devrait donc être sauté. Cependant, le test se traduit par un avertissement, ce qui n’est pas un obstacle à la certification.
- test "oidcc-refresh-token" : ce test est sauté car le client de test a été configuré sans le flux "refresh_token".

Test de certification du flux Implicit (response_type ’token’ et ’id_token token’)

Le résultat est visible à l’URL :
https://www.certification.openid.net/plan-detail.html?plan=7Z0tOWnMttGlm&public=true

Cette série appelle les mêmes commentaires que la précédente.

Mai 2019 - Configuration Basic OP : succès à 100% !

Cette configuration teste OAuthSD en tant que OP (OpenID Connect Provider) avec le flux Authorization Code.
Le résultat des tests peut être vu ci-dessous. On voit que OAuthSD remplit 100% des exigences (Il est normal que le test OP-redirect_uri-NotReg reste à l’état non complété) [1]

La certification OpenID peut être obtenue avec quelques tests à l’état "Warning". Notre engagement de qualité nous commande de satisfaire à 100% des tests.

Notes

[1Il est normal que le test OP-redirect_uri-NotReg reste à l’état non complété car "Ce test devrait avoir pour résultat que le fournisseur OpenID affiche un message d’erreur dans votre agent d’utilisateur. Vous devez ignorer le statut de ce test dans l’outil de test, car il sera incomplet."

Tester OAuthSD avec OIDC Debugger

  publié le par i-Tego WM

Une application cliente a été enregistrée sur ce serveur OAuthSD pour interagir avec https://oidcdebugger.com/ et tester le bon fonctionnement d’OAuthSD.

Lancez le debugger : https://oidcdebugger.com/

Remplissez le formulaire comme suit :

Notez la mention du scope sli. Que vous l’indiquiez ou non, le SLI ne fonctionnera pas car OpenID Connect debugger n’accepte pas les cookies. Voyez SLI, SSO, SLO et SRA sont dans un bateau : OAuthSD.

Entrez dans le champ State une chaîne quelconque.

Le champ Nonce n’est obligatoire que pour les "Response Type" "id_token" et"id_token token". Entrez une chaîne quelconque.

Sélectionnez une ou plusieures valeurs de "Response Type. Cette sélection détermine le type de flux d’autorisation (Grant Type) comme décrit ici : OpenID Connect et OAuth 2.0 : Synthèse des flux d’autorisation (Grant Type).

Actionnez "Send Request".

Entrez login = bebert password = 012345678
puis actionnez "Submit".

La réponse montre le bon fonctionnement d’OAuthSD :

Vous pouvez examiner l’interaction avec le serveur OAuthSD (avec les erreurs eventuelles) ici : https://oa.dnc.global/web/spip.php?page=evenements.

A propos des response type "id_token" et "token-id token"

Ces types de réponse correspondent à des flux implicites retournant directement les jetons. Le paramètre "nonce" doit être présent dans la requête.

Response type "token"

La librairie OAuth 2.0 Server PHP accepte response type = "token" sous la forme d’un flux OAuth 2.0 implicite retournant le jeton d’accès :


Notons la mention erronée à propos du type de réponse demandé.

A propos des response type "code id_token", "code token" et "code token id token"

Le serveur n’accepte que la demande de flux hybride "code id_token".
Ces types de réponse correspondent à des flux hybrides retournant directement le ou les jetons.

Une erreur est générée avec les demandes de réponse "code token" et "code token id token", cela est cohérent dans le cadre d’OpenID Connect :

Tester OAuthSD avec OpenID Connect Playground

  publié le par i-Tego WM

Cet article décrit comment utiliser OpenID Connect Playground pour tester le fonctionnement de OAuth Server by DnC pour le protocole OpenID Connect.

1. Créer un client pour le test :

Nota : S’il s’agit de tester le fonctionnement du présent serveur, le client mentionné dans la configuration est déjà créé, vous pouvez donc passer cette étape.

Aller à http://oa.dnc.global/?page=creer-client, créer un client comme suit :

2. Configurer le client :

Aller à l’URL https://openidconnect.net/,
- Cliquer sur le bouton CONFIGURATION pour faire apparaître le formulaire de configuration.
- Dans le champ "Server Template", sélectionner "Custom".
- Dans le champ "Discovery Document URL" indiquer : https://oa.dnc.global/.well-known/openid-configuration
- Actionner le bouton "USE DISCOVERY DOCUMENT". Les 3 champs suivants sont complétés automatiquement (c’est heureux car il y a un bug dans le playground empêchant l’inscription de ces champs).
- Compléter les 3 champs suivants avec les données de votre application. S’il s’agit de tester OAuthSD, indiquez "testrpc3", "thesecret" et "openid profile".

Le formulaire de configuration doit être rempli comme suit :

3. Lancer le Test :

- Actionner le bouton "SAVE".

Dans la fenêtre qui apparaît, entrez le login "bebert" et le password "012345678" :