quijano.com.es

Jeton daccès oauth2

Aide-mémoire du protocole OAuth 2.0¶

Cet aide-mémoire décrit les meilleures pratiques de sécurité actuelles [1] pour OAuth 2.0 telles que dérivées de sa RFC [2][3]. OAuth est devenu la norme de protection des API et la base de la connexion fédérée à l’aide d’OpenID Connect. OpenID Connect 1.0 est une simple couche d’identité au-dessus du protocole OAuth 2.0. Il permet aux clients de vérifier l’identité de l’utilisateur final sur la base de l’authentification effectuée par un serveur d’autorisation, ainsi que d’obtenir des informations de profil de base sur l’utilisateur final de manière interopérable et de type REST.

Terminologie¶

  • Jetons d’accès = fournissent une abstraction, remplaçant différentes constructions d’autorisation (par exemple, nom d’utilisateur et mot de passe, assertion) pour un seul jeton compris par le serveur de ressources. Cette abstraction permet d’émettre des jetons d’accès valides pour une courte période, ainsi que de supprimer la ressource Le serveur a besoin de comprendre un large éventail de schémas d’authentification.
  • Jetons d’actualisation = sont des informations d’identification utilisées pour obtenir des jetons d’accès. Ceux-ci sont émis au client par le serveur d’autorisation et sont utilisés pour obtenir un nouveau jeton d’accès lorsque le jeton d’accès actuel devient invalide ou expire ou pour obtenir des jetons d’accès supplémentaires avec une portée identique ou plus étroite (les jetons d’accès peuvent avoir une durée de vie plus courte et moins d’autorisations que celles autorisées par le propriétaire de la ressource).
  • Client = fait généralement référence à une application qui effectue des demandes de ressources protégées au nom du propriétaire de la ressource et avec son autorisation. Le terme « client » n’implique aucune caractéristique d’implémentation particulière (par exemple, si l’application s’exécute sur un serveur, un ordinateur de bureau ou d’autres appareils).
  • Serveur d’autorisation (AS) = fait référence au serveur qui émet des jetons d’accès au client après avoir authentifié la ressource avec succès propriétaire et l’obtention de l’autorisation.
  • Resource Owner (RO) = fait référence à une entité capable d’accorder l’accès à une ressource protégée. Lorsque le propriétaire de la ressource est une personne, il est appelé utilisateur final.
  • Serveur de ressources (RS) = fait référence au serveur hébergeant les ressources protégées, capable d’accepter et de répondre aux demandes de ressources protégées à l’aide de jetons d’accès.

Les

  1. clients et le serveur d’autorisation ne doivent pas exposer d’URL qui redirigent le navigateur de l’utilisateur vers des URI arbitraires obtenus à partir d’un paramètre de requête (« redirecteurs ouverts ») qui peuvent permettre l’exfiltration de codes d’autorisation et de jetons d’accès.
  2. Les clients se sont assurés que le serveur d’autorisation prend en charge PKCE peut s’appuyer sur la protection CSRF fournie par PKCE. Dans les flux OpenID Connect, le paramètre « nonce » fournit une protection CSRF. Sinon, CSRF à utilisateur unique Les jetons portés dans le paramètre « state » qui sont liés de manière sécurisée à l’agent utilisateur doivent être utilisés pour la protection CSRF.
  3. Lorsqu’un client OAuth peut interagir avec plusieurs serveurs d’autorisation, les clients doivent utiliser le paramètre « iss » de l’émetteur comme contre-mesure, ou en fonction d’une valeur « ss » dans la réponse d’autorisation (telle que la revendication « ss » dans le jeton d’ID dans OpenID)
  4. Lorsque les autres options de contre-mesure pour les clients OAuth interagissant avec plus d’un serveur d’autorisation sont absentes, Les clients peuvent utiliser des URI de redirection distinctes pour identifier les points de terminaison d’autorisation et les points de terminaison de jeton.
  5. Un serveur d’autorisation évite de transférer ou de rediriger accidentellement une demande contenant des informations d’identification de l’utilisateur.

PKCE - Clé de preuve pour le mécanisme d’échange de code¶

Les clients publics OAuth 2.0 utilisant l’octroi de code d’autorisation sont susceptibles de Attaque d’interception de code d’autorisation. La clé de preuve pour l’échange de code (PKCE, prononcé « pixy ») est la technique utilisée pour atténuer la menace d’une attaque par interception de code d’autorisation.

À l’origine, PKCE est destiné à être utilisé uniquement pour sécuriser les applications natives, mais il est ensuite devenu une fonctionnalité OAuth déployée. Il protège non seulement contre les attaques par injection de code d’autorisation, mais protège également les codes d’autorisation créés pour les clients publics, car PKCE garantit que l’attaquant ne peut pas racheter un code d’autorisation volé au point de terminaison du jeton du serveur d’autorisation sans en avoir connaissance code_verifier.

  1. Les clients empêchent l’injection (relecture) de codes d’autorisation dans la réponse d’autorisation à l’aide du flux PKCE. De plus, les clients peuvent utiliser le paramètre « nonce » d’OpenID Connect et la revendication correspondante dans le jeton d’ID à la place. Le challenge PKCE ou « nonce » OpenID Connect doit être spécifique à la transaction et liée de manière sécurisée au client et à l’agent utilisateur dans lequel la transaction a été démarrée.
  2. Lors de l’utilisation de PKCE, les clients doivent utiliser des méthodes de test de code PKCE qui n’exposent pas le vérificateur PKCE dans la demande d’autorisation. Dans le cas contraire, les attaquants qui peuvent lire la demande d’autorisation peuvent briser la sécurité fournie par le PKCE. Les serveurs d’autorisation doivent prendre en charge PKCE.
  3. Si un client envoie un paramètre PKCE « code_challenge » valide dans la demande d’autorisation, le serveur d’autorisation applique l’utilisation correcte de « code_verifier » au point de terminaison du jeton.
  4. Les serveurs d’autorisation atténuent les attaques de rétrogradation PKCE en s’assurant qu’une demande de jeton contenant un paramètre « code_verifier » n’est acceptée que si un paramètre « code_challenge » est présent dans la demande d’autorisation.

