Question Pourquoi OAuth v2 dispose-t-il à la fois de jetons d'accès et d'actualisation?


La section 4.2 du projet de protocole OAuth 2.0 indique qu'un serveur d'autorisation peut renvoyer un access_token (qui s'authentifie avec une ressource) ainsi qu'un refresh_token, qui est utilisé uniquement pour créer une nouvelle access_token:

https://tools.ietf.org/html/rfc6749#section-4.2

Pourquoi avoir les deux? Pourquoi ne pas simplement faire le access_token durer aussi longtemps que le refresh_token et ne pas avoir refresh_token?


482
2017-08-15 15:25


origine


Réponses:


L'idée des jetons d'actualisation est que si un jeton d'accès est compromis, parce qu'il est de courte durée, l'attaquant a une fenêtre limitée pour l'abuser.

Les jetons d'actualisation, s'ils sont compromis, sont inutiles car l'attaquant a besoin de l'identifiant et du secret du client en plus du jeton d'actualisation pour obtenir un jeton d'accès.

Ayant dit cela, car chaque appel à la fois au serveur d'autorisation et au serveur de ressources est effectué via SSL - y compris l'ID client d'origine et secret lorsqu'ils demandent les jetons d'accès / rafraîchissement - je ne suis pas sûr le jeton de rafraîchissement à long terme et la combinaison client / secret.

Ceci est bien sûr différent des implémentations dans lesquelles vous ne contrôlez pas les serveurs d'autorisation et de ressources.

Voici un bon fil parlant des utilisations de jetons de rafraîchissement: Archives OAuth.

Une citation de ce qui précède, parlant des objectifs de sécurité du jeton d'actualisation:

Actualiser les jetons ... atténue le risque de fuite de longue durée d'accès_token (paramètre de requête dans un fichier journal sur un serveur de ressources non sécurisé, une application de serveur de ressources bêta ou mal codée, client JS SDK sur un site non https). cookie, etc.)


354
2017-08-26 18:52



Le lien vers la discussion, fourni par Catchdave, a un autre point valide faite par Dick Hardt, qui je crois mérite d'être mentionné ici en plus de ce qui a été écrit ci-dessus:

Mon souvenir des jetons de rafraîchissement était pour la sécurité et la révocation.   <...>

révocation: Si le jeton d'accès est autonome, l'autorisation peut être révoquée en n'émettant pas de nouveaux jetons d'accès. Une ressource n'a pas besoin d'interroger le serveur d'autorisation pour savoir si le jeton d'accès est valide. Cela simplifie la validation des jetons d'accès et facilite la mise à l'échelle et la prise en charge de plusieurs serveurs d'autorisation. Il y a une fenêtre de temps où un jeton d'accès est valide, mais l'autorisation est révoquée.

En effet, dans le cas où le serveur de ressources et le serveur d’autorisation sont la même entité et où la connexion entre l’utilisateur et l’un ou l’autre est également sécurisée, il n’est pas judicieux de séparer le jeton de rafraîchissement du jeton d’accès.

Bien que, comme indiqué dans le devis, les jetons d'actualisation ont également pour rôle de garantir que le jeton d'accès peut être révoqué à tout moment par l'utilisateur (via l'interface Web dans ses profils, par exemple) tout en gardant le système évolutif. .

Généralement, les jetons peuvent être soit des identificateurs aléatoires pointant vers l’enregistrement spécifique dans la base de données du serveur, soit ils peuvent contenir toutes les informations en elles-mêmes (certainement, ces informations doivent être signées, avec MAC, par exemple).

Comment le système avec des jetons d'accès à vie longue devrait fonctionner

Le serveur permet au client d'accéder aux données de l'utilisateur dans un ensemble d'étendues prédéfini en émettant un jeton. Comme nous voulons garder le jeton révocable, nous devons stocker dans la base de données le jeton avec le drapeau "révoqué" étant mis ou non (sinon, comment le feriez-vous avec un jeton autonome?) La base de données peut contenir autant que len(users) x len(registered clients) x len(scopes combination) enregistrements. Chaque demande d'API doit alors toucher la base de données. Bien qu'il soit assez trivial de faire des requêtes à une telle base de données en exécutant O (1), le seul point de défaillance lui-même peut avoir un impact négatif sur l'évolutivité et les performances du système.

Comment le système avec jeton d'actualisation à long terme et jeton d'accès à durée de vie courte doit-il fonctionner?

Ici, nous émettons deux clés: le jeton d'actualisation aléatoire avec l'enregistrement correspondant dans la base de données, et le jeton d'accès autonome signé, contenant entre autres le champ d'horodatage d'expiration.

Comme le jeton d'accès est autonome, il n'est pas nécessaire de cliquer sur la base de données pour vérifier sa validité. Tout ce que nous avons à faire est de décoder le jeton et de valider la signature et l'horodatage.

