Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Important
À compter du 1er mai 2025, Azure AD B2C ne sera plus disponible pour les nouveaux clients. Pour plus d’informations, consultez notre FAQ.
Vous pouvez utiliser le code d’autorisation OAuth 2.0 accordé dans les applications installées sur un appareil pour accéder à des ressources protégées, telles que les API Web. À l’aide de l’implémentation Azure Active Directory B2C (Azure AD B2C) d’OAuth 2.0, vous pouvez ajouter des tâches d’inscription, de connexion et d’autres tâches de gestion des identités à vos applications monopages, mobiles et de bureau. Dans cet article, nous décrivons comment envoyer et recevoir des messages HTTP sans utiliser de bibliothèques open source. Cet article est indépendant de la langue. Dans la mesure du possible, nous vous recommandons d’utiliser les bibliothèques d’authentification Microsoft (MSAL) prises en charge. Jetez un coup d’œil aux exemples d’applications qui utilisent MSAL.
Le flux de code d’autorisation OAuth 2.0 est décrit dans la section 4.1 des spécifications OAuth 2.0. Vous pouvez l’utiliser pour l’authentification et l’autorisation dans la plupart des types d’applications, y compris les applications web, les applications monopages et les applications installées en mode natif. Vous pouvez utiliser le flux de code d’autorisation OAuth 2.0 pour acquérir en toute sécurité des jetons d’accès et des jetons d’actualisation pour vos applications, qui peuvent être utilisés pour accéder à des ressources sécurisées par un serveur d’autorisation. Le jeton d’actualisation permet au client d’acquérir de nouveaux jetons d’accès (et d’actualisation) une fois que le jeton d’accès a expiré, généralement au bout d’une heure.
Cet article se concentre sur le flux de code d’autorisation OAuth 2.0 des clients publics . Un client public est une application cliente à laquelle on ne peut pas faire confiance pour maintenir en toute sécurité l’intégrité d’un mot de passe secret. Cela inclut les applications monopages, les applications mobiles, les applications de bureau et, essentiellement, toute application qui ne s’exécute pas sur un serveur.
Remarque
Pour ajouter la gestion des identités à une application web à l’aide d’Azure AD B2C, utilisez OpenID Connect au lieu d’OAuth 2.0.
Azure AD B2C étend les flux OAuth 2.0 standard pour faire plus que de simples authentifications et autorisations. Il introduit le flux d’utilisateurs. Avec les flux d’utilisateurs, vous pouvez utiliser OAuth 2.0 pour ajouter des expériences utilisateur à votre application, telles que l’inscription, la connexion et la gestion des profils. Les fournisseurs d’identité qui utilisent le protocole OAuth 2.0 incluent Amazon, Microsoft Entra ID,Facebook, GitHub, Google et LinkedIn.
Pour essayer les requêtes HTTP de cet article :
- Remplacez
{tenant}par le nom de votre locataire Azure AD B2C. - Remplacez-le
00001111-aaaa-2222-bbbb-3333cccc4444par l’ID d’application d’une application que vous avez précédemment inscrite dans votre locataire Azure AD B2C. - Remplacez
{policy}par le nom d’une stratégie que vous avez créée dans votre instance, par exempleb2c_1_sign_in.
Configuration de l’URI de redirection requise pour les applications à page unique
Le flux de code d’autorisation pour les applications à page unique nécessite une configuration supplémentaire. Suivez les instructions de création de votre application à page unique pour marquer correctement votre URI de redirection comme activé pour CORS. Pour mettre à jour une URI de redirection existante afin d’activer CORS, vous pouvez cliquer sur l’invite de migration dans la section « Web » de l’onglet Authentification de l’inscription de l’application. Vous pouvez également ouvrir l’éditeur de manifeste des inscriptions d’applications et définir le type champ vers lequel correspond votre URI de redirection dans spa la replyUrlsWithType section.
Le spa type de redirection est rétrocompatible avec le flux implicite. Les applications qui utilisent actuellement le flux implicite pour obtenir des jetons peuvent passer au type d’URI de redirection spa sans problème et continuer à utiliser le flux implicite.
1. Obtenez un code d’autorisation
Le flux de code d'autorisation commence par le client dirigeant l'utilisateur vers le point de terminaison /authorize . Il s’agit de la partie interactive du flux, où l’utilisateur passe à l’action. Dans cette demande, le client indique dans le scope paramètre les autorisations qu’il doit acquérir de l’utilisateur. Les exemples suivants (avec des sauts de ligne pour plus de lisibilité) montrent comment acquérir un code d’autorisation. Si vous testez cette requête HTTP GET, utilisez votre navigateur.
GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=code
&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob
&response_mode=query
&scope=00001111-aaaa-2222-bbbb-3333cccc4444%20offline_access%20https://{tenant-name}/{app-id-uri}/{scope}
&state=arbitrary_data_you_can_receive_in_the_response
&code_challenge=YTFjNjI1OWYzMzA3MTI4ZDY2Njg5M2RkNmVjNDE5YmEyZGRhOGYyM2IzNjdmZWFhMTQ1ODg3NDcxY2Nl
&code_challenge_method=S256
| Paramètre | Obligatoire ? | Descriptif |
|---|---|---|
| {locataire} | Obligatoire | Nom de votre locataire Azure AD B2C |
| {politique} | Obligatoire | Flux utilisateur à exécuter. Spécifiez le nom d’un flux d’utilisateur que vous avez créé dans votre locataire Azure AD B2C. Par exemple : b2c_1_sign_in, b2c_1_sign_up, ou b2c_1_edit_profile. |
| client_id | Obligatoire | ID d’application affecté à votre application dans le portail Azure. |
| type_de_réponse | Obligatoire | Le type de réponse, qui doit inclure code pour le flux de code d’autorisation. Vous pouvez recevoir un jeton d’ID si vous l’incluez dans le type de réponse, par exemple code+id_token, et dans ce cas, l’étendue doit inclure openid. |
| redirect_uri | Obligatoire | URI de redirection de votre application, où votre application envoie et reçoit des réponses d’authentification. Il doit correspondre exactement à l’un des URI de redirection que vous avez enregistrés dans le portail, sauf qu’il doit être encodé au format URL. |
| portée | Obligatoire | Une liste d’étendues séparées par des espaces. L’étendue openid indique une autorisation pour connecter l’utilisateur et obtenir des données relatives à l’utilisateur sous la forme de jetons d’ID. L’étendue offline_access est facultative pour les applications web. Il indique que votre application a besoin d’un jeton d’actualisation pour un accès étendu aux ressources. L’ID du client indique que le jeton émis qui sera utilisé par le client inscrit Azure AD B2C.
https://{tenant-name}/{app-id-uri}/{scope} indique une autorisation pour les ressources protégées telles qu’une API web. Pour plus d’informations, consultez Demander un jeton d’accès. |
| mode_de_réponse | Recommandé | Méthode à utiliser pour renvoyer le code d’autorisation résultant à votre application. Il peut s’agir de query, form_post ou fragment. |
| état | Recommandé | Une valeur incluse dans la requête peut être une chaîne de n’importe quel contenu que vous voulez utiliser. Généralement, une valeur unique générée de manière aléatoire est utilisée pour empêcher les attaques par falsification de requête intersites. L’état est également utilisé pour coder les informations sur l’état de l’utilisateur dans l’application avant la demande d’authentification. Par exemple, la page dans laquelle l’utilisateur se trouvait ou le flux d’utilisateur en cours d’exécution. |
| prompt | Optionnel | Le type d’interaction utilisateur requis. Actuellement, la seule valeur valide est login, ce qui oblige l’utilisateur à entrer ses informations d’identification sur cette demande. L’authentification unique ne prend pas effet. |
| défi_de_code | recommandé/obligatoire | Utilisé pour sécuriser l’octroi de codes d’autorisation via Proof Key for Code Exchange (PKCE). Obligatoire si code_challenge_method est inclus. Vous devez ajouter une logique dans votre application pour générer code_verifier et code_challenge.
code_challenge est un hachage SHA256 codé en URL Base64 de code_verifier. Vous stockez le code_verifier dans votre application pour une utilisation ultérieure et l’envoyez avec la demande d’autorisation code_challenge . Pour plus d'informations, consultez le RFC PKCE. Cette option est désormais recommandée pour tous les types d’applications : applications natives, SPA et clients confidentiels tels que les applications web. |
code_challenge_method |
recommandé/obligatoire | La méthode utilisée pour encoder le code_verifier pour le paramètre code_challenge. Cela DEVRAIT être S256, mais la spécification permet l’utilisation de plain si, pour une raison quelconque, le client ne peut pas prendre en charge SHA256. Si vous excluez le code_challenge_method, mais que vous incluez tout de même le code_challenge, alors le code_challenge est supposé être du texte brut. La plateforme d’identités Microsoft prend en charge à la fois plain et S256. Pour plus d'informations, consultez le RFC PKCE. Ceci est requis pour les applications à page unique utilisant le flux de code d’autorisation. |
| indice de connexion | Non | Peut être utilisé pour préremplir le champ nom de connexion de la page de connexion. Pour plus d’informations, consultez Préremplir le nom de connexion. |
| domain_hint | Non | Fournit un indicateur à Azure AD B2C sur le fournisseur d’identité sociale qui doit être utilisé pour la connexion. Si une valeur valide est incluse, l’utilisateur accède directement à la page de connexion du fournisseur d’identité. Pour plus d’informations, consultez Redirection de la connexion à un fournisseur de réseaux sociaux. |
| Paramètres personnalisés | Non | Paramètres personnalisés qui peuvent être utilisés avec des stratégies personnalisées. Par exemple, un URI de contenu de page personnalisée dynamique ou des programmes de résolution de revendication de clé-valeur. |
À ce stade, il est demandé à l’utilisateur d’effectuer le workflow du flux utilisateur. Cela peut impliquer que l’utilisateur saisisse son nom d’utilisateur et son mot de passe, se connecte avec une identité sociale, s’inscrive à l’annuaire ou tout autre nombre d’étapes. Les actions utilisateur dépendent de la façon dont le flux utilisateur est défini.
Une fois que l’utilisateur a terminé le flux d’utilisateurs, l’ID Microsoft Entra renvoie une réponse à votre application à la valeur que vous avez utilisée pour redirect_uri. Elle utilise la méthode spécifiée dans le response_mode paramètre. La réponse est exactement la même pour chacun des scénarios d’action utilisateur, indépendamment du flux utilisateur qui a été exécuté.
Une réponse réussie qui utilise response_mode=query ressemble à ceci :
GET urn:ietf:wg:oauth:2.0:oob?
code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq... // the authorization_code, truncated
&state=arbitrary_data_you_can_receive_in_the_response // the value provided in the request
| Paramètre | Descriptif |
|---|---|
| code | Code d’autorisation demandé par l’application. L’application peut utiliser le code d’autorisation pour demander un jeton d’accès pour une ressource cible. Les codes d’autorisation sont de courte durée. Généralement, ils expirent au bout de 10 minutes. |
| état | Voir la description complète dans le tableau de la section précédente. Si un paramètre state est inclus dans la demande, la même valeur doit apparaître dans la réponse. L’application doit vérifier que les state valeurs de la demande et de la réponse sont identiques. |
Les réponses d’erreur peuvent également être envoyées à l’URI de redirection afin que l’application puisse les gérer de manière appropriée :
GET urn:ietf:wg:oauth:2.0:oob?
error=access_denied
&error_description=The+user+has+cancelled+entering+self-asserted+information
&state=arbitrary_data_you_can_receive_in_the_response
| Paramètre | Descriptif |
|---|---|
| erreur | Chaîne de code d’erreur que vous pouvez utiliser pour classer les types d’erreurs qui se produisent. Vous pouvez également utiliser la chaîne pour réagir aux erreurs. |
| description de l'erreur | Un message d’erreur spécifique qui peut vous aider à identifier la cause principale d’une erreur d’authentification. |
| état | Voir la description complète dans le tableau précédent. Si un paramètre state est inclus dans la demande, la même valeur doit apparaître dans la réponse. L’application doit vérifier que les state valeurs de la demande et de la réponse sont identiques. |
2. Obtenez un jeton d’accès
Maintenant que vous avez acquis un code d’autorisation, vous pouvez l’échanger code contre un jeton de la ressource prévue en envoyant une requête POST à l'emplacement /token. Dans Azure AD B2C, vous pouvez demander des jetons d’accès pour d’autres API comme d’habitude en spécifiant leur ou leurs étendues dans la requête.
Vous pouvez également demander un jeton d’accès pour l’API Web principale de votre application par convention en utilisant l’ID client de l’application comme étendue demandée (ce qui se traduira par un jeton d’accès avec cet ID client comme « audience ») :
POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=00001111-aaaa-2222-bbbb-3333cccc4444 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
&code_verifier=ThisIsntRandomButItNeedsToBe43CharactersLong
| Paramètre | Obligatoire ? | Descriptif |
|---|---|---|
| {locataire} | Obligatoire | Nom de votre locataire Azure AD B2C |
| {politique} | Obligatoire | Flux utilisateur utilisé pour acquérir le code d’autorisation. Vous ne pouvez pas utiliser un autre flux d’utilisateur dans cette requête. |
| client_id | Obligatoire | ID d’application affecté à votre application dans le portail Azure. |
| secret du client | Oui, dans Web Apps | Secret d’application généré dans le portail Azure. Les secrets client sont utilisés dans ce flux pour les scénarios d’application web, où le client peut stocker en toute sécurité une clé secrète client. Pour les scénarios d’application native (client public), les clés secrètes client ne peuvent pas être stockées en toute sécurité et ne sont donc pas utilisées dans cet appel. Si vous utilisez une clé secrète client, modifiez-la périodiquement. |
| type d'autorisation | Obligatoire | Le type de subvention. Pour le flux de code d’autorisation, le type d’octroi doit être authorization_code. |
| portée | Recommandé | Une liste d’étendues séparées par des espaces. Une seule valeur d’étendue indique à Azure AD B2C les deux autorisations demandées. L’utilisation de l’ID client comme étendue indique que votre application a besoin d’un jeton d’accès qui peut être utilisé sur votre propre service ou API web, représenté par le même ID client. L’étendue offline_access indique que votre application a besoin d’un jeton d’actualisation pour un accès de longue durée aux ressources. Vous pouvez également utiliser l’étendue openid pour demander un jeton d’ID à partir d’Azure AD B2C. |
| code | Obligatoire | Le code d’autorisation que vous avez acquis à partir de l’endpoint /authorize. |
| redirect_uri | Obligatoire | URI de redirection de l’application dans laquelle vous avez reçu le code d’autorisation. |
| vérificateur_de_code | recommandé | Le même code_verifier utilisé pour obtenir le code d’autorisation. Obligatoire si PKCE est utilisé dans la requête d’octroi du code d’autorisation. Pour plus d'informations, consultez le RFC PKCE. |
Si vous testez cette requête HTTP POST, vous pouvez utiliser n’importe quel client HTTP tel que Microsoft PowerShell.
Un jeton de réponse correct se présente ainsi :
{
"not_before": "1442340812",
"token_type": "Bearer",
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
"scope": "00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
"expires_in": "3600",
"refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
| Paramètre | Descriptif |
|---|---|
| pas_avant | Heure à laquelle le jeton est considéré comme valide, en heure epoch. |
| type_de_jeton | Valeur du type de jeton. Le seul type pris en charge par Microsoft Entra ID est Porteur. |
| jeton d'accès | Le jeton Web JSON (JWT) signé que vous avez demandé. |
| portée | Étendues de validité du jeton. Vous pouvez également utiliser des étendues pour mettre en cache des jetons pour une utilisation ultérieure. |
| expires_in | Durée de validité du jeton (en secondes). |
| jeton_de_actualisation | Un jeton d’actualisation OAuth 2.0. L’application peut utiliser ce jeton pour acquérir des jetons supplémentaires après l’expiration du jeton actuel. Les jetons d’actualisation sont de longue durée. Vous pouvez les utiliser pour conserver l’accès aux ressources pendant de longues périodes. Pour plus d’informations, consultez la référence du jeton Azure AD B2C. |
Les réponses d’erreur ressemblent à ceci :
{
"error": "access_denied",
"error_description": "The user revoked access to the app.",
}
| Paramètre | Descriptif |
|---|---|
| erreur | Chaîne de code d’erreur que vous pouvez utiliser pour classer les types d’erreurs qui se produisent. Vous pouvez également utiliser la chaîne pour réagir aux erreurs. |
| description de l'erreur | Un message d’erreur spécifique qui peut vous aider à identifier la cause principale d’une erreur d’authentification. |
3. Utilisez le jeton
Maintenant que vous avez acquis un jeton d’accès, vous pouvez l’utiliser dans les requêtes adressées à vos API web back-end en l’incluant dans l’en-tête Authorization :
GET /tasks
Host: mytaskwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
4. Actualisez le jeton
Les jetons d’accès et les jetons d’ID sont de courte durée. Une fois qu’ils expirent, vous devez les actualiser pour continuer à accéder aux ressources. Lorsque vous actualisez le jeton d’accès, Azure AD B2C retourne un nouveau jeton. Le jeton d’accès actualisé a des valeurs de revendication mises à jour : nbf (pas avant), iat (émis à) et exp (expiration). Toutes les autres valeurs de revendication sont identiques à celles du jeton d’accès émis à l’origine.
Pour actualiser le jeton, soumettez une autre requête POST au point de terminaison /token. Cette fois, fournissez le refresh_token au lieu de :code
POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=00001111-aaaa-2222-bbbb-3333cccc4444 offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
| Paramètre | Obligatoire ? | Descriptif |
|---|---|---|
| {locataire} | Obligatoire | Nom de votre locataire Azure AD B2C |
| {politique} | Obligatoire | Flux utilisateur utilisé pour acquérir le jeton d’actualisation d’origine. Vous ne pouvez pas utiliser un autre flux d’utilisateur dans cette requête. |
| client_id | Obligatoire | ID d’application affecté à votre application dans le portail Azure. |
| secret du client | Oui, dans Web Apps | Secret d’application généré dans le portail Azure. Les secrets client sont utilisés dans ce flux pour les scénarios d’application web, où le client peut stocker en toute sécurité une clé secrète client. Pour les scénarios d’application native (client public), les clés secrètes client ne peuvent pas être stockées en toute sécurité et ne sont donc pas utilisées dans cet appel. Si vous utilisez une clé secrète client, veuillez la modifier périodiquement. |
| type d'autorisation | Obligatoire | Le type de subvention. Pour cette étape du flux de code d’autorisation, le type d’octroi doit être refresh_token. |
| portée | Recommandé | Une liste d’étendues séparées par des espaces. Une valeur d’étendue unique indique à Microsoft Entra ID les deux autorisations demandées. L’utilisation de l’ID client comme étendue indique que votre application a besoin d’un jeton d’accès qui peut être utilisé sur votre propre service ou API web, représenté par le même ID client. L’étendue offline_access indique que votre application a besoin d’un jeton d’actualisation pour un accès de longue durée aux ressources. Vous pouvez également utiliser l’étendue openid pour demander un jeton d’ID à partir d’Azure AD B2C. |
| redirect_uri | Optionnel | URI de redirection de l’application dans laquelle vous avez reçu le code d’autorisation. |
| jeton_de_actualisation | Obligatoire | Jeton d’actualisation d’origine que vous avez acquis dans le second tronçon du flux. |
Un jeton de réponse correct se présente ainsi :
{
"not_before": "1442340812",
"token_type": "Bearer",
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
"scope": "00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
"expires_in": "3600",
"refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
| Paramètre | Descriptif |
|---|---|
| pas_avant | Heure à laquelle le jeton est considéré comme valide, en heure epoch. |
| type_de_jeton | Valeur du type de jeton. Le seul type pris en charge par Microsoft Entra ID est Porteur. |
| jeton d'accès | Le JWT signé que vous avez demandé. |
| portée | Étendues de validité du jeton. Vous pouvez également utiliser les périmètres pour mettre en cache des jetons en vue d’une utilisation ultérieure. |
| expires_in | Durée de validité du jeton (en secondes). |
| jeton_de_actualisation | Un jeton d’actualisation OAuth 2.0. L’application peut utiliser ce jeton pour acquérir des jetons supplémentaires après l’expiration du jeton actuel. Les jetons d’actualisation sont de longue durée et peuvent être utilisés pour conserver l’accès aux ressources pendant des périodes prolongées. Pour plus d’informations, consultez la référence du jeton Azure AD B2C. |
Les réponses d’erreur ressemblent à ceci :
{
"error": "access_denied",
"error_description": "The user revoked access to the app.",
}
| Paramètre | Descriptif |
|---|---|
| erreur | Chaîne de code d’erreur que vous pouvez utiliser pour classer les types d’erreurs qui se produisent. Vous pouvez également utiliser la chaîne pour réagir aux erreurs. |
| description de l'erreur | Un message d’erreur spécifique qui peut vous aider à identifier la cause principale d’une erreur d’authentification. |
Utiliser votre propre annuaire Azure AD B2C
Pour essayer ces demandes vous-même, procédez comme suit. Remplacez les exemples de valeurs que nous avons utilisés dans cet article par vos propres valeurs.
- Créez un annuaire Azure AD B2C. Utilisez le nom de votre répertoire dans les requêtes.
- Créez une application pour obtenir un ID d’application et un URI de redirection. Incluez un client natif dans votre application.
- Créez vos flux d’utilisateurs pour obtenir vos noms de flux d’utilisateurs.