Utilisation d'OpenID Connect pour étendre OAuth 2.0

Un jeton d'identité est un jeton autonome sécurisé pour l'intégrité (au format JWT (JSON Web Token)), défini dans la norme OpenID Connect contenant des revendications concernant l'utilisateur final. Le jeton d'identité est l'extension principale d'OpenID Connect 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, des données utiles et de la signature numérique. Suivant 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. Il 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 et similaire à 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. Voir OpenID Connect pour plus d'informations.

Pourquoi validons-nous les jetons? Lorsque votre application Web vérifie directement les données d'identification, elle vérifie que le nom d'utilisateur et le mot de passe présentés correspondent à ce que vous tenez à jour. Lorsque vous utilisez une identité basée sur des réclamations, vous sous-traitez cette tâche à un fournisseur d'identités.

La responsabilité passe de la vérification des données d'identification brutes à la vérification que le demandeur a passé par votre fournisseur d'identités privilégié et a réussi l'authentification. Le fournisseur d'identités a réussi l'authentification en émettant un jeton. Avant de pouvoir utiliser les informations ou de s'en fier comme assertion que l'utilisateur s'est authentifié, vous devez les valider.

OpenID Document d'exploration

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

Le point d'extrémité OpenID Connect UserInfo est utilisé par une application pour extraire des informations de profil sur l'identité authentifiée. Les applications peuvent utiliser ce point d'extrémité pour extraire des informations de profil, des préférences et d'autres informations propres à l'utilisateur.

Le profil OpenID Connect comprend deux composants :

• Réclamations décrivant l'utilisateur

• Point d'extrémité UserInfo fournissant un mécanisme pour extraire ces revendications

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

Réclamations de profil d'utilisateur

Le point d'extrémité UserInfo fournit un jeu de revendications basé sur les portées OAuth2 présentées dans la demande d'authentification. OpenID Connect définit cinq valeurs de portée qui sont mappées à un jeu spécifique de revendications par défaut :

Le client doit présenter ses données 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 revendication (email) ne sera pas présente dans les revendications retournées.

Exemple de demande de point d'extrémité UserInfo

Une fois que l'application client a authentifié un utilisateur et dispose du jeton d'accès, le client peut alors faire une demande au point d'extrémité UserInfo pour 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 retourne une réponse HTTP 200 OK et les revendications 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 retournées par le point d'extrémité UserInfo (par exemple, pour vérifier l'attaque de substitution de jeton), le client doit vérifier que la revendication sub retournée par la demande de point d'extrémité UserInfo correspond à l'objet du jeton d'ID.

Utilisez le flux de code d'autorisation lorsque vous avez des clients qui 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 retourne un code d'autorisation au client, qui peut ensuite échanger le code contre un jeton d'identification et un jeton d'accès directement.

Cela vous donne 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 Code d'autorisation fonctionne avec les clients confidentiels et les clients publics.

Clients confidentiels

Clients publics

Les clients publics n'ont pas de données d'identification, ils ont plutôt un identificateur de client. Le flux Authorization Code comprend deux étapes. Les demandes impliquent une demande GET basée sur un navigateur, puis une demande POST de canal dorsal 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

   Note
   
   Ces exemples de demande et de réponse sont similaires à la demande du client confidentiel et aux réponses décrites précédemment.

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

2. Demandez le jeton.

   Exemple de demande

   Note
   
   Cette demande est différente de la demande de client confidentiel dans laquelle l'ID client et la clé secrète client sont spécifiés dans l'en-tête d'authentification de base. Dans le flux de client public, il n'y a pas d'en-tête d'authentification de base. L'ID client est spécifié dans les données utiles 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 mis en oeuvre 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'identification sont retourné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 (comme 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 comprend 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

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

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

Obtention d'un jeton d'identification 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 dorsal tel que Node.js. Le composant de navigateur obtient le code d'autorisation et le jeton d'identification et peut ensuite personnaliser le contenu de l'interface utilisateur. Le composant dorsal obtient le jeton d'accès pour effectuer des appels d'API de gestion.

Les clients doivent prendre en charge les demandes et les réponses basées sur un navigateur, ainsi que les demandes et les réponses programmatiques/back-canal pour utiliser le flux hybride. Le flux hybride fonctionne 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 un jeton d'ID et un code d'autorisation.

   Exemple de réponse

   Note
   
   Tous les paramètres de réponse sont ajoutés au composant 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'identification 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 façons à l'aide d'OpenID Connect :