La protection des informations personnelles et professionnelles est plus cruciale que jamais, à mesure que la technologie numérique devient de plus en plus répandue. L’identité sert de périmètre de sécurité principal pour les applications d’entreprise et grand public. Alors que les cyberattaques et les violations de données continuent d’augmenter, la protection des données sensibles est devenue une priorité essentielle pour les individus et les organisations.
Selon le rapport Data Breach Investigations report (2024) de Verizon, 86 % des violations sont attribuées à des informations d’identification volées, notamment les mots de passe, les jetons OAuth/OpenID Connect et les clés d’API. Ces jetons sont généralement utilisés pour authentifier et autoriser les utilisateurs à accéder à plusieurs sites Web, permettre aux utilisateurs de rester connectés pendant une période prolongée et récupérer des informations de profil sur l’utilisateur que le site Web peut utiliser pour personnaliser leur expérience. Les applications peuvent utiliser ces jetons pour accéder à des ressources protégées telles que les API et les informations sensibles.
La sécurisation de ces artefacts privilégiés (jetons) est devenue une exigence essentielle. Voici les meilleures pratiques que vous pouvez mettre en œuvre pour sécuriser vos jetons OAuth et OpenID Connect.
Petit rappel sur les types de jetons et d’applications OAuth/OpenID Connect
Tout d’abord, passons en revue les différents types de jetons et d’applications OAuth et OpenID Connect.
Types de jetons
Les jetons sont des informations d’identification numériques sécurisées utilisées pour vérifier l’identité d’un utilisateur et accorder l’accès à des ressources protégées. La charge utile du jeton contient généralement des informations sur le profil utilisateur, les autorisations et les métadonnées, qui sont signées cryptographiquement pour garantir l’authenticité et l’intégrité.
Jetons d’identification: Comme son nom l’indique, les jetons d’identification sont utilisés pour identifier le principal (c’est-à-dire l’utilisateur final). Ils contiennent des informations sur l’utilisateur et prouvent que le fournisseur OpenID a authentifié l’utilisateur avec succès. L’audience de ce jeton est le client OpenID, c’est-à-dire l’application elle-même.
Jetons d'accès: OpenID Connect fonctionne en parallèle avec OAuth 2.0 à des fins d'autorisation. Les jetons d'accès OAuth 2.0 délèguent des permissions à l'application pour appeler les API backend au nom de l'utilisateur. L'audience du jeton est l'API backend (c'est-à-dire le serveur de ressources).
Jetons d’actualisation: Les jetons d’accès et d’identification sont de courte durée et expirent après une certaine période. Les jetons d’actualisation sont des autorisations de longue durée que l’application peut utiliser pour demander une nouvelle paire de jetons d’accès et d’identification auprès du serveur d’autorisation. L’audience du jeton d’actualisation est le serveur d’autorisation lui-même.
Types d’applications
Selon la spécification OAuth, les applications peuvent être classées comme confidentielles ou publiques. La principale différence est de savoir si l’application peut ou non détenir des informations d’identification en toute sécurité (telles qu’un ID client et un secret).
Applications publiques: Ces applications ne peuvent pas stocker en toute sécurité les secrets clients ou les informations d'identification fournies par un serveur d'autorisation. Les exemples d'applications publiques incluent les applications modernes côté client basées sur JavaScript qui s'exécutent dans le navigateur (applications monopages) et les applications natives installées sur les appareils mobiles et les ordinateurs de bureau.
Applications confidentielles: D’un autre côté, les applications confidentielles peuvent stocker et maintenir la confidentialité des informations d’identification du client en toute sécurité. Ces applications s’exécutent sur un serveur sécurisé et, par conséquent, les informations d’identification ne sont pas accessibles aux utilisateurs finaux. Les exemples d’applications confidentielles incluent les applications Web traditionnelles et les applications serveur à serveur backend.
5 meilleures pratiques pour sécuriser vos jetons
1. Utilisez la cryptographie asymétrique pour l’authentification du client
L’authentification du client nous permet de vérifier l’identité de l’application cliente afin d’empêcher l’usurpation d’identité du client et de permettre un accès sécurisé aux ressources protégées. Tout comme les mots de passe sont considérés comme un facteur d’authentification utilisateur faible, les secrets client sont une méthode d’authentification client faible, car le secret client est contenu dans le corps de la requête et repose sur un secret partagé.
Contrairement aux secrets client, les techniques cryptographiques asymétriques telles que mTLS ou les jetons Web JSON signés (JWT), appelés JWT de clé privée, ne sont jamais transmis sur le réseau, ce qui réduit considérablement le risque de fuite de clé et d’attaques de l’homme du milieu. L’authentification du client s’applique uniquement aux clients confidentiels. Ainsi, lors de la création de votre application, envisagez d’utiliser une méthode d’authentification client robuste, en particulier si vous traitez des informations sensibles. En savoir plus sur les méthodes d’authentification du client.
2. Adoptez PKCE pour les clients publics
L'essor des applications mobiles et web a probablement entraîné une augmentation du nombre de clients publics. Étant donné que l'authentification du client ne peut pas être utilisée avec les applications clientes publiques, Proof Key for Code Exchange (PKCE) garantit que seul le client d'origine qui a initié la demande d'autorisation peut échanger le code contre des jetons.
PKCE garantit qu’un attaquant ne peut pas utiliser un code d’autorisation volé au point de terminaison de jeton du serveur d’autorisation. Bien que PKCE ait été initialement conçu pour les clients publics, OAuth 2.1 recommande PKCE pour les clients confidentiels en plus de l’authentification du client, car il offre une protection supplémentaire contre l’injection de code d’autorisation et les attaques d’interception. En savoir plus sur PKCE avec le flux de code d’autorisation.
3. Mettre en œuvre la preuve de possession
La preuve de possession est une méthode permettant de limiter l’utilisation des jetons d’accès OAuth à un client autorisé (application basée sur navigateur). Elle peut être réalisée de deux manières : la liaison de jetons basée sur mTLS au niveau du transport ou la liaison de jetons basée sur DPoP au niveau de l’application. Étant donné les défis de scalabilité, de déploiement et de convivialité de mTLS, la démonstration de la preuve de possession (DPoP) est la manière recommandée de mettre en œuvre la preuve de possession. DPoP représente une amélioration significative de la sécurité OAuth 2.0, car il empêche les attaquants de voler et de relire des jetons. En savoir plus sur OAuth 2.0 DPoP.
4. Tenez compte de votre processus de gestion du cycle de vie des jetons
En cas de compromission, les jetons de longue durée offrent une plus grande fenêtre d’opportunité pour les activités malveillantes qui peuvent entraîner un accès non autorisé. Par conséquent, nous vous recommandons d’attribuer aux jetons d’accès des durées de vie courtes et de les actualiser en continu si nécessaire.
Pour atténuer les risques associés aux jetons d’actualisation divulgués, envisagez la rotation des jetons d’actualisation, qui permet de faire pivoter le jeton d’actualisation en toute sécurité après chaque utilisation. La rotation des jetons d’actualisation peut aider à détecter la réutilisation d’un jeton d’actualisation, sur lequel le serveur d’autorisation peut invalider le jeton d’actualisation et tous les jetons d’accès émis depuis l’authentification de l’utilisateur. Cela protège l’application contre la compromission de jetons et les attaques de relecture. En savoir plus sur la rotation des jetons d’actualisation.
La révocation de tous les jetons lorsqu’un utilisateur se déconnecte d’une application est également essentielle. Lorsqu’un jeton est révoqué, il devient immédiatement invalide, empêchant toute utilisation ultérieure de ce jeton pour accéder aux ressources protégées. La révocation de jetons peut se produire lorsque l’utilisateur lance une déconnexion ou lorsqu’un événement inattendu se produit, ce qui augmente le profil de risque de l’utilisateur. Grâce à la révocation globale des jetons, les fournisseurs externes de sécurité et d’informations d’identification peuvent demander à un serveur d’autorisation de révoquer tous les jetons existants d’un utilisateur. Cette action oblige l’utilisateur à se réauthentifier avant que de nouveaux jetons ne soient émis. En savoir plus sur la révocation globale des jetons et la déconnexion universelle.
5. Appliquez le principe du moindre privilège
Les applications OAuth/OpenID Connect doivent être conçues et mises en œuvre selon le principe du moindre privilège afin d’améliorer la posture de sécurité de l’application et de minimiser les risques potentiels. Des politiques spécifiques à l’application peuvent être utilisées pour garantir que seules les bonnes personnes peuvent accéder à une application spécifique à partir d’un emplacement, d’un type d’appareil, d’un profil de risque, etc. particuliers.
Les scopes OAuth peuvent être utilisés pour accorder des autorisations spécifiques dans un jeton d’accès. Les scopes doivent être aussi granulaires que possible pour empêcher les applications de demander des autorisations excessives. Pour les cas d’utilisation qui nécessitent un accès précis qui change de manière dynamique, nous recommandons de les modéliser à partir du framework OAuth. Cela permet d’éviter que les jetons ne soient gonflés avec des scopes excessifs et des informations liées aux revendications. Pour en savoir plus sur les politiques de connexion à l’application, les droits et l’ autorisation fine.
Bien que ce blog mette en évidence certains aspects essentiels de l’amélioration de la sécurité de vos jetons, le groupe de travail OAuth a élaboré une liste exhaustive des meilleures pratiques de sécurité. Consultez régulièrement les spécifications officielles pour vous assurer que vos applications sont conformes aux dernières tendances en matière de sécurité et aux normes d’identité.
Vous avez des questions sur cet article de blog ? Contactez-nous à l'adresse eng_blogs@okta.com.
Consultez d’autres Blogs sur l’ingénierie d’Okta pour approfondir vos connaissances.
Prêt à rejoindre notre équipe d’ingénieurs aussi passionnés qu’exceptionnels ? Consultez notre page Carrières.
Libérez le potentiel d’une gestion des identités moderne et sophistiquée pour votre entreprise. Contactez notre équipe commerciale pour plus d’informations.
