OAuth 2.0 : le standard d'autorisation du web moderne
OAuth 2.0 est un protocole d'autorisation qui permet a une application tierce d'obtenir un acces limite aux ressources d'un utilisateur sur un service, sans que l'utilisateur n'ait a partager ses identifiants. C'est le protocole utilise quand vous cliquez "Se connecter avec Google" ou "Autoriser cette application".
Les roles dans OAuth 2.0
- Resource Owner : l'utilisateur qui possede les donnees (vous)
- Client : l'application qui veut acceder aux donnees (une app tierce)
- Authorization Server : le serveur qui authentifie l'utilisateur et delivre les tokens (Google, GitHub, etc.)
- Resource Server : le serveur qui heberge les donnees protegees (l'API)
Les flux d'autorisation (Grant Types)
Authorization Code : le flux le plus securise, recommande pour les applications web avec un backend. L'utilisateur est redirige vers le serveur d'autorisation, s'authentifie, puis un code est echange contre un token cote serveur.
Authorization Code + PKCE : extension du flux precedent pour les applications mobiles et SPA. PKCE (Proof Key for Code Exchange) ajoute une verification cryptographique pour prevenir l'interception du code.
Client Credentials : pour la communication machine-to-machine, sans utilisateur implique. Le client s'authentifie directement avec son ID et son secret.
Device Code : pour les appareils sans navigateur (TV, CLI). L'utilisateur s'authentifie sur un autre appareil en entrant un code affiche a l'ecran.
Les tokens
- Access Token : token a courte duree de vie (minutes/heures) qui autorise l'acces aux ressources. Souvent au format JWT.
- Refresh Token : token a longue duree de vie utilise pour obtenir un nouvel access token sans re-authentification. Doit etre stocke de maniere securisee.
Les scopes
Les scopes definissent le perimetre d'acces demande. Par exemple, une application peut demander le scope "read:email" pour lire l'email mais pas "write:profile" pour modifier le profil. L'utilisateur voit et approuve les scopes demandes.
OAuth 2.0 vs OpenID Connect
OAuth 2.0 gere l'autorisation (ce que vous pouvez faire). OpenID Connect (OIDC) est une couche d'identite construite au-dessus d'OAuth 2.0 qui gere l'authentification (qui vous etes). OIDC ajoute un ID Token contenant les informations de l'utilisateur.
Securite et bonnes pratiques
- Toujours utiliser HTTPS : les tokens transitent en clair dans les headers
- Valider les tokens cote serveur : verifier la signature, l'expiration, l'audience
- Utiliser des scopes minimaux : principe du moindre privilege
- Stocker les refresh tokens de maniere securisee : jamais dans le localStorage
- Implementer la rotation des refresh tokens : chaque utilisation genere un nouveau token