Dans

le flux implicite, au lieu d’émettre le Client un code d’autorisation, le client reçoit directement un jeton d’accès (à la suite de l’autorisation du propriétaire de la ressource). Le type d’octroi est implicite, car aucune information d’identification intermédiaire (telle qu’un code d’autorisation) n’est émise (et utilisée ultérieurement pour obtenir un jeton d’accès).

  1. Les clients utilisent le type de réponse « code » (alias type d’octroi de code d’autorisation) ou tout autre type de réponse qui amène le serveur d’autorisation à émettre des jetons d’accès dans la réponse de jeton, tel que le type de réponse « code id_token ». Cela permet au serveur d’autorisation de détecter les tentatives de relecture des attaquants et réduit généralement la surface d’attaque puisque les jetons d’accès ne sont pas exposés dans les URL. Il permet également au serveur d’autorisation de contraindre l’expéditeur des jetons émis.

  1. Les serveurs d’autorisation et de ressources utilisent des mécanismes pour limiter l’accès à l’expéditeur. pour empêcher les relectures de jetons, tels que Mutual TLS pour OAuth 2.0 ou OAuth Demonstration of Proof of Possession (DPoP).
  2. Les jetons d’actualisation sont limités par l’expéditeur ou utilisent la rotation des jetons d’actualisation.

Les
  1. privilèges associés à un jeton d’accès doivent être limités au minimum requis pour l’application ou le cas d’utilisation particulier. Cela empêche les clients d’outrepasser les privilèges autorisés par le propriétaire de la ressource. Il empêche également les utilisateurs d’outrepasser leurs privilèges autorisés par la politique de sécurité respective. Les restrictions de privilèges permettent également de réduire l’impact des fuites de jetons d’accès.
  2. Les jetons d’accès sont limités à certains serveurs de ressources (restriction d’audience), de préférence à un seul serveur de ressources. Le Serveur d’autorisation doit associer le jeton d’accès à certains Serveurs de ressources et à chaque Ressource Le serveur est tenu de vérifier, pour chaque demande, si le jeton d’accès envoyé avec cette demande était destiné à être utilisé pour ce serveur de ressources particulier. Si ce n’est pas le cas, le serveur de ressources doit refuser de traiter la demande concernée. Les clients et les serveurs d’autorisation peuvent utiliser les paramètres « scope » et « resource » respectivement pour déterminer le serveur de ressources auquel ils souhaitent accéder.
  3. Les jetons d’accès sont limités à certaines ressources et actions sur les Serveurs de ressources ou les ressources. Le serveur d’autorisation doit associer le jeton d’accès à la ressource et aux actions respectives et chaque serveur de ressources est tenu de vérifier, pour chaque demande, si le jeton d’accès envoyé avec cette demande était destiné à être utilisé pour cette action particulière sur la ressource particulière. Si ce n’est pas le cas, le serveur de ressources doit refuser de traiter la demande concernée. Les clients et les serveurs d’autorisation peuvent utiliser les paramètres « scope » et « authorization_details » pour déterminer ces ressources et/ou actions.

Octroi des identifiants de mot de passe du propriétaire de la ressource¶

  1. L’octroi des identifiants du mot de passe du propriétaire de la ressource n’est pas utilisé. Ce type d’octroi expose de manière non sécurisée les informations d’identification du propriétaire de la ressource au client, ce qui augmente la surface d’attaque de l’application.

Les

  1. serveurs utilisent l’authentification client si possible. Il est recommandé d’utiliser des méthodes asymétriques (basées sur une clé publique) pour l’authentification du client, telles que mTLS ou « private_key_jwt » (OpenID Connect). Lorsque des méthodes asymétriques d’authentification du client sont utilisées, les serveurs d’autorisation n’ont pas besoin de stocker des clés symétriques sensibles, ce qui rend ces méthodes plus robustes contre plusieurs attaques.

Autres recommandations¶

  1. Les serveurs d’autorisation ne le font pas permettre aux clients d’influencer leur valeur « client_id » ou « sub » ou toute autre Réclamation pouvant être confondue avec un véritable Propriétaire de Ressource. Il est recommandé d’utiliser TLS de bout en bout.
  2. Les réponses d’autorisation ne sont pas transmises via des connexions réseau non chiffrées. Les serveurs d’autorisation ne doivent pas autoriser les URI de redirection qui utilisent le schéma « http », à l’exception des clients natifs qui utilisent la redirection d’interface de bouclage.

références: