L'avenir de l'autorisation : pourquoi OAuth 2.0 n'est que le début

L’autorisation est un élément essentiel de la sécurité des applications, permettant uniquement aux utilisateurs authentifiés et autorisés d’accéder aux ressources protégées. OAuth 2.0 est devenu le protocole d’autorisation standard du secteur, fournissant un cadre pour le contrôle d’accès délégué.

Publié pour la première fois en 2012, OAuth 2.0 permet aux applications d’accéder aux ressources hébergées par un serveur de ressources au nom du propriétaire de la ressource, via l’émission de jetons d’accès. Il permet aux utilisateurs d’autoriser des applications tierces à accéder à leurs données sur un autre service, sans exposer leurs informations d’identification.

OAuth a été largement adopté sur le Web, permettant l’autorisation de nombreuses plateformes majeures, notamment Facebook, Google, Twitter et Microsoft. Cependant, à mesure que l’utilisation d’OAuth s’est développée de façon exponentielle, des vulnérabilités et des faiblesses ont également été découvertes. Ceux-ci ont permis aux attaquants de voler des jetons d’accès et de usurper l’identité d’utilisateurs valides.

Dans cet article, nous fournirons un aperçu du fonctionnement d’OAuth 2.0, des cas d’utilisation courants, des meilleures pratiques et des vulnérabilités. Nous examinerons également au-delà d’OAuth des protocoles d’autorisation et d’authentification plus avancés visant à améliorer la sécurité : OpenID Connect, TLS mutuel et WebAuthn. À la fin, vous aurez une solide compréhension d’OAuth 2.0 et comment l’utiliser en toute sécurité. De plus, vous obtiendrez un aperçu des nouvelles normes et techniques qui vont au-delà d’OAuth pour sécuriser davantage le contrôle d’accès pour les applications modernes.

Comment fonctionne OAuth 2.0

OAuth 2.0 est une norme ouverte de délégation d’accès qui fournit une autorisation sécurisée permettant aux applications d’accéder aux ressources du serveur au nom d’un utilisateur. Il permet aux utilisateurs d’accorder un accès limité à leurs ressources sans exposer leurs informations d’identification.

OAuth 2.0 définit quatre flux d’autorisation principaux :

Flux de code d’autorisation

Le flux de code d’autorisation est mieux adapté aux clients confidentiels tels que les applications Web. Il s’agit d’un code d’autorisation intermédiaire à échanger contre un jeton d’accès :

L’application client redirige l’utilisateur vers le serveur d’autorisation pour se connecter et approuver l’accès.
Le serveur d’autorisation authentifie l’utilisateur et le redirige avec un code d’autorisation.
Le client échange le code d’autorisation contre un jeton d’accès.
Le client peut utiliser le jeton d’accès pour effectuer des appels API afin d’accéder aux ressources.

Ce flux offre une sécurité accrue car le jeton d’accès n’est jamais transmis directement via le navigateur de l’utilisateur.

Flux impliciteLe flux implicite est optimisé pour les clients basés sur un agent utilisateur tels que les applications Web à page unique. Le jeton d’accès est renvoyé directement sans code d’autorisation :

L’application client redirige l’utilisateur vers le serveur d’autorisation pour se connecter et approuver l’accès.
Le serveur d’autorisation authentifie l’utilisateur et le redirige avec un jeton d’accès dans le fragment d’URL.
Le client peut utiliser le jeton d’accès pour effectuer des appels API afin d’accéder aux ressources.

Ce flux simplifié supprime le besoin d’allers-retours supplémentaires vers le serveur d’autorisation, mais est moins sécurisé car le jeton d’accès est exposé dans l’historique du navigateur.

Comparaison des flux

Le flux du code d’autorisation est plus sécurisé mais implique davantage d’allers-retours. Le flux implicite est plus simple et optimisé pour les clients user-agent au détriment de la sécurité.

