OAuth 2.0 est un protocole standard de délégation d'autorisation. Il permet à une application d'accéder à des ressources d'un utilisateur sur un autre service sans connaître son mot de passe, au moyen d'un jeton d'accès (access token) à portée limitée.
⚠️ Point souvent mal compris : OAuth 2.0 gère l'autorisation (« quels droits ? »), pas l'authentification (« qui es-tu ? »). Pour l'authentification, c'est la surcouche OpenID Connect qui s'en charge.
Les quatre rôles du protocole :
| Rôle | Description |
|---|---|
| Resource Owner | L'utilisateur, propriétaire des données |
| Client | L'application qui demande l'accès |
| Authorization Server | Émet les jetons (ex. Entra ID) |
| Resource Server | L'API qui héberge les ressources protégées |
Le flow le plus sûr et le plus courant, l'Authorization Code :
1. Client ─▶ redirige l'utilisateur vers l'Authorization Server
2. Utilisateur ─▶ consent (autorise l'accès)
3. Authorization Server ─▶ renvoie un code d'autorisation
4. Client ─▶ échange le code contre un access_token
5. Client ─▶ appelle l'API avec : Authorization: Bearer {token}À retenir
OAuth 2.0 est le socle de l'autorisation sur le web (« Se connecter avec Google / Microsoft »). Le jeton d'accès est souvent un JWT à durée de vie courte. Ne confondez jamais OAuth (autorisation) et OIDC (authentification) : ils travaillent ensemble mais répondent à deux questions différentes.
Termes connexes : OpenID Connect, JWT, SSO.
