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

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 ?#

1. L'utilisateur clique sur un bouton ou un lien dans l'application cliente pour initier le processus d'authentification.
2. L'application cliente redirige l'utilisateur vers le serveur d'autorisation pour s'authentifier, incluant le champ d'accès désiré.
3. Le serveur d'autorisation invite les utilisateurs à se connecter et à accorder l'autorisation à l'application cliente.
4. 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.
5. 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 ?#

1. L'utilisateur clique sur un bouton ou un lien dans l'application cliente pour initier le processus d'authentification.
2. L'application cliente redirige l'utilisateur vers le serveur d'autorisation pour s'authentifier avec la portée d'accès désirée.
3. Le serveur d'autorisation invite les utilisateurs à se connecter et à accorder l'autorisation à l'application cliente.
4. Après une authentification et une autorisation réussies, le serveur d'autorisation renvoie un code d'autorisation au client.
5. 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.
6. Le serveur d'autorisation valide le code d'autorisation et les identifiants clients et renvoie un jeton d'accès au client.
7. 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 ?#

1. L'utilisateur clique sur un bouton ou un lien dans l'application cliente pour initier le processus d'authentification.
2. L'application cliente génère un vérificateur de code et un défi de code.
3. L'application cliente redirige l'utilisateur vers le serveur d'autorisation pour s'authentifier avec le défi de code.
4. Le serveur d'autorisation stocke le défi de code pour vérification ultérieure.
5. L'utilisateur s'authentifie et approuve l'accès à l'application cliente.
6. Le serveur d'autorisation renvoie un code d'autorisation au client.
7. 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.
8. Le serveur d'autorisation valide le code d'autorisation et le vérificateur de code par rapport au défi de code stocké.
9. Le serveur d'autorisation renvoie un jeton d'accès au client.
10. 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.

Flux implicite vs. Flux de code d'autorisation#

Le flux de code d'autorisation peut-il éliminer les problèmes de sécurité du flux implicite ?#

La réponse est OUI :

Le flux de code d'autorisation introduit une étape supplémentaire pour échanger le code d'autorisation contre un jeton d'accès, ce qui réduit considérablement le risque d'exposition des jetons.

• Pour les clients privés avec un composant serveur sécurisé, l'application cliente peut échanger en toute sécurité le code d'autorisation contre un jeton d'accès en utilisant ses identifiants clients.
• Pour les clients publics sans composant serveur sécurisé, l'extension PKCE peut être utilisée pour protéger le processus d'échange de code d'autorisation.

Si vous utilisez actuellement le flux implicite dans votre entreprise, passer au flux de code d'autorisation avec PKCE peut offrir une meilleure sécurité à la fois pour vous et vos utilisateurs. Nous comprenons que la migration et la gestion d'un système d'identité peuvent être fastidieuses et coûteuses, mais les avantages en matière de sécurité améliorée et de conformité en valent bien l'effort.