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.

Diagramme illustrant le flux de type d'octroi de code d'autorisation.
Dans ce flux OAuth :
  1. Un utilisateur clique sur un lien dans une application client de serveur Web pour demander l'accès aux ressources protégées.

  2. L'application client redirige le navigateur vers le point d'extrémité d'autorisation oauth2/v1/authorize avec une demande de code d'autorisation.

  3. 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.

  4. L'application client échange alors le code d'autorisation contre un jeton d'accès, et souvent un jeton d'actualisation.

  5. Le serveur d'autorisation retourne le jeton d'accès à l'application client.

  6. 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

  1. Un utilisateur clique sur un lien dans l'application client du serveur Web (Customer Quotes), demandant l'accès aux ressources protégées.

  2. 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=1234

    Exemple 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=1234

    Exemple 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=1234

    Exemple 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>'
  3. 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ée openid).)

  4. 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.

  5. 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.
  6. 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_'
  7. IAM valide les données d'autorisation et d'utilisateur associées au code (client_id, client_secret et au code d'autorisation).

  8. 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.

  9. L'application Customer Quotes traite id_token, puis extrait les informations de l'utilisateur retournées par IAM.

  10. Customer Quotes affiche la page d'accueil qui contient des informations sur l'utilisateur.