Dans l’ensemble, OAuth 2.0 fournit un cadre d’autorisation délégué sécurisé permettant aux applications clientes d’accéder aux ressources du serveur de manière standardisée. Cependant, des vulnérabilités existent toujours si elles ne sont pas mises en œuvre correctement.

Avantages et inconvénients d’OAuth 2.0

Avantages :

Autorisation déléguée sans partager les informations d’identification de l’utilisateur
Flux d’autorisation flexibles pour différents types de clients
Large adoption sur les principales plates-formes et fournisseurs

Inconvénients :

La complexité conduit à des erreurs de mise en œuvre courantes
S’appuie sur HTTPS et le secret des jetons pour la sécurité
Les jetons d’accès peuvent fuir s’ils ne sont pas correctement protégés
Contexte utilisateur intégré limité au-delà des portées

OAuth 2.0 résout le problème clé de l’autorisation sécurisée, mais présente des faiblesses que des protocoles plus avancés tentent de résoudre.

Cas d’utilisation d’OAuth 2.0

OAuth 2.0 est couramment utilisé pour activer les flux d’autorisation dans une grande variété d’applications et de services sur Internet. Certains des cas d’utilisation et exemples les plus courants incluent :

Connexion aux réseaux sociaux - Des services comme Facebook, Twitter, Google et GitHub exploitent tous OAuth 2.0 pour permettre aux utilisateurs de « se connecter avec » leurs identifiants de plateforme. Cela permet aux utilisateurs de renoncer à créer de nouveaux comptes et d’autoriser à la place ces sites à se connecter à leurs profils sociaux existants.
Autorisation d’application - Les applications mobiles et de bureau intègrent souvent OAuth pour autoriser l’accès aux API REST. Par exemple, une application peut utiliser OAuth pour accéder aux photos d’un utilisateur dans un service de stockage cloud, aux contacts dans un service de carnet d’adresses ou à d’autres données d’un fournisseur d’API.- Sécurité et authentification unique - OAuth permet une authentification centralisée via un seul fournisseur d’identité, plutôt que de gérer les informations d’identification pour chaque application individuellement. Cette approche d’authentification unique (SSO) est populaire dans les environnements d’entreprise pour améliorer la sécurité et la commodité.
Protection du compte utilisateur - Pour les utilisateurs soucieux de leur sécurité, OAuth permet d’autoriser l’accès aux applications sans jamais partager leurs informations d’identification principales. Cela protège le compte de l’utilisateur dans le cas où une application serait compromise ou malveillante.
Intégration de services - OAuth permet une intégration transparente entre différentes plates-formes grâce à ses flux d’autorisation et ses jetons d’accès. Les services peuvent se connecter directement les uns aux autres via des API au nom des utilisateurs, évitant ainsi les frictions et les tracas liés aux étapes d’authentification redondantes.

En résumé, OAuth 2.0 fournit un cadre standardisé pour accorder un accès limité aux données et fonctionnalités des utilisateurs sans exposer les informations d’identification. Ses flux flexibles et son format de jeton en font un protocole largement applicable pour l’autorisation dans les intégrations Web, mobiles, de bureau, IoT et basées sur les API. OAuth 2.0 est à la base d’une grande partie de l’interopérabilité transparente entre les applications et les services sur le Web moderne.

Meilleures pratiques OAuth 2.0

Pour tirer pleinement parti des avantages de sécurité d’OAuth 2.0, il est important de suivre les bonnes pratiques en matière d’enregistrement, de clés, de jetons et de jetons d’actualisation.

Inscription et gestion des clés

Utilisez HTTPS pour les points de terminaison d’autorisation et de jeton. Cela protège contre les attaques de l’homme du milieu.
Générez des clés cryptographiquement fortes avec une entropie suffisante. Les tailles de clé recommandées sont de 2 048 bits pour RSA et de 256 bits pour EC.
Ne codez jamais en dur les secrets des clients dans les applications et ne partagez jamais de secrets avec des parties non fiables. Stockez les secrets en toute sécurité côté serveur.
Définissez des délais d’expiration courts pour les codes d’autorisation, environ 10 minutes. Cela réduit la fenêtre d’interception.
Révoquez immédiatement les secrets client exposés et générez de nouvelles clés.

