Français

oauth
flux implicite
code d'autorisation
PKCE

Flux implicite vs. Flux de code d'autorisation: Pourquoi le flux implicite est-il obsolète ?

Pourquoi existe-t-il un "flux de code d'autorisation" dans OAuth 2.0 alors que nous avons déjà le "flux implicite" ? Plongeons-nous dans les détails de ces deux types de permissions et découvrons pourquoi vous devriez éviter d'utiliser le flux implicite.

Darcy Ye

Developer

1/3/2024

Arrêtez de perdre des semaines sur l'authentification des utilisateurs

Lancez des applications sécurisées plus rapidement avec Logto. Intégrez l'authentification des utilisateurs en quelques minutes et concentrez-vous sur votre produit principal.

Commencer

Le flux de code d'autorisation et le flux implicite sont deux des types de permissions les plus couramment utilisés dans OAuth 2.0, permettant une autorisation utilisateur sécurisée et efficace pour les applications web. Les deux flux implémentent un processus d'autorisation qui permet aux utilisateurs d'accorder l'accès aux applications sans exposer leurs identifiants directement. Le flux implicite a été initialement développé pour répondre aux limitations des navigateurs, mais avec l'avènement des technologies web modernes, le flux de code d'autorisation est devenu le choix préféré de nombreux développeurs grâce à ses fonctionnalités de sécurité améliorées.

Dans cet article, nous explorerons les différences entre ces deux types de permissions et expliquerons pourquoi vous devriez éviter d'utiliser le flux implicite au profit du flux de code d'autorisation.

Qu'est-ce qu'OAuth 2.0 ?

Avant de plonger dans les détails de ces deux types de permissions, voyons d'abord ce qu'est OAuth 2.0 et pourquoi c'est essentiel pour les applications web modernes.

Quand on parle d'OAuth, on se réfère généralement à OAuth 2.0, connu sous le nom de "Open Authorization", qui est un protocole établi permettant aux sites web ou aux applications d'utiliser des ressources d'autres services web au nom d'un utilisateur. Il a succédé à OAuth 1.0 en 2012 et est depuis devenu la norme largement acceptée pour l'autorisation numérique. OAuth 2.0 est conçu pour fournir un accès contrôlé aux utilisateurs, permettant aux applications clientes des permissions spécifiques pour interagir avec des ressources représentant l'utilisateur, sans révéler les détails de connexion de l'utilisateur.

Bien que principalement utilisé dans les environnements web, le cadre d'OAuth 2.0 s'étend également à diverses formes de clients. Cela inclut les applications basées sur un navigateur, les applications web côté serveur, les applications natives ou mobiles, et même les appareils interconnectés, détaillant l'approche pour gérer l'accès délégué sur ces plateformes. Il introduit le concept de "types de permissions" pour définir le processus d'autorisation entre l'application cliente, l'utilisateur, et le serveur d'autorisation. Ces types de permissions sont utilisés pour déterminer comment l'application cliente peut obtenir un jeton d'accès pour accéder aux ressources de l'utilisateur. Les types de permissions les plus courants dans OAuth 2.0 sont :

Code d'autorisation : Idéal pour tous les types d'applications, en particulier les applications web côté serveur, où l'application cliente peut échanger un code d'autorisation contre un jeton d'accès et gérer les jetons de manière sécurisée.
Implicite : Un flux simplifié, conçu pour les applications basées sur un navigateur, sans composant serveur sécurisé. Il a été créé pour livrer rapidement des jetons aux applications clientes. Mais il est maintenant largement obsolète en raison de préoccupations de sécurité.
Identifiants du propriétaire de la ressource : Ce type permet à l'application cliente de demander et de recevoir un jeton d'accès directement en soumettant les identifiants de l'utilisateur (nom d'utilisateur et mot de passe). Étant donné que l'application cliente a un accès direct aux identifiants de l'utilisateur, ce type de permission est également considéré comme obsolète et doit être évité en toutes circonstances.
Identifiants client : Utilisé pour la communication machine-à-machine où l'application elle-même est le client. Cela implique que l'application s'authentifie auprès du serveur d'autorisation et demande un jeton d'accès pour accéder à ses propres ressources ou à celles d'un autre service.

Qu'est-ce que le flux implicite ?

Le flux implicite est un flux OAuth 2.0 simplifié où le jeton d'accès est renvoyé directement au client dans l'URI de redirection, sans étape supplémentaire pour échanger un code d'autorisation contre un jeton. Il a été conçu à l'origine pour les applications web qui ne pouvaient pas effectuer de requêtes côté serveur au point de terminaison du jeton en raison de restrictions de navigateur.

