OAuth 2.0

OAuth 2.0 est un framework d’autorisation déléguée. Au lieu de donner votre mot de passe à une application, vous approuvez une demande auprès d’un serveur d’autorisation, qui délivre à l’application un jeton d’accès (access token) limité par un scope (par exemple orders:read) et dans le temps. L’application envoie ce jeton à l’API, généralement sous la forme Authorization: Bearer <token>. Les quatre rôles sont le propriétaire de la ressource (l’utilisateur), le client (l’application), le serveur d’autorisation (qui délivre les jetons) et le serveur de ressources (l’API).

Authentification ou autorisation

L’authentification répond à « qui êtes-vous ? ». L’autorisation répond à « qu’avez-vous le droit de faire ? ». OAuth 2.0 seul concerne l’autorisation : un jeton d’accès indique ce à quoi son porteur peut accéder, pas de façon fiable qui est l’utilisateur. Connecter les utilisateurs est le rôle d’OpenID Connect, une couche au-dessus d’OAuth 2.0 qui ajoute un ID token (un JWT) décrivant l’utilisateur. Les boutons « Se connecter avec… » utilisent OpenID Connect.

Types d’octroi (grant types) courants

• Authorization code avec PKCE : pour les applications qui agissent au nom d’un utilisateur, y compris les applications web et mobiles. L’utilisateur se connecte sur le serveur d’autorisation, l’application reçoit un code de courte durée et l’échange contre des jetons.
• Client credentials : pour les appels de service à service, sans utilisateur. C’est le flux le plus utilisé par les suites de tests d’API.
• Refresh token : échange un refresh token de longue durée contre un nouveau jeton d’accès.

Les octrois implicit et resource owner password sont déconseillés par les recommandations de sécurité OAuth actuelles et ont été supprimés dans le brouillon OAuth 2.1.

Exemple : client credentials

curl -X POST https://auth.example.com/oauth/token \
  -d grant_type=client_credentials \
  -d client_id="$CLIENT_ID" \
  -d client_secret="$CLIENT_SECRET" \
  -d scope=orders:read

La réponse contient un access_token, un token_type valant Bearer et un expires_in en secondes. Récupérez le jeton une seule fois dans une fixture, gardez-le en cache jusqu’à ce qu’il approche de son expiration, et stockez les secrets client dans les secrets de la CI plutôt que dans le dépôt.

Que tester

• Un jeton absent, expiré ou mal formé renvoie 401.
• Un jeton valide sans le scope requis renvoie 403.
• Les jetons émis pour une autre audience ou un autre client sont rejetés.
• Dans le flux authorization code, le paramètre state est vérifié et l’URI de redirection doit correspondre exactement à une valeur enregistrée.
• Les réponses de jeton et les redirections n’exposent jamais de jetons dans les logs ou les URL.