Remettons tout cela en musique et replaçons les choses de façon compréhensible.
+----------------------------+
| OpenID |
| (authentification) |
+----------------------------+
│
▼
+----------------------------+
| OpenID Connect | → Authentifie l’utilisateur
| (OIDC = OAuth2 + ID) | + fournit un ID Token (JWT)
+----------------------------+
│
▼
+----------------------------+
| OAuth 2.0 | → Autorise un accès à des ressources
| (protocoel d’autorisation) | via Access Token
+----------------------------+
│
▼
+----------------------------+
| OAuth 1.0 | → Ancien protocole (signatures complexes)
+----------------------------+
🗝️ OIDC repose sur OAuth 2.0 comme une extension normalisée, en y ajoutant une couche d’identité.
⚙️ Les briques et leurs rôles
| Brique | Rôle principal | Ce qu’elle fournit |
|---|---|---|
| OAuth 1.0 | Autorisation avec signature HMAC (obsolète) | Access Token signé |
| OAuth 2.0 | Délégation d’accès à des ressources (API) | Access Token (et Refresh Token) |
| OIDC | Authentification fédérée (qui est l’utilisateur) | ID Token (JWT) + profil utilisateur |
🔄 Les flux types
OAuth 2.0 — Authorization Code Flow
[Client] → [Authorization Server] → [Resource Server]
1. L'utilisateur autorise l'accès à ses ressources.
2. Le client obtient un "authorization code".
3. Le client échange ce code contre un Access Token.
4. Le client utilise cet Access Token pour appeler une API (Resource Server).
🎯 Objectif : accéder à des ressources au nom de l’utilisateur.
📦 Résultat : Access Token (aucune info d’identité).
OIDC — Authorization Code Flow (avec PKCE)
[Client/RP] ↔ [User Agent] ↔ [OpenID Provider]
1. RP redirige vers l’OP : scope=openid + code_challenge
2. L’utilisateur s’authentifie (login/MFA)
3. OP renvoie un "authorization code" au RP
4. RP échange ce code contre :
- Access Token (OAuth)
- ID Token (JWT → identité)
- Optionnellement Refresh Token
5. RP valide le ID Token → utilisateur authentifié
🎯 Objectif : identifier l’utilisateur (pas seulement l’autoriser).
📦 Résultat : ID Token (JWT signé, contient l’identité).
🧭 Résumé conceptuel
| Objectif | Protocole | Jetons impliqués | Sert à |
|---|---|---|---|
| Déléguer un accès à une API | OAuth 2.0 | Access / Refresh Tokens | Autorisation |
| Authentifier un utilisateur | OIDC (extension OAuth 2.0) | ID Token (+ Access Token) | Authentification |
| Ancienne base historique | OAuth 1.0 | Access Token signé | Prédécesseur d’OAuth 2 |
🔐 Vue simplifiée du flux global
[Utilisateur]
│
▼
[Application cliente (RP)]
│ (redirection / login)
▼
[OpenID Provider (OP)]
│ Authentifie l’utilisateur
▼
(Retourne Access Token + ID Token)
│
▼
[Application RP] → [API / Ressources protégées]
Access Token : autorise à appeler les API
- Access Token : autorise à appeler les API
- ID Token : prouve qui est l’utilisateur
- OIDC = OAuth2 + identité vérifiée