CerberAuthCerberAuth

Qu'est-ce que PKCE et pourquoi l'utiliser ?

Emmanuel Gautier Emmanuel Gautier ·
OAuth 2.0

Utiliser le flux Authorization Code avec OAuth 2.0 est un moyen sûr d’authentifier les utilisateurs et d’obtenir des jetons d’accès. Cependant, ce flux est vulnérable aux attaques par interception, en particulier lorsqu’il est utilisé par des clients publics comme les applications mobiles ou les applications monopages.

Pour atténuer ce risque, l’extension Proof Key for Code Exchange (PKCE) a été introduite dans le protocole OAuth 2.0.

Quel est le risque ?

Lors de l’utilisation du flux Authorization Code, l’application cliente échange un code d’autorisation contre un jeton d’accès. Ce code est généralement envoyé via une URI de redirection depuis le serveur d’autorisation vers l’application cliente. Si un attaquant intercepte ce code, il peut l’utiliser pour obtenir un jeton d’accès, puis usurper l’identité de l’utilisateur.

Flux Authorization Code OAuth 2.0 lors d'une attaque par interception

Qu’est-ce que PKCE ?

PKCE (prononcé « pixy ») est une extension du flux Authorization Code d’OAuth 2.0 qui apporte une sécurité supplémentaire pour les clients publics. Il est conçu pour se protéger contre les attaques par interception de code en garantissant que le code d’autorisation ne peut être échangé contre un jeton d’accès que par le client qui a initié la demande d’autorisation.

Comment fonctionne PKCE ?

Lorsqu’un client initie le flux Authorization Code avec PKCE, il génère un code verifier et un code challenge. Ce code verifier n’est connu que du Relying Party et peut être vérifié via le code d’autorisation. Ce mécanisme permet au serveur d’autorisation de vérifier le code d’autorisation lors de son échange contre des jetons.

Voici comment PKCE fonctionne en pratique :

  1. Génération d’un Code Verifier : le client génère une chaîne aléatoire cryptographique à haute entropie appelée code verifier.
code_verifier = "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk"
  1. Création d’un Code Challenge : le client crée ensuite un code challenge dérivé du code verifier. Cela se fait généralement via un hash SHA-256 du code verifier, ensuite encodé en base64-url.
code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
  1. Demande d’autorisation : le client inclut le code challenge et la méthode utilisée pour le créer (généralement S256) dans la demande d’autorisation envoyée au serveur d’autorisation.
GET /authorize?response_type=code&client_id=abcd1234&redirect_uri=https://mydomain.com/callback&code_challenge=CODE_CHALLENGE&code_challenge_method=S256

  1. Réponse du serveur d’autorisation : le serveur d’autorisation authentifie l’utilisateur et renvoie un code d’autorisation au client.

  2. Demande de jeton : le client envoie le code d’autorisation ainsi que le code verifier au endpoint de jeton.

POST /token
Content-Type: application/x-www-form-urlencoded


grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=https://mydomain.com/callback&client_id=abcd1234&code_verifier=CODE_VERIFIER
  1. Réponse du jeton : le serveur d’autorisation vérifie le code verifier par rapport au code challenge et, si valide, émet un jeton d’accès.

En utilisant PKCE, le code d’autorisation ne peut être échangé contre un jeton d’accès que par le client ayant initié la demande, atténuant ainsi le risque d’attaques par interception.

Documentation et ressources

#authorization #oauth2