Partager via

Demander un jeton d’accès dans Azure Active Directory B2C

Important

À compter du 1er mai 2025, Azure AD B2C ne sera plus disponible pour les nouveaux clients. Pour plus d’informations, consultez notre FAQ.

Un jeton d’accès contient des revendications que vous pouvez utiliser dans Azure Active Directory B2C (Azure AD B2C) pour identifier les autorisations accordées à vos API. Pour appeler un serveur de ressources, la requête HTTP doit inclure un jeton d’accès. Un jeton d’accès est indiqué comme access_token dans les réponses d’Azure AD B2C.

Cet article explique comment demander un jeton d’accès pour une application web et une API web. Pour plus d’informations sur les jetons dans Azure AD B2C, consultez la vue d’ensemble des jetons dans Azure Active Directory B2C.

Remarque

Les chaînes d’API web (on-Behalf-Of) ne sont pas prises en charge par Azure AD B2C - De nombreuses architectures incluent une API web qui doit appeler une autre API web en aval, toutes deux sécurisées par Azure AD B2C. Ce scénario est courant dans les clients qui ont un back-end d’API web, qui appelle à son tour un autre service. Ce scénario d’API web chaînée peut être pris en charge à l’aide de l’octroi des informations d’identification du porteur OAuth 2.0 JWT, également appelé flux On-Behalf-Of. Toutefois, le flux on-Behalf-Of n’est pas actuellement implémenté dans Azure AD B2C. On-Behalf-Of fonctionne pour les applications inscrites dans Microsoft Entra ID, mais pas pour les applications inscrites dans Azure AD B2C, quel que soit le locataire (Microsoft Entra ID ou Azure AD B2C) qui émet les jetons.

Conditions préalables

Étendues

Les étendues offrent un moyen de gérer les autorisations pour les ressources protégées. Lorsqu’un jeton d’accès est demandé, l’application cliente doit spécifier les autorisations souhaitées dans le paramètre d’étendue de la requête. Par exemple, pour spécifier la valeur d’étendue de read l’API qui a l’URI d’ID d’application de https://contoso.onmicrosoft.com/api, l’étendue serait https://contoso.onmicrosoft.com/api/read.

Les étendues sont utilisées par l’API web pour implémenter le contrôle d’accès basé sur l’étendue. Par exemple, les utilisateurs de l’API web peuvent avoir à la fois un accès en lecture et en écriture, ou les utilisateurs de l’API web peuvent avoir uniquement un accès en lecture. Pour acquérir plusieurs autorisations dans la même requête, vous pouvez ajouter plusieurs entrées dans le paramètre d’étendue unique de la requête, séparées par des espaces.

L’exemple suivant montre les étendues décodées dans une URL :

scope=https://contoso.onmicrosoft.com/api/read openid offline_access

L’exemple suivant montre les étendues encodées dans une URL :

scope=https%3A%2F%2Fcontoso.onmicrosoft.com%2Fapi%2Fread%20openid%20offline_access

Si vous demandez plus d’étendues que ce qui est accordé pour votre application cliente, l’appel réussit si au moins une autorisation est accordée. La revendication scp dans le jeton d’accès résultant comportera uniquement les autorisations octroyées.

Étendues OpenId Connect

La norme OpenID Connect spécifie plusieurs valeurs d’étendue spéciales. Les étendues suivantes représentent l’autorisation d’accéder au profil de l’utilisateur :

  • openid : demande un jeton d’ID.
  • offline_access - Demande un jeton de rafraîchissement en utilisant les flux de code d'authentification.
  • 00000000-0000-0000-0000-000000000000 - L’utilisation de l’ID client comme le champ d'application indique que votre application a besoin d’un jeton d’accès pouvant être utilisé sur votre propre service ou API web, représenté par le même ID client.

Si le paramètre response_type d’une /authorize requête inclut token, le paramètre d’étendue doit inclure au moins une étendue de ressource autre que openid celle offline_access qui sera accordée. Sinon, la /authorize requête échoue.

Demander un jeton