Néanmoins, nous devons toujours conserver la base de données des jetons d'actualisation, mais le nombre de requêtes à cette base de données est généralement défini par la durée de vie du jeton d'accès (plus la durée de vie est longue, plus le taux d'accès est bas).

Afin de révoquer l'accès du Client à partir d'un Utilisateur particulier, nous devrions marquer le jeton d'actualisation correspondant comme "révoqué" (ou l'enlever complètement) et cesser d'émettre de nouveaux jetons d'accès. Il est cependant évident qu’il ya une fenêtre pendant laquelle le jeton de rafraîchissement a été révoqué, mais son jeton d’accès peut toujours être valide.

Les compromis

Les jetons d'actualisation éliminent partiellement le SPoF (Single Point of Failure) de la base de données Access Token, mais ils présentent des inconvénients évidents.

  1. La fenêtre". Un délai entre les événements «l'utilisateur révoque l'accès» et «l'accès est garanti pour être révoqué».

  2. La complication de la logique client.

    sans pour autant Actualiser le jeton

    • Envoyer une demande d'API avec un jeton d'accès
    • si le jeton d'accès est invalide, échouer et demander à l'utilisateur de s'authentifier à nouveau

    avec Actualiser le jeton

    • Envoyer une demande d'API avec un jeton d'accès
    • Si le jeton d'accès n'est pas valide, essayez de le mettre à jour à l'aide du jeton d'actualisation.
    • si la demande de rafraîchissement passe, mettez à jour le jeton d'accès et renvoyez la demande d'API initiale
    • Si la demande de rafraîchissement échoue, demandez à l'utilisateur de s'authentifier à nouveau

J'espère que cette réponse a du sens et aide quelqu'un à prendre des décisions plus réfléchies. Je voudrais également noter que certains fournisseurs OAuth2 bien connus, y compris github et foursquare adoptent le protocole sans jetons d'actualisation, et semblent heureux avec cela.


449
2017-10-14 19:38



En dépit de toutes les bonnes réponses ci-dessus, en tant qu'étudiant en master de sécurité et programmeur qui travaillait auparavant chez eBay lorsque je jetais un coup d'œil sur la protection des acheteurs et la fraude, je peux dire meilleur équilibre entre utilisateur harcelant de fréquent saisie du nom d'utilisateur / mot de passe et maintien de l'autorité en main pour révoquer l'accès au potentiel abuser de de votre service.

Pensez à un scénario comme celui-ci. Vous émettez l'utilisateur d'un jeton d'accès de 3600 secondes et actualisez le jeton beaucoup plus longtemps qu'un jour.

  1. L'utilisateur est un bien utilisateur, il est à la maison et obtient sur / hors de votre site shopping et de la recherche sur son iPhone. Son adresse IP ne change pas et la charge sur votre serveur est très faible. Comme 3-5 pages demande chaque minute. Lorsque ses 3600 secondes sur le jeton d'accès sont terminées, il en requiert une nouvelle avec le jeton d'actualisation. Nous, du côté serveur, vérifions son historique d'activité et son adresse IP, pensons qu'il est un humain et qu'il se comporte lui-même. Nous lui accordons un nouveau jeton d'accès pour continuer à utiliser notre service. L'utilisateur n'aura pas besoin de saisir à nouveau le nom d'utilisateur / mot de passe avant d'avoir atteint la durée de vie du jeton d'actualisation.

  2. L'utilisateur est un négligent utilisateur. Il vit dans New York, États-Unis et a arrêté son programme de virus et a été piraté par un pirate Pologne. Lorsque le pirate a obtenu le jeton d’accès et actualise le jeton, il essaie d’emprunter l’identité de l’utilisateur et d’utiliser notre service. Mais après l'expiration du jeton d'accès de courte durée, lorsque le pirate tente d'actualiser le jeton d'accès, nous remarquons sur le serveur un changement spectaculaire de l'historique de comportement de l'utilisateur (hé, ce type se connecte aux USA et rafraîchit son accès en Pologne après seulement 3600s ???). Nous terminons le processus de rafraîchissement, invalide le jeton d'actualisation lui-même et demandons à entrer à nouveau le nom d'utilisateur / mot de passe.

  3. L'utilisateur est un mal intentionné utilisateur. Il est destiné à abuser de notre service en appelant 1000 fois notre API chaque minute en utilisant un robot. Il peut bien le faire jusqu'à 3600 secondes plus tard, quand il essaie de rafraîchir le jeton d'accès, nous avons remarqué son comportement et pensons qu'il pourrait ne pas être un humain. Nous rejetons et terminons le processus d'actualisation et lui demandons d'entrer à nouveau le nom d'utilisateur / mot de passe. Cela pourrait potentiellement casser le flux automatique de son robot. Au moins le rend mal à l'aise.

Vous pouvez voir que le jeton d'actualisation a parfaitement fonctionné lorsque nous essayons d'équilibrer notre travail, l'expérience utilisateur et le risque potentiel d'un jeton volé. Votre chien de garde du côté du serveur peut vérifier plus que le changement d'IP, la fréquence des appels d'API pour déterminer si l'utilisateur doit être un bon utilisateur ou non.

