4. Protocole

4.1 Le client crée un vérificateur de code

Le client crée d'abord un vérificateur de code "code_verifier" pour chaque demande d'autorisation OAuth 2.0 [RFC6749].

4.2 Le client crée le défi de code

Le client crée ensuite un défi de code (code challenge) dérivé du vérificateur de code en utilisant l'une des transformations suivantes :

plain

code_challenge = code_verifier

S256

code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))

Si le client est capable d'utiliser "S256", il doit utiliser "S256", car "S256" est obligatoire à implémenter (MTI) sur le serveur.

4.3 Le client envoie le défi de code avec la demande d'autorisation

Le client envoie le défi de code dans la demande d'autorisation OAuth 2.0 avec les paramètres supplémentaires suivants :

code_challenge : REQUIS. Défi de code.

code_challenge_method : OPTIONNEL, par défaut "plain". Méthode de transformation : "S256" ou "plain".

4.4 Le serveur retourne le code

Lorsque le serveur émet le code d'autorisation, il doit associer les valeurs "code_challenge" et "code_challenge_method" au code d'autorisation.

4.4.1 Réponse d'erreur

Si le serveur require PKCE et que le client n'envoie pas "code_challenge", le point de terminaison d'autorisation doit retourner une réponse d'erreur avec "error" défini sur "invalid_request".

4.5 Le client envoie le code d'autorisation et le vérificateur de code

À la réception du code d'autorisation, le client envoie la demande de jeton d'accès au point de terminaison de jeton avec le paramètre supplémentaire :

code_verifier : REQUIS. Vérificateur de code.

4.6 Le serveur vérifie code_verifier avant de retourner les jetons

Le serveur vérifie le code_verifier en calculant le défi de code et en le comparant au "code_challenge" précédemment associé.

---