Comment fonctionne le flux implicite ?

L'utilisateur clique sur un bouton ou un lien dans l'application cliente pour initier le processus d'authentification.
L'application cliente redirige l'utilisateur vers le serveur d'autorisation pour s'authentifier, incluant le champ d'accès désiré.
Le serveur d'autorisation invite les utilisateurs à se connecter et à accorder l'autorisation à l'application cliente.
Après une authentification et une autorisation réussies, le serveur d'autorisation redirige le navigateur de l'utilisateur vers l'URI de redirection spécifiée du client, avec le jeton d'accès inclus dans le fragment d'URL.
L'application cliente extrait le jeton d'accès du fragment d'URL et l'utilise pour accéder aux ressources de l'utilisateur sur le serveur de ressources.

Risques de sécurité du flux implicite

Le flux implicite présente plusieurs vulnérabilités en matière de sécurité :

Exposition du jeton : Le jeton d'accès est renvoyé directement au client dans le fragment d'URL, qui peut être facilement intercepté par des parties malveillantes. Cela expose le jeton d'accès à un vol et à un usage abusif potentiels.
Attaques CSRF : Le flux implicite est sensible aux attaques de Cross-Site Request Forgery (CSRF), où des sites web malveillants peuvent inciter les utilisateurs à accorder un accès non autorisé à leurs comptes.

En raison de ces préoccupations de sécurité, le flux implicite n'est plus recommandé pour les applications web modernes. À la place, le flux de code d'autorisation avec PKCE (Proof Key for Code Exchange) est le choix privilégié pour une autorisation utilisateur sécurisée.

Qu'est-ce que le flux de code d'autorisation ?

Le flux de code d'autorisation, quant à lui, est un flux OAuth 2.0 plus sécurisé qui sépare le processus d'autorisation en deux étapes: l'application cliente obtient d'abord un code d'autorisation du serveur d'autorisation, puis échange le code contre un jeton d'accès. Ce flux a été conçu à l'origine pour les applications web côté serveur qui peuvent stocker en toute sécurité les identifiants clients et gérer les jetons d'accès. Avec l'introduction de l'extension PKCE, le flux de code d'autorisation peut désormais être utilisé dans les applications basées sur un navigateur également.

Comment fonctionne le flux de code d'autorisation pour les clients privés avec composant côté serveur ?

L'utilisateur clique sur un bouton ou un lien dans l'application cliente pour initier le processus d'authentification.
L'application cliente redirige l'utilisateur vers le serveur d'autorisation pour s'authentifier avec la portée d'accès désirée.
Le serveur d'autorisation invite les utilisateurs à se connecter et à accorder l'autorisation à l'application cliente.
Après une authentification et une autorisation réussies, le serveur d'autorisation renvoie un code d'autorisation au client.
L'application cliente échange en toute sécurité le code d'autorisation contre un jeton d'accès en effectuant une requête de serveur à serveur au point de terminaison du jeton en utilisant ses identifiants clients.
Le serveur d'autorisation valide le code d'autorisation et les identifiants clients et renvoie un jeton d'accès au client.
L'application cliente utilise le jeton d'accès pour accéder aux ressources de l'utilisateur sur le serveur de ressources.

Comment fonctionne le flux de code d'autorisation pour les clients publics avec PKCE ?

L'utilisateur clique sur un bouton ou un lien dans l'application cliente pour initier le processus d'authentification.
L'application cliente génère un vérificateur de code et un défi de code.
L'application cliente redirige l'utilisateur vers le serveur d'autorisation pour s'authentifier avec le défi de code.
Le serveur d'autorisation stocke le défi de code pour vérification ultérieure.
L'utilisateur s'authentifie et approuve l'accès à l'application cliente.
Le serveur d'autorisation renvoie un code d'autorisation au client.
L'application cliente échange le code d'autorisation contre un jeton d'accès en effectuant une requête de serveur à serveur au point de terminaison du jeton en utilisant le vérificateur de code.
Le serveur d'autorisation valide le code d'autorisation et le vérificateur de code par rapport au défi de code stocké.
Le serveur d'autorisation renvoie un jeton d'accès au client.
L'application cliente utilise le jeton d'accès pour accéder aux ressources de l'utilisateur sur le serveur de ressources.

En savoir plus sur le flux PKCE.