OAuth 2.0 est un protocole de délégation d'autorisation : il permet à une application d'accéder à une ressource au nom d'un utilisateur, sans détenir ses identifiants. L'utilisateur consent à une portée d'accès précise, et l'application reçoit un jeton d'accès limité dans le temps et dans ses droits.
Les rôles et le flux
Le protocole distingue quatre rôles : le propriétaire de la ressource (l'utilisateur), le client (l'application demandeuse), le serveur d'autorisation qui émet les jetons, et le serveur de ressources qui les vérifie.
Le flux recommandé pour les applications web et mobiles est le code d'autorisation avec PKCE : l'utilisateur s'authentifie auprès du serveur d'autorisation, un code à usage unique est renvoyé au client, qui l'échange contre un jeton d'accès et, éventuellement, un jeton de rafraîchissement.
L'erreur à ne pas commettre
OAuth 2.0 n'authentifie pas l'utilisateur auprès de l'application. Un jeton d'accès signifie « ce porteur a le droit d'appeler telle API », pas « cet utilisateur est bien untel ». Construire une connexion sur le seul OAuth 2.0 conduit à des failles connues, notamment la substitution de jeton. La couche d'identité normalisée est OpenID Connect, qui ajoute un jeton d'identité signé et destiné à un client précis.
Autre point de vigilance : le jeton est un porteur (bearer). Quiconque le détient l'utilise. D'où l'importance de sa durée de vie, de son stockage et, pour les opérations sensibles, d'une validation portant sur l'action elle-même.
Aller plus loin : définition d'OpenID Connect · identification, authentification, autorisation · définition du vol de token · l'authentification cognitive