Un autre mot est que vous pouvez également essayer de limiter le contrôle des dommages de jeton volé / abus de service en mettant en œuvre sur chaque appel API le chien de surveillance IP de base ou d'autres mesures. Mais cela coûte cher car vous devez lire et écrire un enregistrement sur l'utilisateur et ralentir la réponse de votre serveur.


110
2018-06-18 19:58



Aucune de ces réponses n'aboutit à la raison principale pour laquelle les jetons d'actualisation existent. Évidemment, vous pouvez toujours obtenir une nouvelle paire access-token / refresh-token en envoyant vos informations d'identification client au serveur d'authentification - c'est comme cela que vous les obtenez en premier lieu.

Le seul but du jeton d'actualisation est donc de limiter l'utilisation des informations d'identification du client envoyées via le fil au service d'authentification. Plus le ttl du jeton d'accès est court, plus souvent les informations d'identification du client doivent être utilisées pour obtenir un nouveau jeton d'accès, et plus les attaquants ont de chances de compromettre les informations d'identification du client (même si cela peut être très difficile). le cryptage asymétrique est utilisé pour les envoyer). Donc, si vous avez un jeton d'actualisation à usage unique, vous pouvez rendre le ttl d'access-tokens arbitrairement petit sans compromettre les informations d'identification du client.


58
2017-08-02 19:11



Cette réponse vient de Justin Richer via la liste de diffusion standard OAuth 2. Ceci est affiché avec sa permission.


La durée de vie d'un jeton d'actualisation dépend du serveur d'autorisations (AS) - ils peuvent expirer, être révoqués, etc. La différence entre un jeton d'actualisation et un jeton d'accès est l'audience: le jeton d'actualisation revient uniquement au serveur d'autorisation, le jeton d'accès va au serveur de ressources (RS).

De plus, le simple fait d'obtenir un jeton d'accès ne signifie pas que l'utilisateur est connecté. En fait, l'utilisateur n'est peut-être même plus là, ce qui est en fait le cas d'utilisation prévu du jeton d'actualisation. Le fait d'actualiser le jeton d'accès vous donnera accès à une API pour le compte de l'utilisateur, il ne vous dira pas si l'utilisateur est présent.

OpenID Connect ne vous fournit pas seulement des informations utilisateur à partir d'un jeton d'accès, il vous donne également un jeton d'identification. Il s’agit d’une donnée distincte adressée au client lui-même et non à l’AS ou à la RS. Dans OIDC, vous ne devriez considérer qu'une personne "connectée" par le protocole si vous pouvez obtenir un nouveau jeton d'ID. Rafraîchissant, il ne sera probablement pas suffisant.

Pour plus d'informations, veuillez lire http://oauth.net/articles/authentication/


31
2017-08-30 23:04



Pour dissiper une certaine confusion, vous devez comprendre les rôles du secret client et le mot de passe de l'utilisateur, qui sont très différents.

le client est une application / site web / programme / ..., soutenue par un serveur, qui veut authentifier une utilisateur en utilisant un service d'authentification tiers. Le secret client est une chaîne (aléatoire) connue de ce client et du serveur d'authentification. En utilisant ce secret, le client peut s’identifier auprès du serveur d’authentification, en recevant autorisation pour demander des jetons d'accès.

Pour obtenir le jeton d'accès initial et le jeton d'actualisation, ce qui est requis est:

  • L'ID utilisateur
  • Le mot de passe de l'utilisateur
  • L'ID du client
  • Le secret du client

Pour obtenir un jeton d'accès actualisé, le client utilise les informations suivantes:

  • L'ID du client
  • Le secret du client
  • Le jeton d'actualisation

Cela montre clairement la différence: lors de l'actualisation, le client reçoit l'autorisation d'actualiser les jetons d'accès en utilisant son secret client, et peut donc ré-authentifier l'utilisateur en utilisant le jeton d'actualisation. au lieu de l'ID utilisateur + mot de passe. Cela empêche efficacement l'utilisateur de ressaisir son mot de passe.

Cela montre également que perdre un jeton d'actualisation n'est pas un problème car l'ID du client et le secret ne sont pas connus. Cela montre également que le secret de l'identification du client et du secret client est vital.


25
2018-03-04 09:36



Les clients peuvent être compromis de plusieurs façons. Par exemple, un téléphone portable peut être cloné. L'expiration d'un jeton d'accès signifie que le client est contraint de s'authentifier de nouveau auprès du serveur d'autorisation. Lors de la ré-authentification, le serveur d'autorisation peut vérifier d'autres caractéristiques (IOW effectue une gestion d'accès adaptative).

Les jetons d'actualisation permettent à un client de ne procéder qu'à une réauthentification, alors que la réautorisation force un dialogue avec l'utilisateur que beaucoup ont indiqué qu'ils préfèrent ne pas faire.

Les jetons d'actualisation s'intègrent essentiellement au même endroit où les sites Web normaux peuvent choisir de ré-authentifier périodiquement les utilisateurs au bout d'une heure environ (par exemple un site bancaire). Il n'est pas très utilisé actuellement puisque la plupart des sites Web sociaux ne réauthentifient pas les utilisateurs Web, alors pourquoi ré-authentifier un client?


19
2017-08-18 18:40