Fondamentaux
OAuth2, OpenID Connect et JWT
OAuth2, OpenID Connect et JWT apparaissent dans beaucoup d'applications modernes. Ils servent à déléguer des accès, connecter des utilisateurs et transporter des informations d'identité ou d'autorisation.
Vue d'ensemble
Ces trois notions sont proches, mais différentes.
| Notion | Rôle |
|---|---|
| OAuth2 | Délégation d'accès |
| OpenID Connect | Authentification au-dessus d'OAuth2 |
| JWT | Format de token souvent utilisé |
OAuth2 ne dit pas directement "qui est l'utilisateur". Il permet surtout à une application d'obtenir un accès limité à une ressource. OpenID Connect ajoute une couche d'identité.
Exemple courant
Utilisateur
│
Application
│
Fournisseur d'identité
│
API protégée
L'utilisateur se connecte chez un fournisseur d'identité. L'application reçoit ensuite des tokens lui permettant d'identifier l'utilisateur ou d'appeler une API selon les droits accordés.
Les rôles OAuth2
| Rôle | Description |
|---|---|
| Resource Owner | Utilisateur ou propriétaire de la ressource |
| Client | Application qui demande l'accès |
| Authorization Server | Serveur qui émet les tokens |
| Resource Server | API qui protège la ressource |
Cette séparation évite qu'une application ait besoin de connaître le mot de passe de l'utilisateur pour accéder à une ressource.
Tokens fréquents
| Token | Usage |
|---|---|
| Access token | Appeler une API |
| ID token | Identifier l'utilisateur avec OpenID Connect |
| Refresh token | Obtenir un nouvel access token |
Un access token doit être court et limité. Un refresh token est plus sensible, car il peut permettre de prolonger l'accès.
Scopes et permissions
Les scopes décrivent les droits demandés ou accordés.
Exemples :
profileemailread:messageswrite:settings
Le serveur doit toujours vérifier que le token contient les droits nécessaires avant d'exécuter une action.
JWT
Un JWT est souvent composé de trois parties encodées.
header.payload.signature
Il peut contenir des informations comme :
- identifiant utilisateur
- émetteur
- audience
- date d'expiration
- scopes
- rôle
Attention
Un JWT est généralement lisible par celui qui le possède. Il ne faut pas y mettre de secret ou de donnée sensible inutile.
Vérifications importantes
Un serveur qui reçoit un token doit vérifier :
- signature
- algorithme attendu
- expiration
- émetteur
- audience
- scopes ou permissions
- révocation si nécessaire
Accepter un token sans vérifier correctement ces éléments revient à faire confiance à une donnée potentiellement manipulée.
Erreurs fréquentes
- confondre access token et ID token
- stocker des tokens sensibles dans le mauvais endroit
- donner des scopes trop larges
- accepter des tokens expirés
- ne pas vérifier l'audience
- exposer un secret client dans le front-end
- utiliser des durées de vie trop longues
- journaliser des tokens complets
Où stocker les tokens
Le stockage dépend de l'architecture. Il n'existe pas une réponse universelle.
Points à considérer :
- sensibilité du token
- application web ou mobile
- risque XSS
- risque CSRF
- durée de vie
- possibilité de révocation
Pour une application web classique, les sessions côté serveur avec cookies HttpOnly, Secure et SameSite restent souvent plus simples à maîtriser.
À retenir
OAuth2 délègue l'accès, OpenID Connect ajoute l'identité, et JWT est un format de token. La sécurité dépend surtout des vérifications, des scopes, du stockage et de la durée de vie.