L’IAM (Identity and Access Management) répond à trois questions fondamentales : qui êtes-vous, pouvez-vous le prouver, et qu’avez-vous le droit de faire ? Ces trois piliers — identification, authentification, autorisation — structurent tous les systèmes de sécurité modernes. Sans maîtrise de ce vocabulaire, impossible de configurer correctement un IdP, de déboguer un problème SSO, ou de concevoir une architecture sécurisée.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »Ce guide pose les fondations de l’IAM (Identity and Access Management). À la fin, vous saurez :
- Distinguer les différents types d’identités (humain, service, machine)
- Différencier authentification (AuthN), autorisation (AuthZ) et audit
- Comprendre le rôle de chaque composant : IdP, SP, RP
- Choisir entre sessions serveur et tokens selon votre architecture
Prérequis : aucun. Ce guide s’adresse aux débutants complets en IAM.
Pourquoi l’IAM est incontournable
Section intitulée « Pourquoi l’IAM est incontournable »Chaque application doit répondre à trois questions :
- Qui es-tu ? → Authentification
- Qu’as-tu le droit de faire ? → Autorisation
- Qu’as-tu fait ? → Audit
L’IAM (Identity and Access Management) regroupe les processus, outils et politiques qui répondent à ces questions. Sans IAM structuré, vous accumulez des comptes orphelins, des permissions excessives et des failles de sécurité.
Identité, compte et principal
Section intitulée « Identité, compte et principal »Ces trois termes sont souvent confondus. Clarifions.
Identité
Section intitulée « Identité »Une identité représente une entité du monde réel : une personne, une application, une machine. C’est le “qui” abstrait.
Un compte (ou compte utilisateur) est la représentation technique d’une identité dans un système. Une même personne peut avoir plusieurs comptes (compte entreprise, compte personnel, compte admin…).
Principal
Section intitulée « Principal »Un principal est l’entité qui s’authentifie à un instant T. C’est le “sujet” d’une requête. Le principal peut être :
- Un utilisateur humain (alice@example.com)
- Un service account (api-backend@example.com)
- Une workload identity (pod Kubernetes, fonction Lambda)
- Une machine (serveur, IoT)
| Concept | Ce que c’est | Exemple |
|---|---|---|
| Identité | Entité du monde réel | Alice Martin, développeuse |
| Compte | Représentation dans un système | alice.martin@corp.com dans Azure AD |
| Principal | Sujet authentifié d’une requête | Le token JWT avec sub=alice.martin |
AuthN / AuthZ / Audit : le triptyque fondamental
Section intitulée « AuthN / AuthZ / Audit : le triptyque fondamental »Authentification (AuthN)
Section intitulée « Authentification (AuthN) »L’authentification répond à : “Qui es-tu ?”
Elle vérifie l’identité d’un principal en demandant une preuve :
- Ce que tu sais (mot de passe, PIN)
- Ce que tu possèdes (téléphone, clé FIDO2)
- Ce que tu es (empreinte, visage)
Résultat : un principal authentifié (identité confirmée).
Autorisation (AuthZ)
Section intitulée « Autorisation (AuthZ) »L’autorisation répond à : “Qu’as-tu le droit de faire ?”
Elle détermine les permissions du principal authentifié :
- Peut-il lire cette ressource ?
- Peut-il modifier ce paramètre ?
- Peut-il supprimer cet utilisateur ?
Résultat : une décision (autorisé / refusé).
Audit (Logging)
Section intitulée « Audit (Logging) »L’audit répond à : “Qu’as-tu fait ?”
Il trace les actions pour :
- Détection d’intrusions
- Conformité réglementaire (RGPD, SOX, PCI-DSS)
- Investigation post-incident
| Étape | Question | Résultat |
|---|---|---|
| AuthN | Qui es-tu ? | Principal authentifié |
| AuthZ | Qu’as-tu le droit de faire ? | Décision allow/deny |
| Audit | Qu’as-tu fait ? | Log d’événement |
SSO, fédération et les acteurs
Section intitulée « SSO, fédération et les acteurs »Single Sign-On (SSO)
Section intitulée « Single Sign-On (SSO) »Le SSO (Single Sign-On) permet à un utilisateur de s’authentifier une seule fois pour accéder à plusieurs applications.
Avantages :
- Moins de mots de passe à retenir (et à oublier)
- Expérience utilisateur fluide
- Point central de révocation des accès
Analogie : c’est comme un bracelet de festival. Vous passez une fois au contrôle d’entrée, et ensuite vous accédez à toutes les scènes sans repasser au guichet.
Fédération
Section intitulée « Fédération »La fédération étend le SSO au-delà des frontières de l’organisation. Elle permet à des entités distinctes de faire confiance aux identités des autres.
Exemple : “Se connecter avec Google” sur un site tiers. Le site fait confiance à Google pour authentifier l’utilisateur.
Les acteurs de la fédération
Section intitulée « Les acteurs de la fédération »| Acteur | Rôle | Exemple |
|---|---|---|
| Identity Provider (IdP) | Authentifie les utilisateurs, émet des assertions | Keycloak, Okta, Azure AD |
| Service Provider (SP) | Application qui consomme les assertions (SAML) | Salesforce, GitLab |
| Relying Party (RP) | Application qui consomme les tokens (OIDC) | Application React, API |
| Authorization Server | Émet les tokens d’accès (OAuth) | Keycloak, Auth0 |
Flux simplifié
Section intitulée « Flux simplifié »
Sessions vs Tokens
Section intitulée « Sessions vs Tokens »Deux approches pour maintenir l’état d’authentification après le login.
Sessions côté serveur
Section intitulée « Sessions côté serveur »Le serveur stocke l’état de la session. Le client ne reçoit qu’un identifiant de session (cookie).
Avantages :
- Révocation immédiate (supprimer la session)
- Pas de données sensibles côté client
Inconvénients :
- Nécessite un store partagé pour le scaling (Redis, DB)
- Sticky sessions ou réplication
Tokens (Bearer tokens)
Section intitulée « Tokens (Bearer tokens) »Le token contient les informations d’identité. Le serveur est stateless.
Avantages :
- Stateless : pas de store à maintenir
- Scale naturellement : chaque serveur peut valider le token
- Adapté aux microservices et APIs
Inconvénients :
- Révocation difficile (attendre l’expiration ou maintenir une blocklist)
- Token potentiellement volumineux
Tableau de décision
Section intitulée « Tableau de décision »| Critère | Sessions | Tokens |
|---|---|---|
| Révocation immédiate | ✅ Oui | ⚠️ Difficile |
| Scaling horizontal | ⚠️ Store partagé | ✅ Natif |
| Microservices | ⚠️ Complexe | ✅ Adapté |
| Données sensibles | Serveur | ⚠️ Potentiellement client |
| Taille des requêtes | Petit (cookie ID) | Plus grand (token complet) |
Niveaux d’assurance (NIST 800-63)
Section intitulée « Niveaux d’assurance (NIST 800-63) »Le NIST SP 800-63 définit des niveaux d’assurance pour qualifier la confiance dans une identité.
Identity Assurance Level (IAL)
Section intitulée « Identity Assurance Level (IAL) »Confiance dans le processus de vérification d’identité (qui est vraiment cette personne ?).
| Niveau | Vérification |
|---|---|
| IAL1 | Auto-déclaration (email seul) |
| IAL2 | Vérification à distance (pièce d’identité + selfie) |
| IAL3 | Vérification en personne |
Authenticator Assurance Level (AAL)
Section intitulée « Authenticator Assurance Level (AAL) »Confiance dans le processus d’authentification (c’est bien cette personne qui se connecte ?).
| Niveau | Facteurs requis |
|---|---|
| AAL1 | 1 facteur (mot de passe seul) |
| AAL2 | 2 facteurs (mot de passe + OTP) |
| AAL3 | 2 facteurs dont 1 hardware (clé FIDO2) |
Federation Assurance Level (FAL)
Section intitulée « Federation Assurance Level (FAL) »Confiance dans le protocole de fédération.
| Niveau | Exigences |
|---|---|
| FAL1 | Assertion signée |
| FAL2 | Assertion chiffrée + signée |
| FAL3 | Holder-of-key (preuve de possession cryptographique) |
Erreurs fréquentes
Section intitulée « Erreurs fréquentes »| Erreur | Conséquence | Solution |
|---|---|---|
| Confondre AuthN et AuthZ | Permissions mal gérées | Séparer clairement les deux phases |
| Ignorer les identités machines | Comptes de service non gouvernés | Inclure les service accounts dans l’IGA |
| SSO sans révocation centralisée | Accès persistants après départ | Désactiver le compte IdP = tout révoquer |
| Tokens sans expiration courte | 24h d’accès post-compromission | Access tokens courts (15-60 min) |
À retenir
Section intitulée « À retenir »Références
Section intitulée « Références »- NIST SP 800-63-4 — Digital Identity Guidelines
- Verizon DBIR 2024 — Data Breach Investigations Report