Utilisation des jetons

Conservez les jetons d’accès de courte durée, environ 1 heure. Les jetons d’actualisation peuvent avoir une expiration plus longue, environ 2 semaines.
Envoyez des jetons d’accès uniquement via HTTPS et uniquement à des backends de confiance. N’incluez jamais de jetons dans les URL, les journaux ou le code frontal.
Validez toujours l’audience du jeton pour qu’elle corresponde à l’audience attendue pour votre API.
Vérifiez que l’émetteur correspond au domaine de votre serveur d’autorisation.
Vérifiez l’algorithme de signature de jeton et la clé par rapport aux clés de confiance connues.

Actualiser les jetons- Émettez des jetons d’actualisation uniquement pour les applications et appareils propriétaires de confiance. Évitez de fournir des jetons d’actualisation pour les clients tiers.

Liez les jetons d’actualisation à une seule combinaison spécifique d’ID client et d’identité utilisateur.
Révoquer les jetons d’actualisation lorsque l’utilisateur se déconnecte ou que les autorisations changent. Émettez de nouveaux jetons lors de la réauthentification.
Jetons d’actualisation sécurisés équivalents à une autorisation à long terme. Transmettez uniquement via HTTPS et limitez l’accès via le cryptage.

Le respect de ces bonnes pratiques garantira qu’OAuth 2.0 fournit une sécurité robuste pour l’autorisation API.

Vulnérabilités OAuth 2.0

Bien qu’OAuth 2.0 constitue une amélioration par rapport aux protocoles d’authentification précédents, il présente toujours des vulnérabilités que les attaquants peuvent exploiter s’il n’est pas correctement implémenté et sécurisé. Certaines attaques OAuth courantes incluent :

Détournement de jeton - Un attaquant vole un jeton d’accès et l’utilise pour obtenir un accès non autorisé aux ressources. Cela peut se produire si les jetons ne sont pas correctement protégés ou transmis via des canaux non sécurisés.
Interception du code d’autorisation - Le code d’autorisation utilisé pour échanger un jeton d’accès peut être intercepté par un attaquant pendant le processus d’autorisation, lui permettant d’obtenir un jeton d’accès valide.
Usuration d’identité de client - Un attaquant prétend être un client valide pour tromper le serveur d’autorisation et lui faire émettre un jeton d’accès. Une faible authentification du client rend cela possible.
Usurpation d’identité d’utilisateur - L’attaquant vole ou devine les informations d’identification d’un utilisateur et les utilise pour s’authentifier en tant qu’utilisateur et accéder à ses données.
Flux OAuth interrompus - Une mise en œuvre et une validation incorrectes des flux OAuth peuvent laisser les points de terminaison ouverts à l’exploitation. Les attaquants peuvent exploiter les failles de la validation redirect_uri, des paramètres d’état et de l’émission de code/jeton pour compromettre les comptes.
Cross site request forgery (CSRF) - Les attaquants peuvent forcer les utilisateurs authentifiés à effectuer sans le savoir des requêtes en leur nom en exploitant la dépendance d’OAuth à l’égard de la redirection du navigateur pour les flux.
Redirecteurs ouverts - Autoriser les redirections ouvertes après la connexion OAuth peut permettre aux attaquants de rediriger les utilisateurs vers des sites de phishing et de voler des informations d’identification ou des jetons.

Pour éviter les abus d’OAuth, une mise en œuvre appropriée est cruciale :

Utiliser les paramètres d’état et de nonce pour empêcher CSRF
Appliquer l’enregistrement et la validation sécurisés des clients
Utiliser des canaux de communication cryptés
Définir des délais d’expiration courts sur les jetons
Révoquer les jetons lorsqu’ils ne sont plus nécessaires
Utilisez les jetons de rafraîchissement avec parcimonie et prudence
Suivez les meilleures pratiques OAuth pour la validation et les redirectionsBien qu’OAuth 2.0 offre un cadre d’autorisation standardisé, les organisations doivent veiller à atténuer les vulnérabilités grâce à une mise en œuvre appropriée, des contrôles de sécurité et des politiques d’accès robustes. Des protocoles supplémentaires comme OpenID Connect s’appuient sur OAuth pour améliorer la sécurité, démontrant ainsi la nécessité d’une évolution continue.

