Appel du noeud final d'autorisation pour OpenID Connect

Dans OpenID Connect, le noeud final d'autorisation traite l'authentification et l'autorisation d'un utilisateur.

Avant de commencer

Lors du démarrage du noeud final d'autorisation depuis une application client interne à un navigateur ou un application client implémentée dans un langage de script tel que Javascript, par exemple, aucune configuration de serveur Liberty en tant que client OpenID Connect n'est nécessaire.

Pourquoi et quand exécuter cette tâche

Le noeud final d'autorisation accepte une demande d'authentification qui inclut les paramètres qui sont définis par les spécifications OAuth 2.0 et OpenID Connect 1.0.

Dans le flux de code d'autorisation, le noeud final d'autorisation est utilisé pour l'authentification et l'autorisation et il renvoie un octroi d'autorisation au client. Cet octroi d'autorisation peut ensuite être transmis dans une demande par le client au noeud final de jeton en échange d'un jeton d'ID, d'un jeton d'accès et d'un jeton d'actualisation. Dans le flux implicite, le noeud final d'autorisation effectue toujours l'authentification et l'autorisation mais il renvoie également un jeton d'ID et un jeton d'accès au client dans sa réponse ; aucune interaction n'a lieu avec le noeud final de jeton.

Un serveur Liberty avec OpenID Connect activé peut accéder au noeud final d'autorisation OpenID Connect à l'URL suivante :

 https://server.example.com:443/oidc/endpoint/<provider_name>/authorize
Remarque : Dans cet exemple le port SSL du fournisseur OpenID Connect doit être 443.

Procédure

  1. Préparez une demande HTTP GET ou POST qui inclut les paramètres obligatoires et recommandés suivants.
    • scope: (obligatoire) Les demandes OpenID Connect doivent contenir la valeur de portée openid. D'autres portées peuvent aussi être présentes
    • response_type : (obligatoire) Détermine le flux de traitement de l'autorisation à utiliser. Avec le flux de code d'autorisation, cette valeur est code. Avec le flux implicite, cette valeur est id_token token ou id_token. Aucun jeton d'accès n'est renvoyé lorsque la valeur est id_token
    • client_id : (obligatoire) Identificateur de client qui est valide au niveau du fournisseur OpenID Connect.
    • redirect_uri : (obligatoire) URI de redirection à laquelle la réponse va être envoyée. Cette valeur doit correspondre exactement à l'une des valeurs d'URI de redirection pour le client enregistré auprès du fournisseur OpenID Connect.
    • state : (recommandé) Valeur opaque utilisée pour gérer l'état entre la demande et le rappel.
    • nonce : (obligatoire pour le flux implicite) Valeur de chaîne utilisée pour associer une session client à un jeton d'ID et pour atténuer les attaques par réinsertion.

    Vous pouvez inclure plusieurs paramètres dans la demande. Pour une description des autres paramètres pris en charge, voir la spécification OpenID Connect Core 1.0.

    Nous ne prenons pas en charge un seul type de réponse id_token. Avec le flux implicite, id_token token doit toujours être utilisé et il renvoie un jeton d'accès.

  2. Envoyez la demande GET ou POST à l'URL du noeud final d'autorisation.

Résultats

Une fois ces étapes effectuées, vous disposez d'une demande HTTP valide qui peut être envoyée au noeud final d'autorisation. Ce dernier renvoie une réponse de la manière décrite dans la section Exemples.

Le fournisseur OpenID Connect essaie d'authentifier et d'autoriser l'utilisateur dès qu'il reçoit une demande du client.

Dans le flux de code d'autorisation, si l'authentification et l'autorisation aboutissent, le fournisseur OpenID Connect émet un code d'autorisation et l'inclut en tant que paramètre dans une réponse d'autorisation OAuth 2.0 au client. Si la demande initiale incluait state, la réponse d'autorisation inclura la valeur state exacte qui figurait dans la demande initiale. Au moyen du format application/x-www-form-urlencoded, les paramètres code et state sont ajoutés en tant que paramètres de requête à la valeur redirect_uri qui a été spécifiée dans la demande d'autorisation.

Dans le flux implicite, si l'authentification et l'autorisation aboutissent, les paramètres suivants sont renvoyés par le noeud final d'autorisation.

  • access_token: jeton d'accès. Ce paramètre est renvoyé sauf si la valeur [response_type] figurant dans la demande initiale est [id_token].
  • token_type : Type de jeton OAuth 2.0. Pour OpenID Connect, cette valeur est Bearer.
  • id_token: jeton d'ID.
  • state : obligatoire si inclus dans la demande d'autorisation.
  • expires_in : (facultatif) délai d'expiration en secondes du jeton d'accès depuis que la réponse a été générée.

Ces paramètres sont ajoutés au composant fragment de la valeur redirect_uri qui est spécifiée dans la demande d'autorisation, mais pas en tant que paramètres de requête comme dans le flux de code d'autorisation.

Exemple

Les exemples ci-après illustrent les formes de flux de code d'autorisation et les flux de code implicite.

Voici un exemple de demande pour le flux d'autorisation de code :

 GET /authorize?
     response_type=code
     &scope=openid profile email 		
     &client_id=client01 		
     &state=af0ifjsldkj 		
     &redirect_uri=https://server.example.com:8020/oidcclient/redirect/client01 HTTP/1.1 	

Voici un exemple de demande pour le flux implicite :

 GET /authorize?
     response_type=id_token token
     &scope=openid profile 		
     &client_id=client01 		
     &state=af0ifjsldkj 		
     &redirect_uri=https://server.example.com:8020/oidcclient/redirect/client01 		
     &nonce=n-0S6_WzA2Mj HTTP/1.1 	

Voici un exemple de réponse du noeud final d'autorisation dans le flux de code d'autorisation :

 HTTP/1.1 302 Found
 Location: https://server.example.com:8020/oidcclient/redirect/client01
     code=SplxlOBeZQQYbYS6WxSbIA
     &state=af0ifjsldkj

Voici un exemple de réponse du noeud final d'autorisation dans le flux implicite :

 HTTP/1.1 302 Found
 Location: https://server.example.com:8020/oidcclient/redirect/client01
     access_token=SlAV32hkKG
     &token_type=Bearer 		
     &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso 		
     &expires_in=3600 		
     &state=af0ifjsldkj

Icône indiquant le type de rubrique Rubrique Tâche



Icône d'horodatage Dernière mise à jour: Tuesday, 6 December 2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=twlp_oidc_auth_endpoint
Nom du fichier : twlp_oidc_auth_endpoint.html