Utilisation d'OpenID Connect pour étendre OAuth 2.0

Un jeton d'identité est un jeton autonome sécurisé par l'intégrité (au format JWT (JSON Web Token)) défini dans la norme OpenID Connect contenant des réclamations concernant l'utilisateur final. Le jeton d'identité est l'extension principale qu'OpenID Connect applique à OAuth 2.0 pour activer l'authentification dans un domaine d'identité.

Le jeton d'identité JWT se compose de trois composants, un en-tête, une charge utile et la signature numérique. Conformément à la norme JWT, ces trois sections sont encodées Base64URL et séparées par des points.

OpenID Connect 1.0 est une couche d'identité simple au-dessus du protocole OAuth 2.0. Elle permet à une application client de domaine d'identité IAM (enregistrée en tant que client OAuth 2 avec un ID client et une clé secrète client) de vérifier l'identité de l'utilisateur final en fonction de l'authentification effectuée par un serveur d'autorisation (AS), et d'obtenir des informations de profil de base sur l'utilisateur final de manière interopérable et de type REST. OpenID Connect permet aux clients de tous types, y compris les clients Web, mobiles et JavaScript, de demander et de recevoir des informations sur les sessions authentifiées et les utilisateurs finaux. Pour plus d'informations, reportez-vous à OpenID Connect.

Pourquoi valider les jetons ? Lorsque votre application Web vérifie les informations d'identification directement, elle vérifie que le nom utilisateur et le mot de passe présentés correspondent à ce que vous gérez. Lors de l'utilisation de l'identité basée sur les réclamations, vous confiez ce travail à un fournisseur d'identités.

La responsabilité passe de la vérification des informations d'identification brutes à la vérification que le demandeur a passé par votre fournisseur d'identités préféré et s'est authentifié avec succès. Le fournisseur d'identités représente une authentification réussie en émettant un jeton. Avant de pouvoir utiliser les informations ou d'en faire une assertion que l'utilisateur s'est authentifié, vous devez les valider.

OpenID Document de repérage

Le protocole OpenID Connect 1.0 est une couche d'identité simple au-dessus du protocole OAuth 2.0 qui nécessite l'utilisation de plusieurs adresses pour authentifier les utilisateurs et pour demander des ressources incluant des informations utilisateur, des jetons et des clés publiques. Pour vous aider à repérer les adresses que vous devez utiliser, OpenID Connect vous permet d'utiliser un document de découverte, qui est un document JSON trouvé à un emplacement bien connu. Ce document de repérage contient des paires clé/valeur qui fournissent des détails sur la configuration du fournisseur OpenID Connect, y compris les URI des adresses d'autorisation, de jeton, d'informations utilisateur et de clés publiques. Vous pouvez extraire le document de repérage pour le service OpenID Connect du domaine d'identité IAM à l'adresse suivante : https://<domainURL>/.well-known/openid-configuration.

L'adresse UserInfo OpenID Connect est utilisée par une application pour extraire des informations de profil sur l'identité qui s'est authentifiée. Les applications peuvent utiliser cette adresse pour extraire des informations de profil, des préférences et d'autres informations propres à l'utilisateur.

Le profil OpenID Connect comprend deux composants :

• Déclarations décrivant l'utilisateur

• Adresse UserInfo fournissant un mécanisme pour extraire ces demandes

  Remarque
  
  Les réclamations utilisateur peuvent également être présentées dans le jeton d'ID pour éliminer un rappel lors de l'authentification.

Profil utilisateur - Déclarations

L'adresse UserInfo fournit un ensemble de demandes en fonction des portées OAuth2 présentées dans la demande d'authentification. OpenID Connect définit cinq valeurs de portée qui correspondent à un ensemble spécifique de déclarations par défaut :

Le client doit présenter ses informations d'identification et un jeton d'accès. Le jeton d'accès présenté doit contenir la portée openid.

