L'authentification, premier périmètre de sécurité
Choisir un mécanisme d'authentification inadapté expose directement une application aux compromissions d'identité. Dans les environnements Microsoft 365 et Azure, ce choix conditionne aussi bien la conformité réglementaire que l'expérience utilisateur finale. Voici un tour d'horizon structuré des neuf approches à connaître, des plus fondamentales aux plus avancées.
Les briques de base : mot de passe, MFA et JWT
Authentification par mot de passe
L'authentification par identifiant/mot de passe reste le socle de la grande majorité des applications existantes. Sa simplicité d'implémentation a un revers : utilisée seule, elle constitue le vecteur d'attaque le plus courant (phishing, brute force, credential stuffing). Dans Microsoft Entra ID, les politiques de protection par mot de passe permettent de bloquer les valeurs faibles ou connues, mais cela ne suffit pas en isolation.
Authentification multifacteur (MFA)
La MFA (Multi-Factor Authentication) exige la présentation d'au moins deux facteurs de vérification distincts :
- Ce que l'utilisateur connaît (mot de passe, PIN)
- Ce qu'il possède (code OTP via Microsoft Authenticator, clé FIDO2)
- Ce qu'il est (biométrie)
Dans Entra ID, la MFA s'active via les Conditional Access policies. Son déploiement réduit drastiquement le risque de compromission de compte, même en cas de fuite de mot de passe.
Attention aux SMS OTP
Les codes envoyés par SMS restent vulnérables aux attaques SIM-swapping. Privilégiez une application d'authentification ou une clé matérielle FIDO2 pour les comptes à privilèges.
JSON Web Token (JWT)
Le JWT (JSON Web Token) structure un jeton en trois parties encodées en Base64 et séparées par des points : Header, Payload et Signature. Ce format compact permet de transmettre des revendications d'identité entre services sans re-interroger un annuaire à chaque requête. Dans Microsoft Entra ID, les access tokens émis pour Microsoft Graph sont des JWT signés par la plateforme d'identité Microsoft.
Exemple de décodage du payload d'un token Entra ID :
1{2 "oid": "<object-id>",3 "upn": "user@contoso.com",4 "roles": ["Mail.Read"],5 "exp": 17000000006}Le champ exp indique la date d'expiration Unix — vérifiez-le systématiquement côté serveur.
Délégation et accès aux API : OAuth 2.0, OIDC et API Key
OAuth 2.0
OAuth 2.0 est un framework d'autorisation déléguée, pas d'authentification. Le client obtient un access token auprès d'un serveur d'autorisation (dans Azure : la plateforme d'identité Microsoft) sans jamais manipuler les identifiants de l'utilisateur. Les scopes déclarent précisément les ressources accessibles.
Les quatre grants principaux :
authorization_code(applications web et mobiles)client_credentials(services machine-to-machine)device_code(appareils sans navigateur)on_behalf_of(délégation entre services)
Implicit grant deprecated
Le grant implicit est déprécié dans la plateforme d'identité Microsoft. Migrez vers authorization_code avec PKCE (Proof Key for Code Exchange) pour les SPA et les applications mobiles.
OpenID Connect (OIDC)
OpenID Connect (OIDC) est une couche d'identité construite au-dessus d'OAuth 2.0. Elle introduit l'ID Token — un JWT signé par l'OIDC Provider — qui contient les attributs de l'utilisateur (sub, email, name). C'est le protocole utilisé par défaut dans Microsoft Entra ID pour l'authentification des utilisateurs dans les applications modernes.
Clé API (API Key)
La clé API (header X-API-KEY ou paramètre de requête) authentifie un client applicatif auprès d'une API sans flux OAuth. Simple à implémenter, elle convient aux intégrations internes ou aux webhooks. Ses limites sont connues : pas de rotation automatique native, pas de portée fine, révocation manuelle. Dans Azure API Management, les abonnements intègrent ce mécanisme avec une gestion centralisée des clés.
Mécanismes avancés : mTLS, SAML et biométrie
mTLS — Mutual TLS
Le mTLS (Mutual Transport Layer Security) impose une authentification bidirectionnelle par certificat numérique : le serveur présente son certificat au client, et le client présente le sien au serveur. Ce mécanisme garantit qu'aucune des deux parties ne peut usurper l'identité de l'autre. Dans Azure, Azure API Management supporte le mTLS pour sécuriser les communications entre services.
| Mécanisme | Direction | Cas d'usage typique | Complexité opérationnelle |
|---|---|---|---|
| TLS standard | Serveur → Client | HTTPS classique | Faible |
| mTLS | Bidirectionnelle | Service-to-service, Zero Trust | Élevée (gestion des certs) |
SAML 2.0
SAML (Security Assertion Markup Language) version 2.0 est un standard XML pour la fédération d'identité entre un Service Provider (SP) et un Identity Provider (IdP). Il reste dominant dans les entreprises ayant des applications legacy ou des partenaires qui n'ont pas migré vers OIDC. Microsoft Entra ID supporte SAML 2.0 en tant qu'IdP, ce qui permet d'intégrer des applications SaaS ne supportant pas encore OIDC.
SAML vs OIDC
Pour une nouvelle application, privilégiez OIDC : protocole plus léger, tokens JSON au lieu de XML volumineux, et meilleure compatibilité avec les architectures API-first. SAML reste pertinent pour les applications existantes et les fédérations inter-entreprises.
Authentification biométrique
L'authentification biométrique vérifie l'identité via des traits biologiques uniques : empreinte digitale, reconnaissance faciale, voix. Dans l'écosystème Microsoft, Windows Hello for Business implémente la biométrie côté poste de travail avec un stockage local des données — elles ne transitent jamais vers un serveur distant. Sur mobile, les SDK Android et iOS exposent ces capacités aux applications via des API standardisées. Microsoft Entra ID reconnaît les connexions Windows Hello comme des authentifications sans mot de passe (passwordless).
Choisir la bonne combinaison selon le contexte
Aucune méthode ne couvre tous les scénarios. La robustesse vient de leur combinaison :
- Applications métier internes : OIDC + MFA + Conditional Access
- APIs machine-to-machine :
client_credentialsOAuth 2.0 ou mTLS - Intégrations legacy SSO : SAML 2.0 fédéré via Entra ID
- Postes de travail managés : Windows Hello for Business (passwordless)
- APIs publiques ou partenaires : API Key via Azure API Management avec rotation planifiée
Dans une architecture Zero Trust, l'identité devient le périmètre. Chaque accès est évalué en continu — peu importe si la requête provient du réseau interne ou externe.
Points clés à retenir
- JWT : validez toujours la signature et le champ
expcôté serveur. - OAuth 2.0 : le grant
implicitest déprécié — utilisezauthorization_code+ PKCE. - OIDC à préférer à SAML pour toute nouvelle intégration.
- mTLS apporte une authentification bidirectionnelle indispensable dans les architectures Zero Trust service-to-service.
- Windows Hello for Business élimine le mot de passe sans sacrifier la sécurité.
- MFA par SMS est moins robuste qu'une application d'authentification ou une clé FIDO2.
La documentation de référence sur les protocoles supportés par Microsoft Entra ID est disponible sur Microsoft Learn — Protocoles d'authentification.
