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
Eviter les incidents : Si vous utilisez un proxy sortant, notez que le fournisseur de ressource OpenID Connect ne fournit aucun moyen d'acheminer automatiquement des demandes via un hôte proxy.

Si vous devez utiliser un proxy pour accéder au fournisseur OpenID Connect, la valeur que vous entrez pour n'importe quelle propriété d'URL liée à un fournisseur OpenID Connect doit contenir l'hôte et le port de proxy et non l'hôte et le port de fournisseur OpenID Connect externe.

Dans la plupart des cas, vous pouvez remplacer l'hôte et le port de fournisseur OpenID Connect par l'hôte et le port de proxy. L'URL que vous entrez doit être visible à la fois pour le fournisseur et le client (navigateur ou application). Pour obtenir d'autres conseils sur la méthode permettant de déterminer l'URL à utiliser, contactez votre administrateur de proxy.

Dans cet exemple, le client suppose que le port SSL est défini sur 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

Nom du fichier : twlp_oidc_auth_endpoint.html