OpenID Connect

OAuth 2.0 est-il un système d’authentification ?

L’authentification suppose que l’application protégée, qui reçoit une autorisation de délivrer les informations à l’application cliente, puisse identifier l’utilisateur final et l’application qui sont à l’origine de l’autorisation.
OAuth ne fournit pas cette identité et doit être complété pour assurer l’authentification.

OpenID Connect

OpenID Connect est une couche d’authentification construite sur OAuth 2.0. Le serveur d’autorisation (ou "fournisseur OpenID" dans ce cas, en anglais OpenID Provider ou OP) contient des informations sur une personne. OAuth est utilisé pour protéger ces informations, permettant à une application tierce (client) d’y accéder au nom de cette personne. Pour autoriser la diffusion d’informations, la personne est authentifiée et le Fournisseur OpenID fournit au client des détails notamment sur l’identité de la personne et le moment de l’authentification.

En plus du jeton d’accès, OpenID Connect met en oeuvre le jeton JWT (JSON Web Token) qui contient des informations sur l’utilisateur authentifié. Le jeton d’identification est signé par le serveur d’autorisation et peut être lu et vérifié sans accéder au serveur d’autorisation. C’est cette caractéristique qui doit conduire à choisir OpenID Connect, en réponse à la problématique de la Validation du jeton par une ressource protégée.

En outre, OpenID Connect standardise différentes choses que OAuth laisse au choix du développeur. Par exemple les scopes, la découverte des points d’extrémité et l’enregistrement dynamique des clients. Mais cela reste des options, le standard est ouvert.

Voyez également : OpenID Connect et OAuth 2.0 : Synthèse des flux d’autorisation (Grant Type).

Flux de code d’autorisation (spéc. : Authorisation code flow) - le flux le plus couramment utilisé, destiné aux applications Web traditionnelles ainsi qu’aux applications natives / mobiles (avec cependant des risques avec ces dernières ). Implique une redirection initiale du navigateur vers le serveur d’authentification pour l’authentification et le consentement de l’utilisateur, puis une seconde demande de l’application cliente pour récupérer le jeton d’ID.

Le diagramme de ce flux est identique à son homologue d’OAuth 2.0, la différence étant le jeton d’identification (ID Token) qui accompagne le jeton d’accès.

La signature de ce jeton offre aux serveurs de ressource protégée (RS) l’opportunité de valider le jeton localement, pourvu qu’une forme de clé leur soit connue.

Le flux de code d’autorisation offre une sécurité optimale, car :
 le secret de l’application, résidant sur le serveur [1], est protégé,
 les jetons ne sont pas révélés au navigateur (ne circulent que dans une liaison serveur-serveur),
 l’application cliente peut être authentifiée, tout comme l’utilisateur final,
 la signature du jeton lie de façon indissoluble : l’identité de l’utilisateur final, l’identité de l’application, la portée (scope) de l’autorisation.

La mise en œuvre de ce flux dans le cadre d’OAuthSD est détaillée ici : OpenID Connect : Autorisation via un code (Authorization Code Flow).

Flux implicite (spéc. : Implicit flow) - pour les applications basées sur un navigateur qui n’ont pas de backend, par exemple une application Javascript. Ce flux est également utilisé pour les applications à page unique (SinglePage Application, SPA). Le jeton d’identification est reçu directement avec la réponse de redirection de l’OP. Aucun appel au canal de retour n’est requis ici. De ce fait, le client ne peut être authentifié.

La mise en œuvre de ce flux dans le cadre d’OAuthSD est détaillée ici : Autorisation implicite.

Flux Hybride (spéc. : Hybrid Flow) - Essentiellement une combinaison du code et des flux implicites, rarement utilisé. On peut lire : "Permet à l’application front-end et back-end de recevoir des jetons séparément l’une de l’autre". Il semble plus sécurisé et tout aussi facile d’appliquer séparément un flux de code et un flux implicite.