Aller au-delà d’OAuth 2.0

OAuth 2.0 est une norme importante en matière d’autorisation et reste encore largement utilisé aujourd’hui. Cependant, en tant que norme vieille de plus de 10 ans, OAuth 2.0 commence à montrer son âge et ses limites face aux menaces de sécurité modernes. Voici quelques-unes des principales raisons pour lesquelles OAuth 2.0 pourrait ne plus suffire :

Conçu pour les ordinateurs de bureau et le Web, pas pour les applications mobiles ou natives - OAuth 2.0 a été créé à l’époque précédant les applications mobiles et natives. Il repose sur des redirections qui ne fonctionnent pas bien en dehors du contexte d’un navigateur Web. Cela peut créer des failles de sécurité.
Pas de chiffrement des jetons par défaut - Les jetons OAuth 2.0 sont souvent envoyés non chiffrés, ce qui les laisse ouverts à l’interception. La spécification nécessite https pour le flux d’autorisation, mais les jetons d’accès peuvent toujours être transmis en clair.
Aucune méthode intégrée pour valider l’identité - OAuth 2.0 se concentre sur l’autorisation et la délégation d’accès. Il ne vérifie pas l’identité de l’utilisateur. Cela laisse place aux attaques d’usurpation d’identité.
Risques liés à la réutilisation et à l’intégration des jetons - OAuth 2.0 fournit une autorisation à usage unique mais n’empêche pas l’utilisation multiple du jeton. Les jetons bénéficiant d’un accès plus large peuvent également être intégrés dans des applications, élargissant ainsi l’exposition.
Aucune exigence de preuve de possession - Il n’existe aucune preuve cryptographique que la partie utilisant un jeton est l’utilisateur autorisé prévu. Cela crée un risque plus grand si un jeton est intercepté.
Normes de chiffrement limitées - OAuth 2.0 ne prend en charge que les anciens chiffrements comme SHA-1. Les algorithmes modernes plus puissants comme SHA-256 ne sont pas intégrés à la spécification de base.

À mesure que les menaces évoluent, les capacités d’OAuth 2.0 à s’en protéger atteignent leurs limites. Bien qu’il soit encore largement utilisé, OAuth 2.0 doit être complété et remplacé par des normes d’autorisation plus robustes et plus modernes pour certains cas d’utilisation. L’exploration de protocoles tels qu’OpenID Connect, TLS mutuel et WebAuthn offre des options pour une sécurité renforcée à l’avenir.

OpenID ConnectOpenID Connect est un protocole d’authentification construit sur OAuth 2.0 qui offre des fonctionnalités d’identité supplémentaires. Avec OAuth 2.0, le serveur de ressources reçoit un jeton d’accès qui accorde l’accès, mais ne fournit aucune information sur l’identité de l’utilisateur.

OpenID Connect permet aux clients de vérifier l’identité de l’utilisateur via une authentification auprès d’un serveur d’autorisation. Cela permet au client d’obtenir des informations de profil de base sur l’utilisateur. OpenID Connect utilise des JWT (JSON Web Tokens) qui contiennent des revendications sur l’authentification des utilisateurs, qui peuvent être renvoyées au client.

Quelques cas d’utilisation clés dans lesquels OpenID Connect améliore la sécurité :

