Flux de code d’autorisation OAuth 2.0 dans Azure Active Directory B2C

Vous pouvez utiliser l’octroi de code d’autorisation OAuth 2.0 dans les applications qui sont installées sur un appareil pour accéder à des ressources protégées, comme des API web. Grâce à l’implémentation Azure Active Directory B2C (Azure AD B2C) d’OAuth 2.0, vous pouvez ajouter l’inscription, la connexion et d’autres tâches de gestion des identités à vos applications monopages, à vos applications mobiles et à vos applications de bureau. Cet article est indépendant du langage. Il décrit comment envoyer et recevoir des messages HTTP sans utiliser de bibliothèque open source. Dans la mesure du possible, nous vous recommandons d’utiliser les bibliothèques d’authentification Microsoft (MSAL) prises en charge. Voir les exemples d’applications qui utilisent une 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 les activités d’authentification et d’autorisation avec la plupart des types d’applications, notamment les applications web, les applications monopages et les applications installées de façon native. Vous pouvez utiliser le flux de code d’autorisation OAuth 2.0 pour acquérir de manière sécurisée des jetons d’accès et des jetons d’actualisation pour vos applications, en vue d’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) après l’expiration du jeton d’accès, soit généralement au bout d’une heure.

Cet article est axé sur le flux de code d’autorisation OAuth 2.0 pour les clients publics. Un client public est une application cliente qui ne peut pas être approuvée pour maintenir de façon sécurisée l'intégrité d’un mot de passe secret. Cela comprend les applications monopages, les applications mobiles, les applications de bureau et quasiment toutes les applications qui ne s’exécutent pas sur un serveur.

Azure AD B2C étend les flux OAuth 2.0 standard pour proposer plus qu’une simple authentification et une simple autorisation. Il introduit le flux utilisateur. Avec les flux d’utilisateur, vous pouvez utiliser OAuth 2.0 pour ajouter des expériences utilisateur à votre application, comme 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 tester les requêtes HTTP de cet article :

1. Remplacez {tenant} par le nom de votre locataire Azure AD B2C.
2. Remplacez 90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 par l’ID d’application d’une application que vous avez précédemment inscrite dans votre locataire Azure AD B2C.
3. Remplacez {policy} par le nom d'une stratégie que vous avez créée dans votre locataire, par exemple b2c_1_sign_in.

Configuration de l’URI de redirection requise pour les applications monopages

Le flux de code d’autorisation pour des applications monopages requiert une configuration supplémentaire. Suivez les instructions permettant de créer votre application monopage pour marquer correctement votre URI de redirection comme étant activé pour CORS. Pour mettre à jour un URI de redirection afin d’activer CORS, vous pouvez cliquer sur l’invite de migration dans la section « Web » de l’onglet Authentification de l’inscription d’application. Vous pouvez également ouvrir l’éditeur de manifeste des inscriptions d’applications et définir le champ type de votre URI de redirection sur spa dans la section replyUrlsWithType.

Le type de redirection spa 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. Obtention d’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, dans laquelle l’utilisateur agit réellement. Dans cette demande, le client indique dans le paramètre scope les autorisations qu’il doit obtenir auprès de l’utilisateur. Les exemples suivants (avec sauts de ligne pour la lisibilité) montrent comment obtenir 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=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&response_type=code
&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob
&response_mode=query
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6%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

À ce stade, il est demandé à l’utilisateur d’effectuer le workflow du flux utilisateur. Il est possible que l’utilisateur doive entrer son nom d’utilisateur et son mot de passe, se connecter avec une identité sociale, s’inscrire à l’annuaire, etc. Les actions de l’utilisateur dépendent de la façon dont le flux d’utilisateur est défini.

Une fois que l’utilisateur a terminé le flux d’utilisateur, Microsoft Entra ID retourne une réponse à votre application avec la valeur que vous avez utilisée pour redirect_uri. Il utilise la méthode spécifiée dans le paramètre response_mode. La réponse est exactement la même pour chacun des scénarios d’actions utilisateur, indépendamment du flux d’utilisateur exécuté.

Une réponse correcte utilisant response_mode=query se présente ainsi :

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

Les réponses d’erreur peuvent également être envoyées à l’URI de redirection, pour que l’application puisse les traiter de façon 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

2. Obtention d’un jeton d’accès

Un code d’autorisation étant acquis, vous pouvez maintenant échanger code contre un jeton sur la ressource prévue en envoyant une demande POST au point de terminaison /token. Dans Azure AD B2C, vous pouvez demander des jetons d’accès pour les autres API comme d’habitude en spécifiant leurs étendues dans la requête.

Vous pouvez également demander un jeton d’accès pour l’API web de back-end de votre application par convention visant à utiliser l’ID client de l’application comme étendue demandée (ce qui génère un jeton d’accès avec cet ID client comme « public ») :

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=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
&code_verifier=ThisIsntRandomButItNeedsToBe43CharactersLong 

Si vous testez cette requête HTTP POST, vous pouvez utiliser n’importe quel client HTTP, comme Microsoft PowerShell ou Postman.

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

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}

Les réponses d’erreur ressemblent à ceci :

{
    "error": "access_denied",
    "error_description": "The user revoked access to the app.",
}

3. Utilisation du jeton

Un jeton d’accès étant acquis, vous pouvez maintenant l’utiliser dans les demandes effectuées à vos API web principales en l’incluant dans l’en-tête Authorization :

GET /tasks
Host: mytaskwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...

4. Actualisation du jeton

Les jetons d’accès et les jetons d’ID ont une courte durée de vie. Après leur expiration, vous devez les actualiser pour continuer à accéder aux ressources. Quand 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, envoyez une autre demande POST au point de terminaison /token. Cette fois, fournissez l’élément refresh_token au lieu de l’élément 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=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob

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

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}

Les réponses d’erreur ressemblent à ceci :

{
    "error": "access_denied",
    "error_description": "The user revoked access to the app.",
}

Utiliser votre propre annuaire Azure AD B2C

Pour essayer vous-même ces demandes, effectuez les étapes suivantes. Remplacez les exemples de valeurs que nous utilisons dans cet article par vos propres valeurs.

1. Créez un annuaire Azure AD B2C. Utilisez le nom de votre annuaire dans les demandes.
2. Créez une application pour obtenir un ID d’application et un URI de redirection. Incluez un client natif dans votre application.
3. Créez vos flux d’utilisateurs pour obtenir vos noms de flux utilisateur.