OAuth 2.0 : Open Authorization 2.0
Sécurité
OAuth 2.0 : Open Authorization 2.0. « Autorisation ouverte », par analogie avec la clé de voiturier qui démarre la voiture sans ouvrir le coffre ni la boîte à gants. Ce protocole de délégation permet à une application d'agir sur un compte au nom de son propriétaire, avec des droits bornés, sans jamais voir son mot de passe.
Quatre rôles : La norme (RFC 6749) distingue le propriétaire de la ressource, le client qui demande l'accès, le serveur d'autorisation qui délivre les jetons et le serveur de ressources qui les vérifie. Le mot de passe ne transite qu'entre l'utilisateur et le serveur d'autorisation.
Jetons et portées : Le client reçoit un jeton d'accès à courte durée de vie, limité à des portées (scopes) précises, et parfois un jeton de rafraîchissement pour en obtenir un nouveau sans redemander le consentement. On révoque un jeton sans toucher au mot de passe.
Autorisation, pas authentification : OAuth 2.0 dit ce qu'un client a le droit de faire, pas qui est l'utilisateur ; c'est OpenID Connect qui ajoute l'identité par-dessus. Se servir d'un jeton d'accès comme preuve d'identité revient à accepter un ticket de vestiaire comme pièce d'identité : ça marche, jusqu'au jour où quelqu'un d'autre le tend au guichet.
Flux recommandé : Le flux par code d'autorisation, protégé par PKCE, est la référence pour tous les types de clients. Les flux implicite et par mot de passe sont déconseillés par les bonnes pratiques de sécurité (RFC 9700) et retirés d'OAuth 2.1.
Ce qui arrive si on s'en passe
Sans délégation OAuth 2.0, une application tierce qui doit agir sur un compte n'a qu'une voie : recevoir le mot de passe de son propriétaire et le conserver. Elle obtient alors tous les droits du compte, sans périmètre ni durée : lire, modifier, supprimer, changer les paramètres de sécurité. Toute fuite de la base de cette application livre des identifiants complets, réutilisables sur d'autres services si le même mot de passe y sert. Retirer l'accès à une seule application impose de changer le mot de passe, ce qui coupe toutes les autres en même temps. Côté fournisseur, les journaux ne distinguent plus les actions de l'application de celles du titulaire : une opération suspecte ne peut plus être attribuée, et aucun client précis ne peut être révoqué. Enfin, l'authentification multifacteur devient soit un obstacle qui casse l'intégration, soit une protection qu'on désactive pour la faire fonctionner.
Explication de la marmotte
Imagine que tu veux qu'une appli de retouche récupère tes photos rangées sur un autre site. Tu pourrais lui donner ton mot de passe, mais elle aurait alors accès à tout, exactement comme toi. Avec ce système, tu passes plutôt par le site qui garde tes photos : il te demande si tu es d'accord, puis remet à l'appli un badge temporaire qui ouvre seulement le tiroir des photos. C'est comme la carte d'un hôtel : elle ouvre ta chambre, pas le coffre de la réception, et elle ne marche plus après ton départ. Ton mot de passe, lui, ne quitte jamais le site d'origine.
Où ce terme est utilisé
- Faille Facebook Voir en tant que 2018 et vol de jetons d'accès (5 occurrences)
- Le flux OAuth avec PKCE en une page (4 occurrences)
- Partage de données inter-organisations par API (4 occurrences)
- Gérer les accès externes des prestataires (3 occurrences)
- Requête d'autorisation poussée et signée (PAR, JAR) (3 occurrences)
- DPoP : attacher un jeton d'accès à une clé que le porteur doit prouver détenir (2 occurrences)
- FAPI 2.0 : ce qu'un profil de sécurité interdit, et pourquoi (2 occurrences)
- Flux par code d'appareil : l'autorisation sur la télévision, et son hameçonnage (2 occurrences)
- Gérer la durée de vie des jetons OAuth (2 occurrences)
- Pièges OAuth 2.1 : PKCE, redirections et scopes (2 occurrences)