Authentification unique (SSO) - OpenID Connect permet une authentification unique simple sur plusieurs sites et applications. L’authentification est gérée par le serveur d’autorisation du fournisseur d’identité, les sites n’ont donc pas besoin de gérer chacun leur propre authentification.
Intégrité accrue - Le jeton d’identification contient des revendications signées qui ont été vérifiées de manière sécurisée par le fournisseur d’identité. Cela offre de meilleures garanties d’intégrité que les jetons d’accès OAuth standard.
Accès au profil utilisateur - OpenID Connect fournit éventuellement un accès aux informations de profil de l’utilisateur final, donnant au client un contexte supplémentaire sur l’identité de l’utilisateur sans avoir besoin d’appels API supplémentaires.
Confiance accrue dans l’identité - Les normes relatives à l’utilisation de la portée, aux revendications JWT et au chiffrement offrent une plus grande confiance dans le fait que l’utilisateur est bien celui qu’il prétend par rapport à OAuth de base.

En résumé, OpenID Connect s’appuie sur l’autorisation fournie par OAuth 2.0 pour fournir également une authentification fiable et vérifier l’identité de l’utilisateur. Pour des cas d’utilisation tels que SSO et lorsque l’assurance de l’identité est critique, OpenID Connect est un protocole plus sécurisé et plus robuste.

TLS mutuel pour une authentification plus forte

Mutual TLS offre une authentification plus forte que le TLS traditionnel en exigeant une authentification bidirectionnelle entre le client et le serveur. Avec mTLS, le client et le serveur doivent fournir des certificats pour s’identifier avant d’établir une connexion TLS cryptée.

Voici comment fonctionne l’authentification mTLS :

Le client initie la prise de contact en envoyant au serveur son certificat client. Ce certificat est émis par une autorité de certification (CA) de confiance et vérifie l’identité du client.
Le serveur fournit alors son propre certificat de serveur au client. Ce certificat est validé par l’autorité de certification de confiance pour authentifier l’identité du serveur.- Le client et le serveur négocient une session TLS chiffrée si les deux parties valident avec succès leurs certificats respectifs. Cela crée un canal de communication bidirectionnel authentifié.
Le client et le serveur peuvent désormais échanger des données en toute sécurité via le tunnel TLS crypté, sachant que les identités aux deux extrémités ont été vérifiées.

mTLS est plus sécurisé que le TLS standard qui authentifie uniquement le serveur auprès du client. En exigeant une authentification mutuelle, mTLS empêche les connexions réseau non autorisées, contrecarrant ainsi les attaques de l’homme du milieu.

Cas d’utilisation où mTLS améliore la sécurité :

Sécurisation des communications entre microservices. mTLS empêche les microservices non autorisés de rejoindre le maillage.
Authentification pour les pods Kubernetes se connectant en interne. mTLS vérifie les identités des pods communiquant au sein du cluster.
Sécurisation de la communication des appareils IoT. mTLS verrouille la communication de machine à machine en exigeant des certificats clients.
Opérations bancaires et financières. mTLS garantit l’intégrité des transactions entre les systèmes financiers.

La mise en œuvre nécessite la prise en charge de mTLS par le client et le serveur. Les équilibreurs de charge comme NGINX peuvent mettre fin aux connexions mTLS, puis relayer le trafic en mode TLS simple. Les SDK clients facilitent l’intégration de l’authentification mTLS dans les applications mobiles et Web se connectant aux services backend. Avec des bibliothèques appropriées et un équilibrage de charge, les entreprises peuvent déployer la sécurité mTLS à grande échelle.

WebAuthn/FIDO2

WebAuthn (Web Authentication) et FIDO2 sont des normes Web émergentes qui offrent une alternative à l’authentification traditionnelle par mot de passe.

WebAuthn permet aux sites Web d’enregistrer et d’authentifier les utilisateurs en utilisant une cryptographie à clé publique au lieu de mots de passe. Ceci est activé grâce à des authentificateurs tels que des clés de sécurité ou des données biométriques. La norme a été créée par l’Alliance FIDO et le World Wide Web Consortium (W3C).

FIDO2 est un ensemble de spécifications techniques qui permettent des méthodes d’authentification sans mot de passe utilisant des informations d’identification sécurisées telles que des clés de sécurité, des données biométriques ou des authentificateurs de plateforme. C’est une extension de la norme FIDO (Fast Identity Online).

