
![[8.5.5.4 ou ultérieure]](../ng_v8554.gif)
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
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 de profil 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
Procédure
Résultats
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
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:443/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:443/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:443/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:443/oidcclient/redirect/client01
access_token=SlAV32hkKG
&token_type=Bearer
&id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
&expires_in=3600
&state=af0ifjsldkj