Type d'octroi de code d'autorisation
Utilisez ce type d'autorisation lorsque vous voulez obtenir un code d'autorisation en utilisant un serveur d'autorisation comme intermédiaire entre l'application client et le responsable de la ressource à l'aide des domaines d'identité.
Le diagramme suivant présente le flux Type d'octroi de code d'autorisation.
Un utilisateur clique sur un lien dans une application client de serveur Web pour demander l'accès aux ressources protégées.
L'application client redirige le navigateur vers le point d'extrémité d'autorisation
oauth2/v1/authorizeavec une demande de code d'autorisation.Le serveur d'autorisation retourne un code d'autorisation à l'application client au moyen d'une redirection de navigateur après que le responsable de la ressource a donné son consentement.
L'application client échange alors le code d'autorisation contre un jeton d'accès, et souvent un jeton d'actualisation.
Le serveur d'autorisation retourne le jeton d'accès à l'application client.
- L'application client utilise le jeton d'accès dans un appel d'API pour obtenir des données protégées.Note
Les données d'identification du responsable de la ressource ne sont jamais exposées au client.
| Fonction | Disponibles |
|---|---|
| Nécessite l'authentification client | Nombre |
| Requiert que le client connaisse les données d'identification de l'utilisateur | Nombre |
| Interaction avec l'utilisateur final à partir d'un navigateur | Oui |
| Peut utiliser un fournisseur d'identités externe pour l'authentification | Oui |
| Le jeton d'actualisation est autorisé | Oui |
| Le jeton d'accès est dans le contexte de l'utilisateur final | Oui |
Voir un exemple de exemple de flux d'autorisation de type d'autorisation de code d'autorisation.
Exemple de flux d'autorisation de type d'octroi de code d'autorisation
Cet exemple de flux d'autorisation vous guide tout au long d'une demande de connexion OpenID Connect à l'aide d'un code d'autorisation.
Ce flux est un flux OAuth à trois branches, qui fait référence aux scénarios dans lesquels l'application appelle les API du domaine d'identité pour le compte des utilisateurs finaux et dans lesquels le consentement de l'utilisateur est parfois requis. Ce flux montre comment configurer l'authentification unique fédérée entre un domaine d'identité et une application personnalisée à l'aide de OAuth 2.0 et OpenID Connect.
Lorsque vous créez une application à l'aide du type d'autorisation Code d'autorisation dans la console du domaine d'identité :
-
Spécifiez Application approuvée comme type d'application.
-
Sélectionnez Code d'autorisation comme type d'autorisation.
-
Spécifiez l'URI de redirection où les réponses aux demandes d'authentification sont envoyées.
-
Facultativement, sélectionnez le type d'autorisation Actualiser le jeton pour retourner un jeton d'actualisation avec le jeton d'accès.
Voir Type d'autorisation de code d'autorisation pour plus d'informations sur le type d'autorisation de code d'autorisation et un diagramme de flux d'autorisation.
Flux d'autorisation
-
Un utilisateur clique sur un lien dans l'application client du serveur Web (Customer Quotes), demandant l'accès aux ressources protégées.
-
L'application Customer Quotes redirige le navigateur vers le point d'extrémité d'autorisation du domaine d'identité
(oauth2/v1/authorize)avec une demande de code d'autorisation.L'URL de la demande contient des paramètres d'interrogation qui indiquent le type d'accès demandé.Note
Une valeur Nonce est une chaîne aléatoire cryptographiquement forte que vous utilisez pour empêcher la réutilisation des réponses interceptées.Exemple de demande : Client confidentiel/de confiance
GET https://<domainURL>/oauth2/v1/authorize?client_id=<client_id>&response_type=code&redirect_uri=<client-redirect-uri>&scope=openid&nonce=<nonce-value>&state=1234Exemple de demande : Client confidentiel/de confiance incluant un jeton d'actualisation dans la demande
GET https://<domainURL>/oauth2/v1/authorize?client_id=<client-id&response_type=code&redirect_uri=<client-redirect-uri>&scope=openid%20<Resource Server Scope>%20offline_access&nonce=<nonce-value>&state=1234Exemple de demande : Client public
GET https://<domainURL>/oauth2/v1/authorize?client_id=<client_id>&response_type=id_token&redirect_uri=<client-redirect-uri>&scope=openid&nonce=<nonce-value>&state=1234Exemple de demande avec PKCE
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&code_challenge=<code-challenge>&code_challenge_method=<plain|S256>' -
Le domaine d'identité reçoit la demande et identifie que l'application Customer Quotes (identifiée par
client_id) demande un code d'autorisation pour obtenir plus d'informations sur le responsable de la ressource (portéeopenid).) -
Si l'utilisateur n'est pas déjà connecté, le service IAM invite l'utilisateur à s'authentifier. Le service IAM vérifie les données d'identification de l'utilisateur.
-
Si la connexion est réussie, IAM redirige le navigateur vers l'application Customer Quotes avec un code d'autorisation.Note
Si l'utilisateur ne s'authentifie pas, une erreur est retournée plutôt que le code d'autorisation. -
L'application Customer Quotes extrait le code d'autorisation et demande à un domaine d'identité d'échanger le code d'autorisation pour un jeton d'accès.
Exemple de demande : Client confidentiel/de confiance
curl -i -H 'Authorization: Basic <base64-clientid-secret>' -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>'Exemple de demande : Client public
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>&redirect_uri=<client-redirect-uri>&client_id=<client-id>'Exemple de demande avec PKCE
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-cod>e&redirect_uri=<client-redirect-uri>&client_id=<client-id>&code_verifier=<code-verifier>'Exemple de demande utilisant mTLS
Pour savoir comment obtenir
secureDomainURL, voir Types d'autorisation d'accès.curl -v \ --cert cert.crt \ --key key.key \ --cacert ca.crt \ --location '<secureDomainURL>/oauth2/v1/token' \ --header 'Authorization: Basic <base64Encoded clientid:secret>' --header 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode 'grant_type=client_credentials' \ --data-urlencode 'client_id=<client-id>' \ --data-urlencode 'scope=urn:opc:idm:_myscopes_' -
IAM valide les données d'autorisation et d'utilisateur associées au code (
client_id, client_secretet au code d'autorisation). -
Un jeton d'accès et un jeton d'identité sont retournés. Le jeton d'accès contient des informations sur les étendues que l'application Customer Quotes peut demander au nom de l'utilisateur. L'application peut utiliser ce jeton lors de la demande d'API au nom de l'utilisateur.
Le jeton d'identité est extrait uniquement lorsque vous demandez l'étendue
openid. Ce jeton contient des informations d'identification sur l'utilisateur et est utilisé pour l'authentification fédérée. -
L'application Customer Quotes traite
id_token, puis extrait les informations de l'utilisateur retournées par IAM. -
Customer Quotes affiche la page d'accueil qui contient des informations sur l'utilisateur.