Pour demander un jeton d’accès, vous avez besoin d’un code d’autorisation. Voici un exemple de demande adressée au /authorize point de terminaison pour un code d’autorisation :

GET https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/authorize?
client_id=<application-ID>
&nonce=anyRandomValue
&redirect_uri=https://jwt.ms
&scope=<application-ID-URI>/<scope-name>
&response_type=code

Remplacez les valeurs dans la chaîne de requête comme suit :

  • <tenant-name> - Nom de votre locataire Azure AD B2C. Si vous utilisez un domaine personnalisé, remplacez-le tenant-name.b2clogin.com par votre domaine, par contoso.comexemple .
  • <policy-name> - Nom de votre stratégie personnalisée ou flux d’utilisateur.
  • <application-ID> - Identificateur d’application de l’application web que vous avez inscrite pour prendre en charge le flux utilisateur.
  • <application-ID-URI> - URI d’identificateur d’application que vous définissez sous Exposer un panneau API de l’application cliente.
  • <scope-name> - Nom de l’étendue que vous avez ajoutée sous Exposer un panneau API de l’application cliente.
  • <redirect-uri> - URI de redirection que vous avez entré lorsque vous avez inscrit l’application cliente.

Pour avoir une idée du fonctionnement de la requête, collez la requête dans votre navigateur et exécutez-la.

Il s’agit de la partie interactive du flux, où vous effectuez des actions. Vous êtes invité à terminer le workflow du flux de l’utilisateur. Cela peut impliquer l’entrée de votre nom d’utilisateur et mot de passe dans un formulaire de connexion ou tout autre nombre d’étapes. Les étapes que vous effectuez dépendent de la façon dont le flux utilisateur est défini.

La réponse avec le code d’autorisation doit être similaire à cet exemple :

https://jwt.ms/?code=eyJraWQiOiJjcGltY29yZV8wOTI1MjAxNSIsInZlciI6IjEuMC...

Une fois le code d’autorisation reçu, vous pouvez l’utiliser pour demander un jeton d’accès. Les paramètres se trouvent dans le corps de la requête HTTP POST :

POST <tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/token HTTP/1.1
Host: <tenant-name>.b2clogin.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&client_id=<application-ID>
&scope=<application-ID-URI>/<scope-name>
&code=eyJraWQiOiJjcGltY29yZV8wOTI1MjAxNSIsInZlciI6IjEuMC...
&redirect_uri=https://jwt.ms
&client_secret=2hMG2-_:y12n10vwH...

Si vous souhaitez tester cette requête POST HTTP, vous pouvez utiliser n’importe quel client HTTP tel que Microsoft PowerShell.

Un jeton de réponse correct se présente ainsi :

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ilg1ZVhrN...",
    "token_type": "Bearer",
    "not_before": 1549647431,
    "expires_in": 3600,
    "expires_on": 1549651031,
    "resource": "f2a76e08-93f2-4350-833c-965c02483b11",
    "profile_info": "eyJ2ZXIiOiIxLjAiLCJ0aWQiOiJjNjRhNGY3ZC0zMDkxLTRjNzMtYTcyMi1hM2YwNjk0Z..."
}

Lorsque vous utilisez https://jwt.ms pour examiner le jeton d’accès retourné, vous devez voir quelque chose de similaire à l’exemple suivant :

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "X5eXk4xyojNFum1kl2Ytv8dl..."
}.{
  "iss": "https://contoso0926tenant.b2clogin.com/c64a4f7d-3091-4c73-a7.../v2.0/",
  "exp": 1549651031,
  "nbf": 1549647431,
  "aud": "f2a76e08-93f2-4350-833c-965...",
  "oid": "1558f87f-452b-4757-bcd1-883...",
  "sub": "1558f87f-452b-4757-bcd1-883...",
  "name": "David",
  "tfp": "B2C_1_signupsignin1",
  "nonce": "anyRandomValue",
  "scp": "read",
  "azp": "38307aee-303c-4fff-8087-d8d2...",
  "ver": "1.0",
  "iat": 1549647431
}.[Signature]

Étapes suivantes

  • Last updated on