Les flux Implicite et Hybride sont implémentés par OAuthSD mais leur usage est découragé car ils ne présentent pas les avantages de sécurité attachés à OpenID Connect :
 ils compromettent le secret de l’application qui est facilement accessible au public,
 ils exposent les jetons au navigateur de l’utilisateur final, ce qui rend possible une exploitation par un malware,
 ils ne permettent pas d’authentifier l’application cliente.

Notes :
 Les fonctionnalités d’OAuth 2.0 sont intégrées au protocole OpenID Connect. Toutes les fonctionnalités d’OAuth 2.0 et de OpenID Connect peuvent donc être atteintes par les Points d’extrémité d’OpenID Connect, en particulier les flux Client/User Credentials d’OAuth 2.0. Tous les flux sont résumés ici : OpenID Connect et OAuth 2.0 : Synthèse des flux d’autorisation (Grant Type).
 Le flux Hybrid n’est que partiellement implémentée par OAuthSD. Cette méthode est peu utilisée et peut être avantageusement remplacée par une successsion d’appels aux deux premières.

La spécification du jeton d’identité (ID_Token) pour OpenID Connect est donnée ici : OpenID Connect Core 1.0 incorporating errata set 1 :

2. Jeton d’identité

L’extension principale qu’OpenID Connect fait à OAuth 2.0 pour permettre aux utilisateurs finaux d’être authentifiés est la structure de données du jeton d’identité. Le jeton d’identité est un jeton de sécurité qui contient des déclarations concernant l’authentification d’un utilisateur final par un serveur d’autorisation lors de l’utilisation d’un client, et éventuellement d’autres déclarations demandées. Le jeton d’identité est représenté sous la forme d’un JSON Web Token (JWT) avec signature cryptographique (JWS).

Les déclarations suivantes sont utilisées dans le jeton ID pour tous les flux OAuth 2.0 utilisés par OpenID Connect :

