La spécification OAuth 2.1 a été planifiée. Explorons les principales différences entre OAuth 2.0 et OAuth 2.1 et comment elles ont été adoptées dans Logto.
Depuis la sortie de OAuth 2.0 (RFC 6749) en 2012, le monde des applications web et mobiles a beaucoup changé. Les gens passent des ordinateurs de bureau aux appareils mobiles, et les applications monopage (SPAs) sont maintenant très en vogue. Nous avons également vu apparaître de nombreux nouveaux frameworks et technologies web. Avec tous ces changements, les défis en matière de sécurité ont également augmenté. Pour suivre les dernières technologies web, de nouveaux RFC comme le Proof Key for Code Exchange (PKCE) ont été continuellement publiés pour améliorer OAuth 2.0. Il est devenu crucial de regrouper toutes les meilleures pratiques pour répondre aux besoins de sécurité d'aujourd'hui, et c'est pourquoi OAuth 2.1 arrive.
Dans le futur OAuth 2.1, le groupe de travail OAuth vise à consolider toutes les meilleures pratiques et recommandations de sécurité dans un document unique. Chez Logto, nous embrassons les dernières normes et meilleures pratiques d'OAuth. Dans cet article, nous explorerons les principales différences entre OAuth 2.0 et OAuth 2.1 et comment elles ont été adoptées dans Logto.
L'un des changements les plus significatifs dans OAuth 2.1 est que le Proof Key for Code Exchange (PKCE) est maintenant requis pour tous les clients OAuth utilisant le flux de code d'autorisation. PKCE est une extension de sécurité qui empêche les attaques d'interception de code d'autorisation. Il est particulièrement utile pour les applications mobiles et les applications monopage (SPAs) où le secret client ne peut pas être stocké en toute sécurité.
Les clients OAuth peuvent être catégorisés en deux types différents en fonction de leur capacité à stocker les secrets en toute sécurité :
Clients confidentiels : Ces clients peuvent stocker des secrets en toute sécurité, comme les applications web rendues par un serveur et les serveurs web. Toutes les demandes liées à l'autorisation sont effectuées du côté serveur, et le risque d'exposition du secret client est faible.
Clients publics : Ces clients ne peuvent pas stocker des secrets en toute sécurité, comme les applications mobiles et les SPAs. Le secret client peut être facilement extrait du code côté client, et il est difficile de le protéger contre les attaquants.
Pour les clients publics, PKCE est une mesure de sécurité indispensable. Il garantit que le code d'autorisation ne peut être échangé que par le client qui a initié la demande d'autorisation.
PKCE fonctionne en générant un code vérificateur aléatoire et un challenge de code basé sur le code vérificateur. Le code vérificateur est envoyé au serveur d'autorisation, et le challenge de code est utilisé pour vérifier le code vérificateur lors de l'échange du code d'autorisation contre un jeton d'accès.
Dans OAuth 2.1, PKCE devient obligatoire pour tous les clients OAuth utilisant le flux de code d'autorisation, quel que soit leur statut de confidentialité—qu'ils soient confidentiels ou publics. Ce changement fondamental garantit une protection universelle contre les éventuelles attaques d'interception de codes d'autorisation.
Dans Logto, le flux de validation PKCE est automatiquement activé pour les clients publics et confidentiels.
Pour les SPAs et les applications mobiles, PKCE est une mesure de sécurité indispensable pour protéger le flux de code d'autorisation dans Logto. Toute demande d'autorisation ne comportant pas de challenge de code sera rapidement refusée par le serveur d'autorisation de Logto.
Concernant les clients confidentiels (applications web traditionnelles), pour une meilleure compatibilité avec les anciens systèmes, Logto permet toujours de ne pas inclure le challenge de code dans la demande d'autorisation. Cependant, nous préconisons fortement aux clients confidentiels d'adopter PKCE en incorporant le challenge de code dans la demande d'autorisation, en suivant les pratiques des clients publics.
Une URI de redirection (Uniform Resource Identifier) est un point de terminaison ou une URL spécifique vers lequel le serveur d'autorisation redirige l'utilisateur après le processus d'authentification et d'autorisation.
Pendant le flux OAuth, l'application cliente inclut une URI de redirection comme partie de la demande d'autorisation initiale. Une fois que l'utilisateur a terminé le processus d'authentification, le serveur d'autorisation génère une réponse qui inclut un code d'autorisation, et redirige l'utilisateur vers l'URI de redirection spécifiée. Toute déviation de l'URI de redirection originale entraînera une fuite de code ou de jeton.
La correspondance exacte des chaînes d'URIs de redirection a été introduite pour la première fois dans la section 4.1 des Meilleures Pratiques de Sécurité en OAuth 2.0. Cette pratique garantit que l'URI de redirection doit correspondre exactement à celle qui est enregistrée auprès du serveur d'autorisation. Toute déviation par rapport à l'URI de redirection enregistrée entraînera une réponse d'erreur.
Nous avons reçu de nombreuses demandes de la communauté concernant la mise en œuvre de la correspondance par wildcard pour les URIs de redirection. Bien que la correspondance par wildcard puisse offrir une commodité pour les développeurs qui gèrent plusieurs sous-domaines ou chemins, en particulier avec un grand nombre de sous-domaines aléatoires, cela introduit également des risques de sécurité tels que les attaques de redirection ouverte. Pour une illustration pratique des dangers posés par l'absence de validation des URIs de redirection, veuillez vous référer à notre article de blog Un bref récapitulatif de la sécurité OAuth.
Conformément aux normes de sécurité strictes d'OAuth 2.1, Logto utilise la correspondance exacte des chaînes pour les URIs de redirection. Cette décision priorise la sécurité du flux OAuth. Plutôt que d'utiliser la correspondance par wildcard, nous encourageons les développeurs à enregistrer toutes les URIs de redirection potentielles auprès du serveur d'autorisation Logto. Cela garantit une validation exhaustive des URIs de redirection et aide à atténuer les vulnérabilités potentielles en matière de sécurité.
Le flux d'octroi implicite dans OAuth 2.0 a été conçu pour les SPAs où le jeton d'accès est renvoyé directement dans le fragment d'URL après que l'utilisateur se soit authentifié. Cette méthode était pratique car elle évitait une étape supplémentaire d'échange de jeton, permettant au client de recevoir directement le jeton.
Cependant, cette commodité a ses inconvénients. Le jeton d'accès peut être exposé à des parties non autorisées par le biais de l'historique du navigateur, des en-têtes de référent ou d'autres moyens, ce qui rend plus facile la survenue de violations de sécurité—en particulier lorsque les jetons d'accès restent valides pendant de longues périodes. Par exemple, si la demande d'autorisation est interceptée par une partie malveillante, elle peut facilement extraire le jeton d'accès du fragment d'URL et usurper l'identité de l'utilisateur.
Dans les Meilleures Pratiques de Sécurité en OAuth 2.0, il est clairement indiqué que :
Les clients NE DOIVENT PAS utiliser l'octroi implicite (type de réponse "token") ou d'autres types de réponses émettant des jetons d'accès dans la réponse d'autorisation.
Par conséquent, le flux implicite a été officiellement retiré de la spécification OAuth 2.1.
Dans Logto, le flux de code d'autorisation avec PKCE est le seul flux pris en charge pour les SPAs et les applications mobiles. Le flux de code d'autorisation offre une manière plus sécurisée d'obtenir des jetons d'accès en échangeant le code d'autorisation.
Le flux des identifiants de propriétaire de ressource (ROPC) permet au client d'échanger le nom d'utilisateur et le mot de passe de l'utilisateur contre un jeton d'accès. Il a été introduit pour la première fois dans la spécification OAuth 2.0 comme un moyen de soutenir les applications héritées telles que l'authentification HTTP de base ou les applications natives héritées qui ne pouvaient pas utiliser les flux OAuth sécurisés et tokenisés.
Le type d'octroi ROPC a été marqué comme non recommandé dans la spécification OAuth 2.0 en raison de ses risques de sécurité. Les identifiants de l'utilisateur sont exposés à l'application cliente, ce qui peut conduire à des violations de sécurité potentielles. L'application cliente peut stocker les identifiants de l'utilisateur, et si le client est compromis, les identifiants de l'utilisateur peuvent être exposés aux attaquants.
Plus tard, dans la section 2.4 des Meilleures Pratiques de Sécurité en OAuth 2.0, l'interdiction du type d'octroi ROPC a été encore renforcée avec l'exigence de ne PAS l'utiliser. En conséquence, le type d'octroi ROPC a été retiré de la spécification OAuth 2.1.
En raison des risques de sécurité élevés associés au type d'octroi ROPC, Logto ne l'a jamais pris en charge. Si vous utilisez encore le flux direct d'identifiants utilisateur dans vos applications héritées, nous recommandons fortement de migrer vers une méthode plus sécurisée, telle que le flux de code d'autorisation ou l'octroi d'identifiants client. Logto propose divers SDKs et tutoriels pour vous aider à intégrer facilement ces flux OAuth sécurisés dans vos applications.
Nous comprenons que les développeurs puissent vouloir concevoir ou héberger eux-mêmes leur propre interface de connexion utilisateur pour une meilleure expérience produit. Chez Logto, nous offrons une gamme d'options de personnalisation de l'expérience de connexion (SIE), y compris les paramètres de marque et le CSS personnalisé. De plus, nous avons plusieurs projets en cours, tels que l'utilisation de votre propre UI, et la connexion directe, pour offrir plus de flexibilité aux développeurs pour apporter leur propre interface de connexion tout en maintenant la sécurité du flux OAuth.
OAuth 2.1 est la dernière mise à jour du protocole OAuth, conçue pour relever les défis de sécurité d'aujourd'hui tout en répondant aux besoins modernes des applications web et mobiles. Le groupe de travail OAuth met activement à jour et affine OAuth 2.1 pour s'assurer qu'il répond aux dernières normes et meilleures pratiques en matière de sécurité. Le dernier projet, OAuth 2.1 11, a été publié en mai 2024, marquant des progrès significatifs vers sa finalisation. Avec une adoption large imminente, nous recommandons vivement à tout le monde de suivre les meilleures pratiques décrites dans OAuth 2.1 pour renforcer la sécurité et améliorer l'expérience utilisateur.