OAuth 2.0

OAuth 2.0 est le protocole standard d’autorisation déléguée — permettant à une application tierce d’accéder aux ressources que vous contrôlez sur un autre service sans donner votre mot de passe. « Se connecter avec Google », « Connecter votre compte GitHub », « Autoriser Zapier à accéder à votre Gmail » utilisent tous OAuth.

Les quatre rôles : propriétaire de la ressource (l’utilisateur), client (l’application tierce), serveur d’autorisation (le service émetteur OAuth, ex. accounts.google.com), serveur de ressources (l’API que le client veut appeler, ex. gmail.googleapis.com).

Le flux le plus courant (code d’autorisation avec PKCE) :

1. Le client redirige l’utilisateur vers le serveur d’autorisation.
2. L’utilisateur se connecte et approuve les portées demandées.
3. Le serveur d’autorisation redirige avec un code d’autorisation à usage unique.
4. Le client échange le code (plus le vérificateur PKCE) contre un jeton d’accès.
5. Le client appelle le serveur de ressources avec le jeton d’accès.

OAuth 2.0 ne gère que l’autorisation. OpenID Connect (OIDC) est la couche d’authentification par-dessus — elle ajoute un jeton d’identité (un JWT avec des claims sur l’identité de l’utilisateur) pour que le client sache qui s’est connecté. La plupart des flux modernes « Se connecter avec X » sont OIDC, pas du OAuth pur.

Pourquoi PKCE est désormais obligatoire pour les clients publics : le flux de code d’autorisation OAuth 2.0 d’origine supposait que le client pouvait garder un secret. Les applications mobiles et les applications à page unique ne le peuvent pas. PKCE (Proof Key for Code Exchange, RFC 7636) remplace le secret client statique par un vérificateur aléatoire par flux haché via SHA-256. PKCE est désormais requis pour tous les clients publics (OAuth 2.1, RFC 9700 BCP) et recommandé pour les clients confidentiels également.

Les quatre flux à connaître et les deux à éviter : utilisez Authorization Code + PKCE pour presque tout (web, mobile, SPA). Utilisez Client Credentials pour les appels API machine à machine. Les flux Implicit et Resource Owner Password Credentials sont tous deux dépréciés dans OAuth 2.1. Voir aussi : JWT, SAML. Référence : RFC 6749 — OAuth 2.0, RFC 7636 — PKCE.

Exemple concret

Un bouton « Connecter Slack » dans votre SaaS déclenche une redirection vers https://slack.com/oauth/v2/authorize?client_id=...&scope=chat:write,channels:read&redirect_uri=https://app.example.com/oauth/callback&state=xyz&code_challenge=BASE64URL(SHA256(verifier))&code_challenge_method=S256. L’utilisateur approuve ; Slack redirige vers https://app.example.com/oauth/callback?code=ONE_TIME_CODE&state=xyz. Votre backend envoie un POST à https://slack.com/api/oauth.v2.access avec le code, le vérificateur PKCE d’origine et l’identifiant client. Slack retourne {"access_token": "xoxb-...", "scope": "chat:write,channels:read", "team": {"id": "T123"}}. Vous stockez le jeton d’accès côté serveur et l’utilisez en tant que Authorization: Bearer xoxb-....

Pourquoi et quand cela importe

Les mauvaises configurations OAuth figurent parmi les catégories les plus exploitées en sécurité web moderne. Erreurs courantes : ne pas valider le paramètre state (active les CSRF sur le callback), autoriser des jokers dans l’enregistrement de redirect_uri, stocker des jetons d’accès dans le stockage accessible aux navigateurs. La Best Current Practice de sécurité OAuth 2.0 (RFC 9700, publiée en 2025) codifie les valeurs par défaut modernes : PKCE partout, URI de redirection correspondance exacte, jetons contraints par expéditeur. Référence : RFC 9700 — OAuth 2.0 Security BCP.