Voici quelques avantages clés de WebAuthn et FIDO2 par rapport à l’authentification par mot de passe traditionnelle :

Sécurité accrue - Les mots de passe peuvent être faibles, réutilisés, divulgués, volés ou sujets à des attaques de phishing. WebAuthn utilise une cryptographie asymétrique (à clé publique) pour offrir une forme d’authentification beaucoup plus solide et résistante à ces menaces.- Meilleure expérience utilisateur - Pas besoin de créer ou de mémoriser des mots de passe. Les utilisateurs s’authentifient simplement avec une empreinte digitale ou une clé de sécurité, ce qui est plus rapide et plus simple.
Coûts réduits - Les organisations dépensent moins pour gérer les réinitialisations de mots de passe, les appels au service d’assistance et d’autres problèmes liés aux mots de passe qui alourdissent les frais informatiques.
Protection de la vie privée - Avec WebAuthn, les informations d’identification d’origine (modèles biométriques ou clés privées) ne quittent jamais l’appareil de l’utilisateur. Cela protège la vie privée.
Agnostique sur la plate-forme/l’appareil - WebAuthn fonctionne sur les ordinateurs de bureau et les appareils mobiles. Et cela ne bloque pas les utilisateurs sur une plate-forme ou un appareil particulier.

Dans l’ensemble, WebAuthn et FIDO2 représentent une avancée majeure en matière de sécurité de l’authentification et de convivialité sur le Web. À mesure que ces normes seront plus largement adoptées, nous verrons moins de dépendance à l’égard des systèmes vulnérables basés sur des mots de passe.

Conclusion

OAuth 2.0 est devenu la norme en matière d’autorisation et d’authentification pour de nombreuses applications, offrant aux utilisateurs un moyen d’accorder un accès limité à leurs données sans exposer leurs informations d’identification. Cependant, en tant qu’ancien protocole, OAuth 2.0 présente certaines limites en termes de sécurité, d’étendue d’accès et d’expérience utilisateur.

Les protocoles les plus récents visent à améliorer OAuth 2.0 de diverses manières :

OpenID Connect s’appuie sur OAuth 2.0 pour ajouter des services d’identité, fournissant une vérification de l’identité ainsi qu’une authentification et une autorisation. Cela permet de corriger certaines des vulnérabilités de sécurité d’OAuth 2.0.
Mutual TLS fournit une authentification basée sur un certificat du client et du serveur, empêchant ainsi les attaques de l’homme du milieu. Bien que plus complexe à mettre en œuvre, le TLS mutuel améliore la protection de l’intégrité et de la confidentialité par rapport à OAuth 2.0 seul.
WebAuthn/FIDO2 utilise une cryptographie à clé publique au lieu de mots de passe pour l’authentification, offrant ainsi une connexion résistante au phishing et à la falsification. Ce protocole pourrait remplacer entièrement OAuth pour la connexion dans de nombreux cas.

Dans l’ensemble, même si OAuth 2.0 a jeté les bases d’une autorisation sécurisée, son âge se reflète dans diverses limitations héritées. Les protocoles plus récents s’appuient sur OAuth mais corrigent ses faiblesses en matière de sécurité, de confidentialité et d’expérience utilisateur.

Pour les applications hautement sensibles telles que les soins de santé, les services financiers et la gestion des identités, le TLS mutuel et les protocoles tels que WebAuthn doivent être fortement envisagés pour assurer une défense en profondeur. Même pour les applications grand public, l’extension d’OAuth avec OpenID Connect permet de garantir une meilleure intégrité de l’identité et de l’authentification des utilisateurs.Restez à l’écoute avec APIRobots pour plus d’informations et de mises à jour sur ce domaine passionnant. Ne manquez pas les opportunités que les API peuvent apporter à votre entreprise. Contactez-nous dès aujourd’hui à API Robots une agence de développement d’API et libérons ensemble tout le potentiel des API.