| Brique | Question | Contenu |
|---|---|---|
| Identification | Qui prétends-tu être ? | Identifiant unique, référentiel d’identités |
| Authentification (AuthN) | Le prouves-tu ? | Facteurs, MFA, SSO |
| Autorisation (AuthZ) | As-tu le droit ? | RBAC, ABAC, PoLP |
| Traçabilité (Accounting/Audit) | Qu’as-tu fait ? | Journalisation, revues |
Mnémonique : AAA (Authentication, Authorization, Accounting).
3 catégories de facteurs : ce que je sais (mot de passe, PIN), ce que je possède (téléphone, token, carte), ce que je suis (biométrie). + facteurs contextuels (localisation, appareil).
Hiérarchie de robustesse (à savoir classer) ⭐
Attaques à connaître : credential stuffing, password spraying, AiTM / Evilginx (vol de cookie de session → MFA contournée), vol de token / Pass-the-Cookie, consent phishing (OAuth), device code phishing. Contre-mesures : FIDO2, liaison du token à l’appareil (token binding / device-bound), Conditional Access avec conformité de l’appareil, réduction des durées de session pour les rôles sensibles, détection d’anomalies (impossible travel, nouvel appareil).
Mots de passe — position moderne (NIST SP 800-63B / ANSSI) : longueur > complexité, pas de rotation périodique forcée sans indice de compromission, blocage des mots de passe compromis (listes type HIBP), pas d’indices, gestionnaire de mots de passe encouragé, entropie ≥ 80 bits pour les comptes sans autre mesure. ANSSI : recommandations selon le contexte (avec/sans mesure de blocage des tentatives). NIST 800-63 AAL1/2/3 et IAL1/2/3 (assurance d’identité) : bon vocabulaire à placer.
| Protocole | Type | Usage | À retenir |
|---|---|---|---|
| Kerberos | AuthN | AD interne | Tickets TGT/TGS, KDC, mutual auth, horloge ±5 min |
| NTLM | AuthN | Legacy Windows | Challenge/response, à désactiver (relay, pass-the-hash) |
| LDAP / LDAPS | Annuaire | Requêtes, bind | Signature LDAP + channel binding contre le relay |
| SAML 2.0 | Fédération | SSO web entreprise | Assertions XML, IdP/SP, POST binding ; attention signature wrapping, RelayState |
| OAuth 2.0 / 2.1 | Autorisation | Délégation d’accès API | Access token, scopes ; ce n’est PAS de l’authentification ⭐ |
| OIDC | AuthN sur OAuth2 | SSO moderne | ID token (JWT), nonce, sub ; flow Authorization Code + PKCE |
| SCIM | Provisioning | Cycle de vie des comptes SaaS | Automatise create/update/deactivate |
| RADIUS / 802.1X / EAP-TLS | Accès réseau | NAC, WiFi | EAP-TLS par certificat > PEAP/MSCHAPv2 |
| FIDO2 / CTAP / WebAuthn | AuthN | Sans mot de passe | Paire de clés par origine, résistant au phishing |
| mTLS | AuthN mutuelle | Machine-to-machine, mesh | Certificats des deux côtés |
Piège récurrent : « OAuth sert-il à authentifier ? » → Non, OAuth 2.0 autorise l’accès à une ressource ; c’est OIDC (couche au-dessus) qui authentifie. Utiliser un access token pour authentifier = anti-pattern (confused deputy).
Flows OAuth : Authorization Code (+ PKCE — recommandé partout, y compris SPA/mobile), Client Credentials (M2M), Device Code (TV/CLI — attention au phishing), Implicit et Password/ROPC : dépréciés.