Comprendre le duo OAuth 2.0 et OpenID Connect
Microsoft Entra ID, anciennement Azure AD, repose sur deux standards ouverts qu'il ne faut jamais confondre. OAuth 2.0 est un framework d'autorisation : il définit comment une application obtient le droit d'accéder à une ressource au nom d'un utilisateur. OpenID Connect (OIDC) est une surcouche d'authentification construite sur OAuth 2.0 : il répond à la question « qui est cet utilisateur ? ».
Cette distinction n'est pas théorique. Elle détermine le type de jeton que votre application doit demander, l'endpoint à appeler et la manière de valider la réponse. Une application qui confond les deux finit souvent par utiliser un ID Token pour appeler une API, ce qui échoue systématiquement côté validation.
Microsoft Identity Platform v2.0
Ce modèle correspond au endpoint v2.0 de la plateforme d'identité Microsoft, celui utilisé par défaut pour toute nouvelle inscription d'application dans le portail Microsoft Entra admin center. L'ancien endpoint Azure AD v1.0 reste supporté pour compatibilité mais n'est plus recommandé pour de nouveaux développements.
Les acteurs impliqués dans un scénario d'authentification
Quatre acteurs interviennent systématiquement dans un flux Entra ID :
- L'utilisateur : s'authentifie avec ses identifiants, potentiellement renforcés par l'authentification multifacteur (MFA) ou une méthode sans mot de passe comme Windows Hello for Business.
- L'application cliente : web app, mobile, Single Page Application (SPA), client desktop ou service daemon sans interaction utilisateur.
- Les API : Microsoft Graph, une API métier personnalisée exposée dans Entra ID, ou une API tierce.
- Microsoft Entra ID : agit comme fournisseur d'identité (Identity Provider) et émet l'ensemble des jetons.
OAuth 2.0 délivre des Access Tokens consommés par les API. OpenID Connect délivre des ID Tokens qui identifient l'utilisateur auprès de l'application cliente. Cette complémentarité permet à la fois un accès sécurisé aux ressources et une expérience de Single Sign-On (SSO) cohérente entre applications Microsoft et applications tierces enregistrées dans le tenant.
Le flux Authorization Code, la référence pour les applications modernes
Le Authorization Code Flow reste le scénario recommandé pour la majorité des applications web, mobiles et desktop. Il évite qu'un jeton transite en clair par le navigateur, contrairement aux flux implicites aujourd'hui déconseillés.
Redirection vers l'endpoint /authorize
L'utilisateur tente d'accéder à l'application. Celle-ci redirige le navigateur vers l'endpoint /authorize de Microsoft Entra ID, avec les paramètres client_id, scope, redirect_uri et response_type=code.
Authentification de l'utilisateur
L'utilisateur s'authentifie via le moyen configuré dans la stratégie d'accès conditionnel : mot de passe, MFA ou Windows Hello. Entra ID évalue au passage les politiques de Conditional Access applicables.
Retour du code d'autorisation
Une fois l'authentification validée, Entra ID redirige l'utilisateur vers le redirect_uri déclaré dans l'inscription d'application, avec un code d'autorisation à courte durée de vie.
Échange du code contre des jetons
L'application appelle l'endpoint /token en back-channel pour échanger ce code contre des jetons. Trois jetons peuvent être émis à ce stade : l'ID Token, l'Access Token et le Refresh Token.
1POST /oauth2/v2.0/token HTTP/1.12Host: login.microsoftonline.com3Content-Type: application/x-www-form-urlencoded4 5grant_type=authorization_code6&client_id={client_id}7&code={code_recu}8&redirect_uri={redirect_uri}9&client_secret={client_secret}Appel de l'API avec l'Access Token
L'application transmet l'Access Token dans l'en-tête Authorization: Bearer de chaque appel API. L'API valide la signature du jeton, son expiration et son audience (claim aud) avant de retourner les données.
PKCE obligatoire pour les clients publics
Pour les SPA et applications mobiles, Microsoft impose l'extension PKCE (Proof Key for Code Exchange). Sans secret client fiable, PKCE empêche l'interception du code d'autorisation en générant un couple code_verifier / code_challenge propre à chaque tentative de connexion.
Les endpoints exposés par Microsoft Entra ID
Toute intégration OAuth 2.0 / OIDC repose sur un jeu d'endpoints normalisés, tous accessibles sous login.microsoftonline.com/{tenant} :
| Endpoint | Rôle | Utilisation typique |
|---|---|---|
| /authorize | Authentifie l’utilisateur et accorde l’autorisation | Point d’entrée du flux Authorization Code |
| /token | Émet les jetons (ID, Access, Refresh) | Échange du code ou renouvellement de session |
| /.well-known/openid-configuration | Discovery Endpoint : expose les métadonnées OIDC | Configuration automatique des librairies MSAL |
| JWKS Endpoint | Publie les clés publiques de signature | Validation cryptographique des jetons côté API |
| UserInfo (Microsoft Graph) | Retourne le profil de l’utilisateur connecté | Complément d’information après authentification |
Choisir le bon flux selon le type d'application
Le choix du flux OAuth 2.0 dépend directement de la nature de l'application cliente. Un mauvais choix expose inutilement des secrets ou complexifie la maintenance.
| Flux | Cas d’usage | Interaction utilisateur |
|---|---|---|
| Authorization Code Flow | Applications web, mobiles et desktop confidentielles | Oui |
| Authorization Code + PKCE | SPA et applications mobiles publiques | Oui |
| Client Credentials Flow | Communication service à service, daemons | Non |
| Device Code Flow | CLI, appareils IoT sans navigateur | Oui (sur un autre appareil) |
| On-Behalf-Of (OBO) | API appelant une autre API pour le compte de l’utilisateur | Non (délégation transitive) |
| Refresh Token Flow | Renouvellement silencieux d’une session existante | Non |
Le Client Credentials Flow est réservé aux scénarios sans utilisateur, souvent avec un service principal ou une managed identity. Le flux On-Behalf-Of intervient dans les architectures à API en chaîne, typiquement une API métier qui relaie un appel vers Microsoft Graph avec le contexte de l'utilisateur d'origine.
Les trois types de jetons et leur rôle exact
Chaque jeton émis par Microsoft Entra ID a une finalité précise, et les confondre est une source fréquente d'erreurs 401 côté API :
- ID Token : jeton JWT (JSON Web Token) au format OIDC, contient les claims d'identité (
sub,name,oid,tid). Il sert exclusivement l'application cliente pour établir la session et le SSO, jamais pour appeler une API. - Access Token : porte les scopes et permissions accordés (
https://graph.microsoft.com/User.Readpar exemple). C'est le seul jeton à transmettre aux API dans l'en-têteAuthorization. - Refresh Token : permet d'obtenir un nouvel Access Token sans repasser par une authentification interactive. Sa durée de vie et ses conditions de révocation sont pilotées par les stratégies de session configurables dans Entra ID.
Validation côté API
Une API ne doit jamais se contenter de décoder un jeton : elle doit vérifier la signature via les clés du JWKS Endpoint, contrôler l'expiration (exp), l'audience (aud) et l'émetteur (iss). Les librairies Microsoft.Identity.Web pour .NET ou MSAL couvrent ces vérifications nativement.
Points clés à retenir
- OAuth 2.0 gère l'autorisation et produit des Access Tokens pour les API ; OpenID Connect gère l'authentification et produit des ID Tokens pour l'application.
- Le Authorization Code Flow, complété par PKCE pour les clients publics, reste le scénario de référence recommandé par Microsoft.
- Le choix du flux (Client Credentials, Device Code, On-Behalf-Of, Refresh Token) dépend strictement du type d'application et de la présence ou non d'un utilisateur interactif.
- Les endpoints
/authorize,/token, le Discovery Endpoint et le JWKS Endpoint forment le socle technique de toute intégration. - Ne jamais utiliser un ID Token pour appeler une API : seul l'Access Token porte les scopes nécessaires.
Pour approfondir l'implémentation concrète, la documentation officielle détaille chaque flux avec des exemples de requêtes HTTP : Microsoft identity platform and OAuth 2.0 authorization code flow et Microsoft identity platform and OpenID Connect protocol.