iss
OBLIGATOIRE. Identifiant de l’émetteur pour l’émetteur de la réponse. La valeur iss est une URL sensible à la casse utilisant le schéma https qui contient des composants de schéma, d’hôte et, éventuellement, de numéro de port et de chemin d’accès et aucun composant de requête ou de fragment.
sub
OBLIGATOIRE. Identifiant du sujet. Un identifiant localement unique et jamais réaffecté au sein de l’émetteur pour l’utilisateur final, qui est destiné à être consommé par le client, par exemple, 24400320 ou AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4. Il NE DOIT PAS dépasser 255 caractères ASCII. La sous-valeur est une chaîne sensible à la casse.
aud
OBLIGATOIRE. Public (s) auquel ce jeton d’identité est destiné. Il DOIT contenir le client_id OAuth 2.0 de la partie utilisatrice comme valeur d’audience. Il PEUT également contenir des identifiants pour d’autres publics. Dans le cas général, la valeur aud est un tableau de chaînes sensibles à la casse. Dans le cas spécial courant où il n’y a qu’une audience, la valeur aud PEUT être une chaîne unique sensible à la casse.
exp
OBLIGATOIRE. Heure d’expiration à partir de laquelle le jeton d’identité NE DOIT PAS être accepté pour le traitement. Le traitement de ce paramètre nécessite que la date / heure actuelle DOIT être antérieure à la date / heure d’expiration répertoriée dans la valeur. Les implémenteurs PEUVENT prévoir une petite marge de manœuvre, généralement pas plus de quelques minutes, pour tenir compte du décalage d’horloge. Sa valeur est un nombre JSON représentant le nombre de secondes à partir de 1970-01-01T0 : 0 : 0Z mesuré en UTC jusqu’à la date / heure. Voir RFC 3339 [RFC3339] pour plus de détails concernant la date / heure en général et UTC en particulier.
iat
OBLIGATOIRE. Heure à laquelle le JWT a été émis. Sa valeur est un nombre JSON représentant le nombre de secondes à partir de 1970-01-01T0 : 0 : 0Z mesuré en UTC jusqu’à la date / heure.
auth_time
Heure à laquelle l’authentification de l’utilisateur final s’est produite. Sa valeur est un nombre JSON représentant le nombre de secondes à partir de 1970-01-01T0 : 0 : 0Z mesuré en UTC jusqu’à la date / heure. Lorsqu’une demande max_age est effectuée ou lorsque auth_time est demandé en tant que revendication essentielle, cette revendication est OBLIGATOIRE ; sinon, son inclusion est FACULTATIVE. (La revendication auth_time correspond sémantiquement au paramètre de réponse auth_time OpenID 2.0 PAPE [OpenID.PAPE].)
nonce
Valeur de chaîne utilisée pour associer une session client à un jeton d’identité et pour atténuer les attaques de relecture. La valeur est transmise sans modification de la demande d’authentification au jeton ID. S’il est présent dans le jeton d’identité, les clients DOIVENT vérifier que la valeur de réclamation nonce est égale à la valeur du paramètre nonce envoyé dans la demande d’authentification. S’ils sont présents dans la demande d’authentification, les serveurs d’autorisation DOIVENT inclure une réclamation nonce dans le jeton d’identité, la valeur de réclamation étant la valeur nonce envoyée dans la demande d’authentification. Les serveurs d’autorisation NE DEVRAIENT effectuer aucun autre traitement sur les valeurs nonce utilisées. La valeur nonce est une chaîne sensible à la casse.
acr
FACULTATIF. Référence de classe de contexte d’authentification. Chaîne spécifiant une valeur de référence de classe de contexte d’authentification qui identifie la classe de contexte d’authentification satisfaite par l’authentification. La valeur "0" indique que l’authentification de l’utilisateur final ne répond pas aux exigences du niveau 1. ISO / IEC 29115 [ISO29115]. L’authentification à l’aide d’un cookie de navigateur de longue durée, par exemple, est un exemple où l’utilisation du "niveau 0" est approprié. Les authentifications de niveau 0 NE DEVRAIENT PAS être utilisées pour autoriser l’accès à toute ressource de quelque valeur monétaire que ce soit. (Cela correspond au PAPIER OpenID 2.0 [OpenID.PAPE] nist_auth_level 0.) Un URI absolu ou un nom enregistré RFC 6711 [RFC6711] DEVRAIT être utilisé comme valeur acr ; les noms enregistrés NE DOIVENT PAS être utilisés avec une signification différente de celle qui est enregistrée. Les parties utilisant cette allégation devront s’entendre sur la signification des valeurs utilisées, qui peuvent être spécifiques au contexte. La valeur acr est une chaîne sensible à la casse.
amr
FACULTATIF. Références aux méthodes d’authentification. Tableau JSON de chaînes qui sont des identifiants pour les méthodes d’authentification utilisées dans l’authentification. Par exemple, des valeurs peuvent indiquer que des méthodes d’authentification par mot de passe et OTP ont été utilisées. La définition de valeurs particulières à utiliser dans la revendication amr dépasse le cadre de cette spécification. Les parties utilisant cette allégation devront s’entendre sur la signification des valeurs utilisées, qui peuvent être spécifiques au contexte. La valeur amr est un tableau de chaînes sensibles à la casse.
azp
FACULTATIF. Partie autorisée - la partie à laquelle le jeton d’identité a été délivré. S’il est présent, il DOIT contenir l’ID client OAuth 2.0 de cette partie. Cette déclaration n’est nécessaire que lorsque le jeton d’identification a une seule valeur d’audience et que cette audience est différente de la partie autorisée. Il PEUT être inclus même lorsque la partie autorisée est la même que le seul public. La valeur azp est une chaîne sensible à la casse contenant une valeur StringOrURI.

