Tout
OAuth

Comment protéger le serveur de ressources contre les attaques de relecture et les fuites de jetons ?

Généré par l’IA et la communauté LinkedIn

OAuth est un protocole populaire pour autoriser les clients à accéder aux ressources au nom des utilisateurs. Cependant, OAuth introduit également certains risques de sécurité, tels que les attaques par relecture et les fuites de jetons, qui peuvent compromettre le serveur de ressources et les données de l’utilisateur. Dans cet article, vous allez apprendre à protéger le serveur de ressources contre ces menaces en suivant certaines des meilleures pratiques pour la conception du serveur de ressources.

Dans cet article collaboratif, vous trouverez des réponses d’experts

Sélectionnés par la communauté pour 5 contributions. En savoir plus

1 Utiliser HTTPS

La première étape, et la plus élémentaire, pour sécuriser le serveur de ressources consiste à utiliser HTTPS pour toutes les communications. HTTPS chiffre les données en transit et empêche l’écoute, la falsification et l’usurpation d’identité. HTTPS garantit également que le client et le serveur de ressources sont authentiques et dignes de confiance. Sans HTTPS, les jetons d’accès et les demandes de ressources peuvent être interceptés et modifiés par des acteurs malveillants.

Ajoutez votre point de vue

Charger plus de contributions

2 Valider les jetons d’accès

La deuxième étape pour protéger le serveur de ressources consiste à valider les jetons d’accès présentés par le client. Le serveur de ressources doit vérifier que le jeton d’accès est valide, qu’il n’a pas expiré et qu’il a la portée et l’audience appropriées pour la ressource demandée. Le serveur de ressources doit également vérifier la signature du jeton d’accès, s’il s’agit d’un JWT, ou utiliser l’introspection, s’il s’agit d’un jeton opaque, pour s’assurer que le jeton d’accès a été émis par un serveur d’autorisation approuvé.

Ajoutez votre point de vue

Charger plus de contributions

3 Mettre en œuvre nonce et état

La troisième étape pour protéger le serveur de ressources consiste à implémenter les paramètres nonce et state dans la demande d’autorisation et la réponse. Un nonce est une chaîne aléatoire que le client génère et envoie au serveur d’autorisation avec la demande. Le serveur d’autorisation renvoie ensuite le même nonce dans le jeton d’accès ou le code d’autorisation. Le client et le serveur de ressources peuvent ensuite comparer les valeurs nonce pour détecter et empêcher les attaques par relecture. Un état est un mécanisme similaire que le client utilise pour maintenir l’état du flux d’autorisation et empêcher les attaques CSRF.

Ajoutez votre point de vue

Greg Rice

Experienced IAM and ML Platform Developer, DevOps Engineer and Architect (Python, Scala, Kotlin, Java, Golang) extravert who loves bringing diverse, inclusive teams together to turn ideas into scalable web services
Signaler la contribution
For example: One may request an access token for accessing resource /home/me/my_file.txt. When calling a GET operation on that resource, I could actually generate a nonce (54321) and request GET /home/me/my_file.txt_54321 instead, as well as send a request to the auth server - say, Auth0 - with a query param including `nonce=54321`. Other providers may not provide explicit nonce support, but it can be hacked into games, too. Now, the controller/service actually serving up /home/me/my_file.txt_54321 will be responsible for recognizing the last bit as a nonce, checking the access token to make sure it's got the right nonce claim as well as general read scopes for the resource.

Texte traduit

J’aime

4 Utiliser des jetons d’accès de courte durée et révocables

La quatrième étape pour protéger le serveur de ressources consiste à utiliser des jetons d’accès de courte durée et révocables. Les jetons d’accès de courte durée réduisent la fenêtre d’opportunité pour un attaquant d’utiliser un jeton volé ou divulgué. Les jetons d’accès révocables permettent au serveur de ressources ou à l’utilisateur d’invalider un jeton s’il est compromis ou n’est plus nécessaire. Le serveur de ressources doit également implémenter une liste noire de jetons ou un mécanisme de liaison de jetons pour rejeter les jetons révoqués ou liés.

Ajoutez votre point de vue

5 Appliquer le moindre privilège et un contrôle d’accès précis

La cinquième étape pour protéger le serveur de ressources consiste à appliquer le principe du moindre privilège et du contrôle d’accès affiné. Le principe du moindre privilège signifie que le client et l’utilisateur ne doivent disposer que des autorisations minimales et des droits d’accès nécessaires pour effectuer leurs tâches. Un contrôle d’accès précis signifie que le serveur de ressources doit appliquer des stratégies granulaires et dynamiques basées sur le contexte, les attributs et les rôles du client et de l’utilisateur. De cette façon, le serveur de ressources peut limiter l’exposition et l’impact d’une violation ou d’un abus.

Ajoutez votre point de vue

Greg Rice

Experienced IAM and ML Platform Developer, DevOps Engineer and Architect (Python, Scala, Kotlin, Java, Golang) extravert who loves bringing diverse, inclusive teams together to turn ideas into scalable web services
Signaler la contribution
Service to service authorization should depend on the level of access of User A, who's talking to Service B, which accesses Service C. User A having a lot of power to grant Service B should not mean Service B anything more than least-privilege on Service C. I personally do not think OAuth2 is quite up to par alone anymore, especially in multitenant projects, and that this work is best handled through caching RBAC-based information on users and scopes/grants available, while combining it with Open Policy Agent. The rise of Auth0 means we want to cache as much access data as possible, while still logging token requests. It's also time to start looking at AuthZ change events and how pubsub can make this scale!

Texte traduit

J’aime

Charger plus de contributions

6 Surveiller et auditer les journaux d’accès

La sixième et dernière étape pour protéger le serveur de ressources consiste à surveiller et à auditer les journaux d’accès. Le serveur de ressources doit enregistrer et analyser les demandes d’accès, les réponses, les erreurs et les anomalies qui se produisent sur le serveur de ressources. Le serveur de ressources doit également alerter et répondre à toute activité suspecte ou malveillante, telle qu’un accès non autorisé ou excessif, des jetons défaillants ou non valides, ou des modèles ou comportements inhabituels. En surveillant et en auditant les journaux d’accès, le serveur de ressources peut détecter et atténuer les attaques potentielles et améliorer la posture de sécurité du serveur de ressources.

Ajoutez votre point de vue

7 Voici ce qu’il faut prendre en compte

Il s’agit d’un espace pour partager des exemples, des histoires ou des idées qui ne correspondent à aucune des sections précédentes. Que voudriez-vous ajouter d’autre?

Ajoutez votre point de vue

OAuth

+ Suivre

Notez cet article

Nous avons créé cet article à l’aide de l’intelligence artificielle. Qu’en pensez-vous ?

Il est très bien Ça pourrait être mieux

Signaler cet article

Tout voir

Comment protéger le serveur de ressources contre les attaques de relecture et les fuites de jetons ?

1

2

3

4

5

6

7

1 Utiliser HTTPS

2 Valider les jetons d’accès

3 Mettre en œuvre nonce et état

4 Utiliser des jetons d’accès de courte durée et révocables

5 Appliquer le moindre privilège et un contrôle d’accès précis

6 Surveiller et auditer les journaux d’accès

7 Voici ce qu’il faut prendre en compte

OAuth

Notez cet article

Nous vous remercions de votre feedback

Plus d’articles sur OAuth

Lecture plus pertinente