Décrivez-moi le flux de code d'autorisation OAuth 2.0.

OAuth 2.0 déroute beaucoup de candidats car ils le confondent avec la connexion. OAuth concerne l'autorisation déléguée — permettre à une application d'agir sur une ressource au nom de l'utilisateur — et non d'identifier l'utilisateur (c'est OIDC, posé par-dessus). Le flux de code d'autorisation est la valeur par défaut sécurisée.

Le flux, étape par étape

1. Redirection vers l'autorisation. L'application envoie le navigateur de l'utilisateur vers le serveur d'autorisation avec son identifiant client, les portées demandées, une URI de redirection et une valeur state (protection CSRF).
2. L'utilisateur s'authentifie et consent. L'utilisateur se connecte au serveur d'autorisation — l'application ne voit jamais le mot de passe — et approuve les portées demandées.
3. Code renvoyé. Le serveur d'autorisation redirige vers l'URI enregistrée de l'application avec un code d'autorisation de courte durée, à usage unique dans la chaîne de requête.
4. Échange par canal arrière. Le backend de l'application envoie ce code, plus son secret client, au point de terminaison de jeton et reçoit un jeton d'accès (et souvent un jeton de rafraîchissement). Cette étape se déroule de serveur à serveur, pas dans le navigateur.
5. Appeler l'API. L'application utilise le jeton d'accès comme identifiant porteur pour appeler le serveur de ressources.

Pourquoi cette conception

L'idée clé est que le puissant jeton d'accès ne transite jamais par le navigateur ni par une URL, où il pourrait être journalisé, mis en cache ou fuité via les en-têtes de référent. Seul le code de faible valeur et de courte durée le fait, et le code est inutile sans le secret client. C'est pourquoi le flux de code est préféré au flux implicite désormais déprécié, qui exposait les jetons directement dans la redirection.

PKCE pour les clients publics

Les applications mobiles et les SPA ne peuvent pas conserver de secret client. PKCE (Proof Key for Code Exchange) corrige cela : le client envoie un code_challenge aléatoire haché au départ et le code_verifier correspondant lors de l'échange de jeton, prouvant que le même client ayant lancé le flux le termine — ainsi un code volé ne peut pas être échangé par un attaquant.

Ce que recherchent les recruteurs

La séquence redirection/consentement/code/échange-par-canal-arrière, la raison pour laquelle les jetons restent hors du navigateur, le flux de code plutôt que l'implicite, et PKCE pour les clients qui ne peuvent pas conserver de secret. Bonus pour avoir noté qu'OAuth est de l'autorisation et OIDC de l'authentification.