Si une portée est omise (par exemple, la portée email n'est pas utilisée), la demande (email) ne sera pas présente dans les demandes renvoyées.

Exemple de demande d'adresse UserInfo

Une fois que l'application client a authentifié un utilisateur et dispose du jeton d'accès, le client peut demander à l'adresse UserInfo d'extraire les attributs demandés sur un utilisateur. L'exemple suivant présente un exemple de demande.

   curl -i
   -H 'Content-Type: application/x-www-form-urlencoded'
   -H 'Authorization: Bearer eyJ4NXQjUzI1....rtApFw'-H 'Accept: */*'
   -H 'Content_Language: en-US'--request GET https://<domainURL>/oauth2/v1/userinfo

Exemple de réponse

Une réponse réussie renvoie une réponse HTTP 200 OK et les déclarations de l'utilisateur au format JSON :

{
"birthdate":"",
"email":"user@example.com",
"email_verified":false,
"family_name":"user",
"gender":"",
"given_name":"user",
"appRoles":[],
"name":"alice alice",
"preferred_username":"user@example.com",
"sub":"user@example.com",
"updated_at":1495136783,"website":""
}

Pour que l'application client puisse faire confiance aux valeurs renvoyées par l'adresse UserInfo (par exemple, en tant que vérification de l'attaque de substitution de jeton), le client doit vérifier que la demande sub renvoyée par la demande d'adresse UserInfo correspond à l'objet du jeton d'ID.

Utilisez le flux Code d'autorisation lorsque vous avez des clients qui peuvent maintenir en toute sécurité une clé secrète client entre eux et le serveur d'autorisation. Le flux de code d'autorisation renvoie un code d'autorisation au client, qui peut ensuite échanger le code contre un jeton d'ID et un jeton d'accès directement.

Cela vous permet de ne pas exposer de jetons à l'agent utilisateur (tel qu'un navigateur Web) et éventuellement à d'autres applications malveillantes ayant accès à l'agent utilisateur. Le serveur d'autorisation peut également authentifier le client avant d'échanger le code d'autorisation contre un jeton d'accès. Le flux Code d'autorisation fonctionne à la fois avec les clients confidentiels et les clients publics.

Clients confidentiels

Clients publics

Les clients publics ne disposent pas d'informations d'identification, mais d'un identificateur client. Le flux de code d'autorisation comporte deux étapes. Les demandes impliquent une demande GET basée sur un navigateur, puis une demande POST de canal arrière pour obtenir le jeton d'accès.

1. Demandez le code d'autorisation.

   Exemple de demande

   GET https://<domainURL>/oauth2/v1/authorize?client_id=<client-id>&response_type=code&redirect_uri=<client-redirect-uri>&scope=openid&nonce=<nonce-value>&state=1234

   Exemple de réponse

   Remarque
   
   Ces exemples de demande et de réponse sont similaires à ceux du client confidentiel et aux réponses abordées précédemment.

   https://<domainURL>/?code=AQIDBAXv9lZQ....F9NCA=

2. Demandez le jeton.

   Exemple de demande

   Remarque
   
   Cette demande est différente de la demande Client confidentiel dans laquelle l'ID client et la clé secrète client sont spécifiés dans l'en-tête Authentification de base. Dans le flux client public, il n'y a pas d'en-tête d'authentification de base. L'ID client est spécifié dans la charge utile de la demande.

      curl -i
      -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8'   
      --request POST https://<domainURL>/oauth2/v1/token 
      -d 'grant_type=authorization_code&code=<authz-code>&reidrect_uri=<client-redirect-uri>&client_id=<client-id>'

   Exemple de réponse

   {
   "access_token":"eyJ4NXQjUzI1???.xhtnbw",
   "token_type":"Bearer",
   "expires_in":27261,
   "id_token":"eyJ4NXQjUzI1???.._XLqUw"
   }
   

Utilisez le flux implicite lorsque vous avez implémenté un client basé sur un navigateur à l'aide d'un langage de script tel que JavaScript. Le jeton d'accès et le jeton d'ID sont renvoyés directement au client, ce qui peut exposer ces jetons à l'utilisateur et aux applications qui ont accès à l'agent utilisateur de l'utilisateur (par exemple, un navigateur Web).

Les valeurs response_type suivantes sont prises en charge avec le flux implicite :

Obtention d'un jeton d'ID

Obtention d'un jeton d'accès

Le flux implicite comporte trois étapes pour obtenir un jeton d'accès :

1. Demandez le jeton d'accès.

   Exemple de demande

   https://<domainURL>/oauth2/v1/authorize?client_id=<client_id>&response_type=token&redirect_uri=<client_redirect_uri>&scope=address+openid+profile

2. L'utilisateur se connecte et donne son consentement (en fonction des portées demandées).

3. Réponse avec jeton d'accès

   Exemple de réponse

   Remarque
   
   Tous les paramètres de réponse sont ajoutés au composant de fragment de l'URI de redirection.

   https://<domainURL>/#access_token=eyJ4NXQjUzI1...4WGvJQ&token_type=Bearer&expires_in=3600

Obtention d'un jeton d'ID et d'un jeton d'accès

Utilisez le flux hybride lorsque vous souhaitez obtenir des jetons séparément du canal avant et du canal arrière. Par exemple, vous disposez d'un composant de navigateur tel que JavaScript et d'un composant de serveur back-end tel que Node.js. Le composant de navigateur obtient le code d'autorisation et le jeton d'ID, puis peut personnaliser le contenu de l'interface utilisateur. Le composant back-end obtient le jeton d'accès pour effectuer des appels d'API métier.

Les clients doivent prendre en charge à la fois les demandes et les réponses basées sur un navigateur et les demandes et réponses programmatiques/back-canal pour utiliser le flux hybride. Le flux hybride fonctionne à la fois avec les clients confidentiels et les clients publics. Les valeurs response_type suivantes sont prises en charge avec le flux hybride :

Obtention d'un jeton d'ID

Obtention d'un jeton d'accès

Le flux hybride comporte quatre étapes pour obtenir le code d'autorisation et le jeton d'accès :

1. Demandez le code d'autorisation et le jeton d'accès.

   Exemple de demande

   https://<domainURL>/oauth2/v1/authorize?client_id=<client_id>&response_type=code token&redirect_uri=<client_redirect_uri>&scope=http://<domainURL>/test

2. L'utilisateur se connecte et donne son consentement (en fonction des portées demandées).

3. Réponse avec le jeton d'ID et le code d'autorisation.

   Exemple de réponse

   Remarque
   
   Tous les paramètres de réponse sont ajoutés au composant de fragment de l'URI de redirection.

   https://<domainURL>/#access_token=eyJ4NXQjUzI1....Pudw9A&code=AQIDBAU6d6Ae....F9NCA=&token_type=Bearer&expires_in=3600

4. L'application client utilise le code d'autorisation et effectue une demande de canal arrière pour obtenir un nouveau jeton d'accès.

   Exemple de demande

      curl -i
     -H 'Authorization: Basic YjA3NTZkNDc5M2QwNDZjNjhjZWVmY2UxZjE4ZGUwMWM6NGYzZjJjN2EtZTBjZC00NzcyLWE5MTYtNjI3ZmExNzA2NWE5'
      -H 'Accept: */*''
      --request POST 'https://<domainURL>/oauth2/v1/token' -d 'grant_type=authorization_code&code=AQIDBAU6d6Ae...NCA%3D'

   Exemple de réponse

   {
   "access_token":"eyJ4NXQjUzI1....Tgs9LA",
   "token_type":"Bearer",
   "expires_in":3600
   }

Obtention d'un jeton d'ID et d'un jeton d'accès

Vous pouvez utiliser OpenID Connect pour les demandes de déconnexion basées sur un navigateur.

Vous pouvez demander une déconnexion à l'aide d'OpenID Connect de deux manières :