Qu'est-ce que PKCE : des concepts de base à une compréhension approfondie

Preuve de clé pour l'échange de code (PKCE) est une extension du flux de code d'autorisation, il a été initialement conçu pour sécuriser le flux de code d'autorisation dans les applications mobiles, et il est maintenant recommandé pour être utilisé par les applications monopages également. À partir d'OAuth 2.1, PKCE est imposé pour tous les types de clients, y compris les clients publics et les clients confidentiels (privés).

Dans cet article, nous allons vous aider à comprendre pourquoi PKCE a été créé et comment il protège vos applications, vous donnant une compréhension approfondie de PKCE.

Pourquoi PKCE est-il nécessaire ?#

Dans le flux OAuth 2.0 de code d'autorisation, les utilisateurs demandent à se connecter via une application. Le serveur d'authentification dirige les utilisateurs vers une page d'authentification. Après l'authentification de l'utilisateur, le serveur retourne un code d'autorisation à l'application, qui utilise ensuite ce code pour demander un jeton d'accès au serveur d'authentification.

Ce flux présente un risque de sécurité important : le code d'autorisation peut être intercepté par des programmes malveillants. Cela est particulièrement préoccupant sur les appareils mobiles, où d'autres applications peuvent enregistrer le même URI de redirection et intercepter le code d'autorisation.

Le processus d'interception est illustré dans le diagramme ci-dessous :

Étape (1) : L'application effectue une demande d'autorisation via une API sécurisée qui ne peut pas être interceptée. À cette étape, le demandeur fournit également un URI de redirection.

Étape (2) : La demande est ensuite transmise au serveur d'autorisation OAuth 2.0. Comme OAuth nécessite l'utilisation de TLS, cette communication est protégée par TLS et ne peut pas être interceptée.

Étape (3) : Le serveur d'autorisation retourne le code d'autorisation.

Étape (4.a) : le code d'autorisation est retourné au demandeur via l'URI de redirection fourni à l'étape (1). À cette étape, si l'application malveillante s'est enregistrée comme un gestionnaire pour l'URI de redirection, elle peut alors intercepter le code d'autorisation. Avec le code d'autorisation, l'attaquant peut demander et obtenir un jeton d'accès aux étapes (5.a) et (6.a), respectivement.

Comme indiqué ci-dessus, dans le flux de code d'autorisation OAuth 2.0, si le code d'autorisation est intercepté, les attaquants peuvent l'utiliser pour obtenir des jetons d'accès. Par conséquent, nous avons besoin d'un mécanisme pour empêcher l'interception des codes d'autorisation, ce qui a conduit à la création de PKCE.

Comment fonctionne PKCE ?#

Comme mentionné ci-dessus, si nous voulons éviter d'être attaqués, nous devons nous assurer que seule l'application qui a initié la demande peut demander et obtenir le jeton d'accès. C'est là que PKCE entre en jeu.

PKCE résout ce problème en introduisant un concept de "preuve de clé".

Lors de la demande d'un code d'autorisation, l'application génère d'abord un vérificateur de code aléatoire et le stocke localement. Elle convertit ensuite ce vérificateur de code en un défi de code en utilisant des algorithmes spécifiques. L'application envoie à la fois le défi de code et la méthode du défi de code au serveur d'authentification lors de la demande de code d'autorisation.

Le vérificateur de code est une chaîne générée aléatoirement, et le défi de code est dérivé du vérificateur de code par conversion. Deux méthodes de conversion sont prises en charge :

• plain : utilise directement le vérificateur de code comme défi de code

• S256 : applique un hachage SHA-256 au vérificateur de code, suivi par un encodage Base64URL. Comme le résultat du hachage ne peut pas être inversé pour obtenir le vérificateur de code, et parce que la méthode plain pourrait être vulnérable aux attaques de type homme-du-milieu pendant la transmission, l'utilisation de S256 est fortement recommandée pour des raisons de sécurité.

Après l'authentification de l'utilisateur, le serveur d'authentification retourne le code d'autorisation à l'application. Lors de la demande d'un jeton d'accès, l'application envoie à la fois le code d'autorisation et le vérificateur de code au serveur d'authentification. Le serveur transforme le "vérificateur de code" en utilisant la "méthode de défi de code" précédemment reçue et compare le résultat avec le "défi de code" précédemment reçu pour vérifier la possession par le client du "vérificateur de code".

Étape (1-3) : L'application crée et enregistre un secret nommé le "vérificateur de code" et dérive une version transformée "défi de code", qui est envoyé dans la demande d'autorisation OAuth 2.0 avec la méthode de transformation "méthode de défi de code".

Étape (3-6) : Le Serveur Auth répond comme d'habitude mais enregistre le "défi de code" et la "méthode de défi de code".

Étape (7.a) : L'application envoie ensuite le code d'autorisation à l'endpoint du jeton comme d'habitude mais inclut le secret "vérificateur de code" généré à l'étape (1).

Étape (8.a-9.a) : Le serveur d'autorisation transforme "vérificateur de code" en "défi de code" et le compare avec le "défi de code" de l'étape (1-3). L'accès est refusé s'ils ne sont pas égaux.

Dans ce cas, même si l'application malveillante a intercepté le code d'autorisation à l'étape (6.b), elle est incapable de l'échanger contre un jeton d'accès, car elle ne possède pas le secret "vérificateur de code", et comme le "vérificateur de code" est envoyé via TLS, il ne peut pas être intercepté.

Résumé#

Cet article explique comment fonctionne PKCE et pourquoi il est nécessaire pour protéger le flux de code d'autorisation. En ajoutant un mécanisme de preuve de clé, PKCE empêche les applications malveillantes d'intercepter et de détourner les codes d'autorisation. J'espère que cette explication vous aide à comprendre PKCE en profondeur.