OAuth expliqué : rôles, flux PKCE et OAuth vs SAML
OAuth expliqué
Qu'est-ce qu'OAuth ? Rôles, flux PKCE, OAuth vs SAML vs OIDC | We.Inc
OAuth 2.0 en termes simples : les quatre rôles, le flux authorization code avec PKCE étape par étape, les scopes, et ce qui distingue OAuth d'OpenID Connect et de SAML.
OAuth 2.0 est un standard qui permet à une application d'agir en votre nom auprès d'un autre service sans jamais voir votre mot de passe. Vous approuvez une demande sur la propre page de connexion du service, et l'application reçoit un jeton d'accès limité aux scopes que vous avez acceptés. Il gère l'autorisation ; OpenID Connect ajoute la connexion par-dessus.
OAuth 2.0 vs OpenID Connect vs SAML 2.0
OAuth 2.0
OpenID Connect
SAML 2.0
Répond à
À quoi cette application peut-elle accéder ?
Qui est cet utilisateur ?
Qui est cet utilisateur ?
Élément principal
Jeton d'accès
ID token (un JWT) plus jeton d'accès
Assertion XML
Spécification
RFC 6749 (IETF)
OpenID Connect Core 1.0
OASIS SAML 2.0
Parties
Client, serveur d'autorisation, serveur de ressources
Relying party, fournisseur OpenID
Fournisseur de services, fournisseur d'identité
Usage typique
Accès aux API, « connectez votre compte »
Boutons « Se connecter avec », connexion mobile et SPA
Authentification unique (SSO) en entreprise
Avant OAuth, relier deux services impliquait souvent de saisir le mot de passe de l'un dans l'autre. OAuth a remplacé cela par des jetons de courte durée, aux droits étroitement limités, émis seulement après votre accord. Le générateur ci-dessous crée un vrai verifier et un vrai challenge PKCE dans votre navigateur et construit l'URL d'autorisation, pour que vous voyiez chaque paramètre utilisé par le flux.
L'application crée un code_verifier aléatoire, le hache en code_challenge, puis vous envoie vers le serveur d'autorisation avec ce challenge, son client_id, les scopes et une valeur state.
Vous vous connectez sur la page du serveur d'autorisation et approuvez les scopes.
Le serveur vous redirige vers la redirect_uri de l'application avec un code d'autorisation de courte durée et le même state.
L'application vérifie state, puis envoie le code et le code_verifier d'origine au token endpoint.
Le serveur hache le verifier, le compare au challenge enregistré et renvoie un jeton d'accès que l'application transmet à l'API.
Utilisez le flux authorization code avec PKCE aussi bien pour les applications monopages que pour les applications mobiles et serveur.
Envoyez et vérifiez toujours state, que la spécification OAuth recommande pour empêcher la falsification de requête intersite (CSRF).
Demandez les scopes les plus restreints qui suffisent ; les gens approuvent plus volontiers les petites demandes.
Enregistrez des redirect URI exactes. Les jokers et les redirections ouvertes sont un moyen classique de voler des jetons.
Gardez les secrets client uniquement sur le serveur. Une application navigateur ou mobile ne peut pas garder un secret.
Questions fréquentes
OAuth sert-il à l'authentification ou à l'autorisation ?
À l'autorisation. Un jeton d'accès indique ce qu'une application peut faire, pas qui est l'utilisateur, et les API peuvent même ne pas vous le dire. Quand vous avez besoin de l'identité de la personne, utilisez OpenID Connect, qui renvoie un ID token signé avec des claims comme sub, iss, aud et exp.
Qu'est-ce que PKCE et en ai-je besoin ?
PKCE (RFC 7636) lie le code d'autorisation à l'application qui a lancé le flux. L'application envoie d'abord le hachage d'un secret aléatoire, puis le secret lui-même plus tard, de sorte qu'un code volé est inutilisable. Utilisez S256, que les serveurs doivent prendre en charge, plutôt que plain.
Quelle est la différence entre OAuth et SAML ?
SAML est un standard plus ancien basé sur XML, dans lequel un fournisseur d'identité envoie une assertion signée sur l'utilisateur à un fournisseur de services, surtout pour l'authentification unique en entreprise dans le navigateur. OAuth émet des jetons pour l'accès aux API et fonctionne bien pour les applications mobiles et les API. OpenID Connect est l'équivalent le plus proche, dans le monde OAuth, de la connexion SAML.
Que sont les scopes ?
Les scopes sont les permissions demandées par une application, écrites sous forme de liste de chaînes séparées par des espaces, sensibles à la casse et définies par le serveur d'autorisation, par exemple openid email ou repo read:user. L'écran de consentement les affiche, et le jeton ne couvre que ce qui a été approuvé.
Dois-je encore utiliser le flux implicit ?
Non pour tout nouveau projet. Il renvoyait les jetons dans le fragment de l'URL, d'où ils peuvent fuiter via l'historique et les journaux. Le flux authorization code avec PKCE offre aux applications navigateur la même simplicité sans cette exposition.
Les quatre rôles
La RFC 6749 nomme quatre parties. Le propriétaire de la ressource, c'est vous. Le client est l'application qui demande l'accès. Le serveur d'autorisation vérifie votre identité et émet les jetons. Le serveur de ressources héberge l'API qui accepte ces jetons. Souvent, une même entreprise gère les deux serveurs, mais ce sont deux rôles distincts.
Pourquoi l'échange de code existe
La redirection vers l'application passe par le navigateur, un endroit où tout ce qui a de la valeur peut fuiter. La redirection ne transporte donc qu'un code à usage unique, dont la spécification recommande l'expiration sous 10 minutes. Le vrai jeton est récupéré par un appel direct au token endpoint.
PKCE comble la faille restante. Même si un logiciel malveillant ou un proxy de journalisation capture le code, il ne peut pas l'échanger sans le verifier, qui n'a jamais quitté l'application.
La place d'OpenID Connect
OpenID Connect est une fine couche au-dessus d'OAuth. Ajoutez openid aux scopes, ce que la spécification OIDC rend obligatoire, et la réponse du jeton contient aussi un ID token : un JWT signé qui décrit l'utilisateur. Un nonce envoyé dans la requête et renvoyé dans l'ID token protège contre le rejeu.
Le flux authorization code avec PKCE
Chaque étape et les paramètres qu'elle transporte
Étape
De vers
Paramètres clés
1. Demande d'autorisation
Application vers serveur d'autorisation (redirection du navigateur)
access_token, token_type, expires_in, refresh_token facultatif (et id_token avec OIDC)
6. Appel d'API
Application vers serveur de ressources
Authorization: Bearer <access_token>
PKCE en code
Créer un verifier et un challenge S256 dans le navigateur
32 octets aléatoires encodés en base64url donnent un verifier de 43 caractères, la longueur minimale autorisée par la RFC 7636.
Échanger le code contre des jetons
S'exécute après la redirection. Comparez d'abord state, puis envoyez le verifier enregistré avec le code.
Générateur PKCE et d'URL d'autorisation
Crée un nouveau code_verifier et son code_challenge S256 avec la cryptographie de votre navigateur, puis assemble une URL d'autorisation à partir de vos réglages. Rien n'est envoyé ; l'endpoint ci-dessous est un exemple à remplacer.
Endpoint d'autorisation
Scopes (séparés par des espaces)
Nouveau verifier
code_verifier ({n} caractères, à garder secret jusqu'à l'étape 4)