Les jetons d’identification PEUVENT contenir d’autres déclarations. Toute déclaration utilisée qui n’est pas comprise DOIT être ignorée. Voir les sections 3.1.3.6, 3.3.2.11, 5.1 et 7.4 pour les déclarations supplémentaires définies par cette spécification.

Les jetons d’identification DOIVENT être signés à l’aide de JWS [JWS] et éventuellement signés puis chiffrés à l’aide de JWS [JWS] et JWE [JWE] respectivement, fournissant ainsi l’authentification, l’intégrité, la non-répudiation et, éventuellement, la confidentialité, conformément à la section 16.14. Si le jeton d’identification est chiffré, il DOIT être signé puis chiffré, le résultat étant un JWT imbriqué, comme défini dans JWT.

Les jetons d’identification NE DOIVENT PAS utiliser ’none’ comme valeur alg, sauf si le type de réponse utilisé ne renvoie aucun jeton d’identification du point de terminaison d’autorisation (comme lors de l’utilisation du flux de code d’autorisation) et si le client a explicitement demandé l’utilisation de ’none’ au moment de l’enregistrement.

Les jetons d’identification NE DEVRAIENT PAS utiliser dans le champ d’entête les paramètres JWS ou JWE x5u, x5c, jku ou jwk. Au lieu de cela, les références aux clés utilisées sont communiquées à l’avance à l’aide des paramètres de découverte et d’enregistrement, conformément à la section 10.

Voici un exemple non normatif de l’ensemble de revendications (l’ensemble de déclarations JWT) dans un jeton d’identification :

{
  "iss": "https://server.example.com",
  "sub": "24400320",
  "aud": "s6BhdRkqt3",
  "nonce": "n-0S6_WzA2Mj",
  "exp": 1311281970,
  "iat": 1311280970,
  "auth_time": 1311280969,
  "acr": "urn:mace:incommon:iap:silver"
 }

Audience

Cette déclaration est interprétée différemment selon les OpenID Connect Provider (OP).

Rappelons que le jeton d’identité (ID Token) est un "jeton au porteur" (Bearer Token).
La plupart des systèmes utilisent donc la déclaration ’audience’ pour définir les applications qui peuvent légitimement présenter le jeton sous la forme :

Il faut observer que les ressources protégées qui présentent le jeton à l’introspection peuvent également être mentionnées dans la liste des applications autorisées.

On voit que la déclaration audience appartient à ces définitions propres à un domaine particulier, dans lequel les applications et le serveur OpenID Connect Provider (OP) partagent la même interprétation.

C’est bien dans ce cas que se trouve OAuthSD qui est conçu et distribué comme OP privé.

Problématique

Le jeton d’identité, de type JWT signé (JWS), doit être validé dans deux situations :

 Dès sa réception, conformément à ce qui est défini dans la spécification d’OpenID Connect [1].

 Pour autoriser l’accès à une ressource protégée. Voyez comment le problème se pose de façon générale : Validation du jeton par une ressource protégée.
Deux cas se présentent :
 soit on passe la clé publique au serveur de ressource protégée RS qui procède localement à sa validation ; si ce RS n’est pas lié à l’organisation qui contrôle le serveur d’authentification, il peut utiliser la fonction API OpenID Connect : Découverte,
 soit on utilise une méthode dite "introspection" consistant à demander l’authentification du jeton JWT au serveur d’authentification qui l’a délivré : API Open ID Connect : Introspection (Introspection Endpoint) .

Procédure pour la Validation et la Consommation du jeton JWT signé (JWS)

La validation d’un jeton d’identité nécessite plusieurs étapes. Que le jeton soit validé du côté du serveur d’authentification ou à distance, la méthode est la même.

Le décodage et la validation du jeton suivent la méthode définie ici : Spécification OpenID Connect : Validation du jeton d’identité :

