Utilisation d'OpenID Connect pour étendre OAuth 2.0

Un jeton d'identité est un jeton autonome sécurisé par intégrité (au format JWT (JSON Web Token) défini dans la norme OpenID Connect contenant des revendications sur l'utilisateur final. Le jeton d'identité est l'extension principale qu'OpenID Connect fait à 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 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 l'ID client et la 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 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, voir OpenID Connect.

Pourquoi valider 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 préféré et s'est authentifié. Le fournisseur d'identités représente une authentification réussie en émettant un jeton. Avant de pouvoir utiliser les informations ou vous y fier en tant qu'assertion authentifiée par l'utilisateur, vous devez les valider.

OpenID Document de découverte

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 points d'extrémité pour authentifier les utilisateurs et 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 détection, 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'informations d'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é UserInfo d'OpenID Connect est utilisé par une application pour extraire les 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 réclamations

  Note
  
  Les réclamations 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 étendues 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 l'étendue openid.

Si une portée est omise (par exemple, la portée email n'est pas utilisée), la réclamation (email) ne sera pas présente dans les réclamations retournées.

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

Une fois que l'application client a authentifié un utilisateur et dispose du jeton d'accès, le client peut ensuite faire une demande au point d'extrémité UserInfo pour extraire les attributs demandés concernant un utilisateur. L'exemple suivant montre 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 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 approuver les valeurs retournées par le point d'extrémité UserInfo (par exemple, pour vérifier l'attaque par substitution de jeton), le client doit vérifier que la réclamation sub retournée par la demande de point d'extrémité UserInfo correspond à l'objet du jeton d'ID.

Utilisez le flux Authorization Code lorsque vous avez des clients qui peuvent conserver une clé secrète client en toute sécurité entre eux et le serveur d'autorisation. Le flux Authorization Code renvoie 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 permet 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 Code d'autorisation comporte 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 et aux réponses du client confidentiel 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 du client confidentiel pour 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 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 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'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 par 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

   Note
   
   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 dorsal tel que Node.js. Le composant du 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 d'affaires.

Les clients doivent prendre en charge à la fois les demandes et les réponses basées sur un navigateur et les demandes et les 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 ID jeton et code d'autorisation.

   Exemple de réponse

   Note
   
   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 le navigateur.

Vous pouvez demander une déconnexion à l'aide d'OpenID Connect de deux façons :