Déroulez-moi le flux OAuth authorization code avec PKCE.

Le client génère un verifier aléatoire, le hache en un code challenge, et redirige l'utilisateur vers le serveur d'autorisation avec ce challenge. L'utilisateur s'authentifie, est redirigé avec un code à usage unique, et le client échange ce code plus le verifier d'origine contre des tokens. Comme l'échange exige le verifier, un code intercepté ne sert à rien. OAuth 2.1 impose PKCE pour tous les clients, publics comme confidentiels.

Le client commence par générer un verifier à forte entropie et le hache en SHA-256 pour fabriquer le code challenge. Il envoie l'utilisateur vers le serveur d'autorisation avec l'identifiant client, l'URI de redirection, les scopes, une valeur state et ce challenge. L'utilisateur se connecte et consent, et le serveur d'autorisation redirige avec un code de courte durée. Le client poste ensuite ce code et le verifier brut sur l'endpoint de token, le serveur hache le verifier et vérifie qu'il correspond au challenge qu'il avait stocké, et seulement là il émet des tokens. C'est tout l'intérêt de PKCE : un code volé dans une redirection, un log ou une application malveillante sur l'appareil ne peut pas être échangé sans le verifier, qui n'a jamais quitté le client. Je valide quand même state séparément, parce que ça couvre le CSRF sur le callback plutôt que l'interception du code. Si je fais du login plutôt que de l'accès à une API, je m'intéresse à l'ID token OIDC et je valide sa signature, son émetteur, son audience et son nonce avant de faire confiance à la moindre claim.