Les clients DOIVENT valider le jeton ID dans la réponse au jeton de la manière suivante :

 Si le jeton d’identification est chiffré, déchiffrez-le à l’aide des clés et des algorithmes spécifiés lors de l’enregistrement par le client, que l’OP devait utiliser pour chiffrer le jeton d’identification. Si le chiffrement a été négocié avec l’OP au moment de l’enregistrement et que le jeton d’identification n’est pas chiffré, le RP [2] DEVRAIT le rejeter.
 L’identifiant de l’émetteur pour le fournisseur OpenID (qui est généralement obtenu lors de la découverte) DOIT correspondre exactement à la valeur de la déclaration iss (issuer).
 Le client DOIT valider que la déclaration aud (audience) contienne la valeur client_id enregistrée auprès de l’émetteur identifié par la déclaration iss (émetteur) en tant qu’audience. La déclaration aud (audience) PEUT contenir un tableau avec plus d’un élément. Le jeton ID DOIT être rejeté si le jeton ID ne répertorie pas le client en tant qu’audience valide, ou s’il contient des audiences supplémentaires non approuvées par le client.
 Si le jeton d’identification contient plusieurs audiences, le client DEVRAIT vérifier qu’une déclaration azp est présente.
 Si une déclaration azp (partie autorisée) est présente, le client DEVRAIT vérifier que son client_id est la valeur de la déclaration.
 Si le jeton ID est reçu via une communication directe entre le client et le point d’extrémité du jeton (qui se trouve dans ce flux), la validation TLS du serveur PEUT être utilisée pour valider l’émetteur au lieu de vérifier la signature du jeton [3]. Le client DOIT valider la signature de tous les autres jetons ID conformément à JWS [JWS] en utilisant l’algorithme spécifié dans le paramètre d’en-tête JWT alg. Le client DOIT utiliser les clés fournies par l’émetteur.
 La valeur alg DEVRAIT être la valeur par défaut de RS256 ou l’algorithme envoyé par le client dans le paramètre id_token_signed_response_alg lors de l’enregistrement.
 Si le paramètre d’en-tête JWT alg utilise un algorithme basé sur MAC, tel que HS256, HS384 ou HS512, les octets de la représentation UTF-8 du secret client correspondant à l’identifiant client contenu dans la déclaration aud (audience) sont utilisés comme clé de validation de la signature. Pour les algorithmes basés sur MAC, le comportement n’est pas spécifié si l’aud est multivalué ou si une valeur azp est différente de la valeur aud.
 L’heure actuelle DOIT être antérieure à l’heure représentée par la déclaration exp.
 La déclaration Iat peut être utilisé pour rejeter des jetons qui ont été émis trop loin de l’heure actuelle, limitant ainsi la durée de stockage des clés pour prévenir les attaques. La plage acceptable est spécifique au client.
 Si une valeur nonce a été envoyée dans la demande d’authentification, une déclaration de nonce DOIT être présente et sa valeur vérifiée pour contrôler qu’il s’agit de la même valeur que celle qui a été envoyée dans la demande d’authentification. Le client DEVRAIT vérifier la valeur de nonce pour les attaques par relecture. La méthode précise pour détecter les attaques par relecture est spécifique au client.
 Si la déclaration acr a été mentionnée, le client DEVRAIT vérifier que la valeur de réclamation revendiquée est appropriée. La signification et le traitement des déclarations acr sont hors du domaine d’application de la présente spécification.
 Si la déclaration auth_time a été mentionnée, par le biais d’une demande spécifique pour cette déclaration ou du paramètre max_age, le client DEVRAIT vérifier la valeur de la déclaration auth_time et demander une nouvelle authentification s’il détermine qu’il s’est écoulé trop de temps depuis la dernière authentification de l’utilisateur final.

Exemple de code pour la vérification locale de la signature du jeton d’identité JWT signé (JWS)

La plupart de ces vérifications ne nécessitent qu’une simple comparaison de chaînes. La validation de la signature est plus complexe. L’implémentation qui en est faite par OAuthSD est décrite maintenant. La fonction suivante, tirée de OAuth 2.0 Server PHP, sépare les composantes du jeton, détecte les erreurs de format, vérifie éventuellement la signature et retourne la charge utile ou false en cas d’erreur.

La variable $key passe la clé publique qui a servi à générer le jeton JWT.

Si $key = null, la vérification de la signature n’est pas effectuée (on suppose le jeton déjà validé par introspection), et le contenu de la charge utile est retourné sous la forme d’un tableau associatif.

PHP

Avertissement à propos du paramètre ’alg’

La spécification prévoit d’appliquer la valeur du paramètre ’alg’ pour le choix de l’algorithme de validation de la signature : RFC 7515, section 4.1.1. : "... This Header Parameter MUST be present and MUST be understood and processed by implementations ...".

C’est une faille de sécurité, et donc une erreur de la spécification. OAuthSD applique la méthode définie pour chaque application, quelle que soit la valeur de alg. Il est intéressant de constater que OAuthSD passe les tests de validation de l’OIDF comme cela.

En savoir plus sur la validation du JWT :

 API Open ID Connect : Introspection (Introspection Endpoint)
 API OpenId Connect : Point d’extrémité d’informations sur les clefs (Keys Endpoint)
 OpenID Connect : Exemples complets du flux d’Autorisation via un code puis requête UserInfo

Voyez également :
 Validation du jeton d’accès avec la déclaration at_hash du jeton d’identité.

Notons que la validation du jeton ne suffit pas au serveur de ressource pour s’assurer que l’application qui présente le jeton le détient légitimement et éviter de répondre à une application étrangère. Voir à ce sujet :
 Vérification de l’origine de la requête reçue par un serveur de ressource.

Ceci suppose que le développeur ou son organisation soit inscrit sur le serveur en tant qu’Auteur et Administrateur d’applications.

Le processus comporte deux aspects :

 du côté du serveur OAuth, inscrire l’application,
 du côté de l’application cliente, insérer le code nécessaire pour assurer le lien avec le serveur OAuth.

1. S’inscrire en tant qu’Auteur et Administrateur d’applications

L’inscription se fait ici : Formulaire d’inscription en tant qu’auteur et administrateur d’applications.

Renseignez soigneusement votre fiche d’Administrateur d’applications, la plupart de ces informations étant communiquées aux utilisateurs finaux dont vous devez gagner la confiance.

Attention : ne confondez pas l’inscription en tant qu’Administrateur d’applications (un développeur qui inscrit son application cliente pour qu’elle puisse déléguer l’authentification à OAuthSD) avec l’inscription d’un internaute en tant qu’utilisateur final des applications clientes, qui se fait ici : Je m’inscris.

Notes :
 Le terme "Administrateur d’applications" permet de distinguer le développeur ou le propriétaire d’une application cliente qui s’inscrit sur ce serveur, de l’utilisateur final, qui doit aussi s’inscrire, mais autrement. Dans le modèle de données sous-jacent, il s’agit également de l’objet éditorial de SPIP (la table auteurs), tandis que l’utilisateur final correspond à une table distincte.

2. Inscrire l’application cliente sur le serveur OAuthSD

