Utilisation d'OpenID Connect pour étendre OAuth 2.0

Un jeton d'identité est un jeton autonome sécurisé par intégrité (au format Jeton Web JSON (JWT)) défini dans la norme OpenID Connect contenant des réclamations relatives à l'utilisateur final. Le jeton d'identité est l'extension principale que OpenID Connect effectue vers 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 codées en 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 ID client et 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, 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 directement les informations d'identification et de connexion, elle vérifie que le nom utilisateur et le mot de passe présentés correspondent à ce que vous gérez. Lorsque vous utilisez une identité basée sur les réclamations, vous sous-traitez 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 a été 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 de vous fier à celles-ci en tant qu'assertion que l'utilisateur a authentifié, vous devez les valider.

OpenID Document de repérage

Le protocole OpenID Connect 1.0 est une couche d'identité simple sur le protocole OAuth 2.0 qui nécessite l'utilisation de plusieurs adresses pour authentifier les utilisateurs et pour demander des ressources comprenant des informations utilisateur, des jetons et des clés publiques. Pour vous aider à découvrir quelles sont ces adresses que vous devez utiliser, OpenID Connect vous permet d'utiliser un document de découverte, qui est un document JSON trouvé à un emplacement 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 de l'autorisation, du jeton, des informations utilisateur et des adresses de clés publiques. Vous pouvez extraire le document de repérage pour le service OpenID Connect de 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 les informations de profil sur l'identité 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 se compose de deux composants :

• Déclarations décrivant l'utilisateur

• Adresse UserInfo fournissant un mécanisme permettant d'extraire ces réclamations

  Remarque
  
  Les réclamations utilisateur peuvent également être présentées à l'intérieur du jeton d'ID afin d'éliminer un rappel lors de l'authentification.

Réclamations du profil utilisateur

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 sont mappées avec un ensemble spécifique de revendications 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, si la portée email n'est pas utilisée), la réclamation (email) ne sera pas présente dans les réclamations renvoyées.

Exemple de demande d'adresse UserInfo - Exemple

Une fois que l'application client a authentifié un utilisateur et dispose du jeton d'accès, le client peut ensuite demander à l'adresse UserInfo d'extraire les attributs demandés sur un utilisateur. L'exemple suivant illustre une 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 réclamations 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 de code d'autorisation lorsque des clients peuvent gérer 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 pour un jeton d'ID et un jeton d'accès directement.

Cela vous offre l'avantage de ne pas exposer de jetons à l'agent utilisateur (comme 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 pour un jeton d'accès. Le flux de code d'autorisation fonctionne 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 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 à la demande et aux réponses du client confidentiel traité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 du 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 du client public, il n'y a pas d'en-tête d'authentification de base. L'ID client est indiqué 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 avez un composant de navigateur tel que JavaScript et 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 jeton d'ID et 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 de deux manières à l'aide d'OpenID Connect :