OAuth2 : définition, rôles, PKCE et différence avec OIDC
OAuth2 est un framework d’autorisation. OAuth.net le décrit comme le protocole standard de l’industrie pour l’autorisation, avec des flux adaptés aux applications web, desktop, mobiles et autres appareils. Le mot clé est autorisation, pas authentification pure.
Les rôles
Le resource owner possède les données. Le client est l’application qui demande l’accès. L’authorization server délivre les tokens. Le resource server héberge l’API protégée. Confondre ces rôles mène à de mauvais schémas de sécurité.
Code + PKCE
Pour une application moderne, le flux Authorization Code avec PKCE est souvent préférable, surtout pour les clients publics qui ne peuvent pas garder un secret serveur. PKCE ajoute une preuve liée à la demande initiale et réduit le risque d’interception du code.
OAuth2 ou OpenID Connect ?
OAuth2 donne un accès à une ressource. OpenID Connect ajoute une couche d’identité et un ID token pour savoir qui est l’utilisateur. Si votre besoin est “connecte-toi avec Google”, vous parlez souvent d’OIDC au-dessus d’OAuth2. Si votre besoin est “autorise mon app à lire ton calendrier”, OAuth2 est le socle.
Piège
Évitez le stockage durable des jetons dans le navigateur ; choisissez un stockage et un flux adaptés au type de client. Prévoyez expiration, refresh token si nécessaire, scopes minimaux et révocation.
Scopes et consentement
Un scope décrit ce que l’application demande : lire un profil, envoyer un email, écrire dans un calendrier. Demandez le minimum. Un scope trop large augmente le risque si le token fuit et effraie l’utilisateur au moment du consentement. Pour une automatisation interne, documentez les scopes utilisés et la raison métier de chacun.
Tokens
L’access token possède une durée de validité définie par le service. Le refresh token sert à obtenir un nouvel access token sans refaire tout le parcours utilisateur. Il est donc plus sensible. Quand l’architecture comporte un backend, protégez-le côté serveur ; pour un client public, suivez les recommandations du fournisseur sur le stockage et la rotation. Prévoyez sa révocation. Ne mettez jamais un client secret dans une application distribuée côté utilisateur.
Erreur de vocabulaire
Dire “OAuth connecte l’utilisateur” est un raccourci dangereux. OAuth autorise un accès. L’identité fiable vient d’OpenID Connect ou d’un endpoint utilisateur prévu par le fournisseur. Cette distinction évite de bâtir une connexion sur un token qui ne prouve pas ce que vous croyez.
Ce que vous autorisez réellement
Une portée, ou scope, décrit une permission demandée. Lire un agenda et modifier cet agenda sont deux besoins différents. L’écran de consentement doit être cohérent avec l’usage annoncé. Refuser une permission ne devrait pas conduire l’application à réclamer le mot de passe du compte comme solution de secours.
Dans un parcours par code d’autorisation, le navigateur ramène un code vers l’application ; celle-ci l’échange auprès du serveur d’autorisation contre des jetons. Le jeton d’accès sert ensuite à appeler l’API. Le code, l’access token et l’ID token éventuel ne sont pas interchangeables.
Expiration et révocation
Un jeton expiré ne signifie pas forcément que le compte a disparu. L’application peut renouveler l’accès si elle possède un refresh token valide et si le service l’autorise. Une permission révoquée ou un renouvellement refusé doit au contraire conduire à une reconnexion explicite. Les journaux doivent expliquer l’erreur sans publier les jetons. OAuth ne dispense ni du HTTPS ni de la validation stricte des redirections.