Dans la rubrique Gérer, aller à Ajouter (Inscrire) une application cliente et remplir le formulaire :

 Client Id (obligatoire) : Chaine identifiant l’application de façon unique. Entrez un nom court, sans espace ni caractère spécial autre que ’_’. Cet identifiant doit être unique pour tous les administrateurs d’applications inscrits sur le serveur. Il est visible du public et doit donc être représentatif de l’application et de votre entreprise.

 Client secret (obligatoire) : une courte chaîne assimilable à un mot de passe fort. Ce code doit rester secret. Il doit être fourni par l’application cliente lors de la demande de jeton.

 Redirect uri (obligatoire) : URI de retour à l’application cliente. C’est l’adresse à laquelle le serveur OAuth fait retour sur le client avec le résultat de l’authentification. OpenID Connect permet d’inscrire plusieurs URI de retour, cependant cette fonctionnalité n’a pas été testée dans l’état actuel du développement.

 Grant Type (obligatoire) : Sauf cas particulier, sélectionnez au moins "Authorization Code". Pour les flux Hybrid, sélectionnez "Authorization Code" et "Implicit". Voyez OpenID Connect et OAuth 2.0 : Synthèse des flux d’autorisation (Grant Type).

 Scopes (obligatoire) : Liste des Scopes autorisés pour l’application, séparés par un espace. Le scope ’openid’ est obligatoire. Les scopes standard de OpenID Connect sont : profile, email, address, phone. Voyez la rubrique : Réponse UserInfo. Le scope ’offline_access’ sert à obtenir un jeton de rafraîchissement. En plus de ces scopes, des scopes particuliers peuvent être définis pour une application donnée. Exemple : "openid profile email administrateur".

 User id Si un nom d’utilisateur (username) est inscrit ici, seul cet utilisateur pourra se connecter, cet identifiant étant figé dans le formulaire d’authentification. Dans le cas général ce champ sera vide.

Vérifiez vos entrées et actionnez le bouton "Enregistrer".

Enfin, naviguez à l’adresse https://oa.dnc.global/keys afin de créer l’entrée correspondant à la nouvelle paire de clés publique/privée.

Vous pourrez retrouver l’application et la modifier à la rubrique Toutes vos applications clientes.

Notes :
 OAuthSD crée pour l’application cliente une paire de clés publique/privée. Si vous souhaitez la changer, allez à la rubrique Toutes vos applications clientes et sélectionnez l’action "clés" correspondant à l’application.

3. Insérer dans l’application le code nécessaire

Bien que OpenID Connect soit construit sur OAuth 2.0, il ne faut pas s’attendre à réutiliser le code écrit pour ce protocole. En effet, OpenID Connect est une couche d’abstraction de niveau supérieur, impliquant des échanges et des points d’extrémité différents, ce qui nécessite que le code soit réécrit.

Si l’application cliente est conçue pour déléguer ses authentifications à un serveur à la norme OpenID Connect, il n’y a rien de plus à faire. En effet, OAuthSD est 100% compatible OIDC ; les fonctionnalités supplémentaires sont apportées de façon transparente.

Si l’applicatif sur lequel est construit l’application cliente propose un plugin OpenID Connect, il suffira de l’installer. Nous proposons quelques plugins ici : Adaptation des applications.

Sinon, c’est une affaire de développeur. Il y a deux adaptations à réaliser :

 Écrire le code situé au Point d’extrémité de redirection, ou URI de retour à l’application cliente (Redirection Endpoint). Il s’agit de demander au serveur OAuthSD un jeton d’accès et un jeton d’identification pour l’application, à partir du Code d’autorisation (Authorization code) retourné par le serveur.

 Écrire la procédure d’authentification adaptée à la technique de l’application cliente. Généralement, ce sera un module d’authentification supplémentaire, ou une ré-écriture du code d’authentification. Voyez : Plugin OpenID Connect Client pour SPIP, Extension OpenID Connect pour phpBB, Extension pour Wordpress "OpenID Connect Generic Client".

De façon optionnelle, on pourra également :
 Afficher l’état de la session OIDC et la gérer (Monitoring).

Consommer une API protégée de type HTTP REST : Un cas simple

Consommer une API protégée de type HTTP REST est extrêmement simple. Voici un exemple élémentaire, juste pour tester le fonctionnement, combinant en un seul script l’authentification de l’utilisateur final et la consommation de UserInfo :

PHP

Exécuter le script : https://oa.dnc.global/oidc/tests/te...

Sur le serveur OAuthSD, vous pouvez vous identifier avec login = bebert et password = 012345678

Une version rigoureuse et donc plus complète est donnée ici : OpenID Connect : Exemples complets du flux d’Autorisation via un code puis requête UserInfo.