Pourquoi OAuth v2 a-t-il à la fois des jetons d'accès et d'actualisation?


654

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

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

Pourquoi avoir les deux? Pourquoi ne pas simplement faire le access_tokendernier aussi longtemps que le refresh_tokenet ne pas en avoir refresh_token?

Réponses:


463

L'idée de rafraîchir les jetons est que si un jeton d'accès est compromis, car il est de courte durée, l'attaquant dispose d'une fenêtre limitée pour en abuser.

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

Cela dit , parce que chaque appel au serveur d'autorisation et au serveur de ressources se fait via SSL - y compris l'ID client et le secret d'origine lorsqu'ils demandent les jetons d'accès / d'actualisation - je ne suis pas sûr de savoir comment le jeton d'accès est plus " compromisable "que le jeton de rafraîchissement de longue durée et la combinaison client / secret.

Bien sûr, cela est différent des implémentations où vous ne contrôlez pas à la fois les serveurs d'autorisation et de ressources.

Voici un bon fil de discussion sur les utilisations des 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 d'un access_token de longue durée (paramètre de requête dans un fichier journal sur un serveur de ressources non sécurisé, application bêta ou serveur de ressources mal codé, client JS SDK sur un site non https qui place le access_token dans un cookie, etc.)


14
Catchdave a raison mais a pensé que j'ajouterais que les choses ont évolué depuis sa réponse initiale. L'utilisation de SSL est désormais facultative (cela était probablement encore en discussion lorsque catchdave a répondu). Par exemple, les jetons MAC (en cours de développement) offrent la possibilité de signer la demande avec une clé privée afin que SSL ne soit pas requis. Les jetons d'actualisation deviennent donc très importants car vous voulez avoir des jetons Mac de courte durée.
AlexGad

54
"Les jetons de rafraîchissement, s'ils sont compromis, sont inutiles car l'attaquant a besoin de l'identifiant client et du secret en plus du jeton de rafraîchissement pour obtenir un jeton d'accès." Mais l'identifiant et le secret du client sont également stockés dans l'appareil, n'est-ce pas? Ainsi, un attaquant ayant accès à l'appareil peut les obtenir. Alors pourquoi? Ici, github.com/auth0/lock/wiki/Using-a-Refresh-Token , il est écrit que la perte d'un jeton d'actualisation signifie qu'il peut demander autant de jetons d'authentification qu'il le souhaite, peut-être pas dans le scénario googles, mais que faire si j'implémente mon propre serveur oauth2?
Jamsheed Kamarudeen

42
"L'attaquant a besoin de l'identifiant client et du secret en plus du jeton d'actualisation pour obtenir un jeton d'accès" : alors quelle est la différence entre utiliser un jeton d'actualisation et simplement démissionner?
sp00m

34
Le jeton d'actualisation peut être utilisé par un tiers qui peut renouveler le jeton d'accès sans aucune connaissance des informations d'identification de l'utilisateur.
Marek décembre

27
@KevinWheeler Non, l'ID client et le secret sont des informations d'identification pour le client OAuth, pas pour l'utilisateur. Quand on parle d'OAuth, le "client" est généralement un serveur (par exemple le serveur Web stackoverflow) qui s'interface avec un serveur d'autorisation ou d'API de ressources (par exemple le fournisseur d'authentification facebook). Les informations d'identification de l'utilisateur sont uniquement transmises entre l'utilisateur et le serveur API OAuth et ne sont jamais connues du client. Le secret client est uniquement transmis du client au serveur API OAuth et n'est jamais connu de l'utilisateur.
machine désirant le

551

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

Mon souvenir de jetons d'actualisation é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 voir si le jeton d'accès est valide, ce qui simplifie la validation du jeton 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 la situation 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 d'eux est (généralement) également sécurisée, il n'y a pas beaucoup de sens à garder le jeton d'actualisation séparé du jeton d'accès.

Bien que, comme mentionné dans la citation, un autre rôle des jetons d'actualisation est de garantir que le jeton d'accès peut être révoqué à tout moment par l'utilisateur (via l'interface Web dans leurs profils, par exemple) tout en gardant le système évolutif en même temps. .

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

Fonctionnement du système avec des jetons d'accès longue durée

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

Fonctionnement du système avec jeton d'actualisation longue durée et jeton d'accès courte durée

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

Comme le jeton d'accès est autonome, nous n'avons pas du tout besoin de frapper la base de données pour vérifier sa validité. Il suffit de décoder le token et de valider la signature et l'horodatage.

Néanmoins, nous devons encore conserver la base de données des jetons d'actualisation, mais le nombre de requêtes vers 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 faible).

Afin de révoquer l'accès du client d'un utilisateur particulier, nous devons marquer le jeton d'actualisation correspondant comme "révoqué" (ou le supprimer complètement) et cesser d'émettre de nouveaux jetons d'accès. Il est évident cependant qu'il existe une fenêtre pendant laquelle le jeton d'actualisation a été révoqué, mais son jeton d'accès peut toujours être valide.

Compromis

Les jetons d'actualisation éliminent partiellement le SPoF (Single Point of Failure) de la base de données des jetons d'accès, mais ils présentent certains 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 d'être révoqué».

  2. La complication de la logique client.

    sans jeton d'actualisation

    • envoyer une demande d'API avec un jeton d'accès
    • si le jeton d'accès n'est pas valide, échouez et demandez à l'utilisateur de se réauthentifier

    avec jeton d'actualisation

    • 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 d'actualisation réussit, 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 se réauthentifier

J'espère que cette réponse a du sens et aide quelqu'un à prendre une décision plus réfléchie. Je voudrais également noter que certains fournisseurs OAuth2 bien connus, y compris github et foursquare, adoptent le protocole sans rafraîchir les jetons, et semblent satisfaits de cela.


4
@RomannImankulov Si je comprends bien le jeton de rafraîchissement, nous pouvons l'enregistrer dans db et les supprimer chaque fois que nous voulons révoquer l'accès, alors pourquoi ne pas enregistrer les jetons d'accès lui-même?
kosnkov

30
@kosnkov la version courte de mon message est, si vous enregistrez le jeton d'accès dans la base de données, vous frappez la base de données à chaque demande à votre API (ce qui peut ou non être un problème dans votre cas particulier). Si vous enregistrez des jetons d'actualisation et conservez les jetons d'accès "autonomes", vous accédez à la base de données uniquement lorsque le client décide d'actualiser le jeton d'accès.
Roman Imankulov

5
Personnellement, je n'aime pas cette approche consistant à ne pas frapper la base de données pour gagner en performances si cela va compromettre la sécurité (ne serait-ce que pour la durée de la fenêtre). On devrait être en mesure de révoquer un access_token immédiatement si nécessaire, car nous traitons presque toujours des informations utilisateur sensibles (sinon nous n'utiliserions probablement pas OAuth en premier lieu). Je me demande quelle approche les grandes entreprises comme Facebook et Google utilisent.
Tiago

1
Je ne comprends pas bien pourquoi nous devons avoir la "fenêtre ouverte" pendant un certain temps. Pourquoi ne pouvons-nous pas simplement envoyer une demande au serveur de ressources pour ne pas accepter les jetons d'accès pour cet utilisateur? Est-ce que j'ai raison de dire que vous ne pouvez pas avoir un comportement de rafraîchissement de jeton lorsque vous n'avez pas de secret client pour signer des jetons? Donc, fondamentalement, vous ne pouvez pas utiliser de jetons d'actualisation à partir de logiciels sur des appareils cliemts js, des applications de bureau mobiles, etc.
Igor Čordaš

1
@PSIXO le serveur de ressources n'a pas de stockage persistant en plus de la base de données et peut-être un cache local. Par conséquent, la seule façon dont il peut vérifier si un jeton est révoqué est de toucher la base de données, ce que tout ce processus essaie d'éviter. Quant à votre 2e question, vous n'avez pas raison. Si vous disposez d'un jeton d'actualisation, vous pouvez demander de nouveaux jetons d'accès.
bernie

199

Malgré toutes les bonnes réponses ci-dessus, en tant qu'étudiant en master de sécurité et programmeur qui a précédemment travaillé chez eBay lorsque j'ai examiné la protection des acheteurs et la fraude, je peux dire que séparer le jeton d'accès et rafraîchir le jeton a son meilleur équilibre entre le harcèlement de l'utilisateur du nom d'utilisateur fréquent / saisie du mot de passe et en gardant l'autorité en main pour révoquer l'accès à un abus potentiel de votre service.

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

  1. L'utilisateur est un bon utilisateur, il est à la maison et monte / descend de votre site Web en faisant des achats et des recherches sur son iPhone. Son adresse IP ne change pas et a une charge très faible sur votre serveur. Comme 3-5 demandes de page chaque minute. Lorsque ses 3600 secondes sur le jeton d'accès sont terminées, il en a besoin d'une nouvelle avec le jeton d'actualisation. Du côté serveur, nous vérifions son historique d'activité et son adresse IP, pensons qu'il est un humain et 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 d'un jeton d'actualisation lui-même.

  2. L'utilisateur est un utilisateur imprudent . Il vit à New York, aux États - Unis et a fait fermer son programme antivirus et a été piraté par un pirate en Pologne . Lorsque le pirate a obtenu le jeton d'accès et le jeton d'actualisation, il essaie de se faire passer pour 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 de rafraîchir le jeton d'accès, nous, sur le serveur, avons remarqué un changement IP spectaculaire dans l'historique du comportement des utilisateurs (hé, ce type se connecte aux États-Unis et actualise maintenant l'accès en Pologne après seulement 3600 ???). Nous terminons le processus d'actualisation, invalidons le jeton d'actualisation lui-même et demandons de saisir à nouveau le nom d'utilisateur / mot de passe.

  3. L'utilisateur est un utilisateur malveillant . Il est destiné à abuser de notre service en appelant 1000 fois notre API chaque minute à l'aide d'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 de rafraîchissement et lui demandons de saisir à nouveau le nom d'utilisateur / mot de passe. Cela pourrait potentiellement interrompre le flux automatique de son robot. Au moins le met 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 côté serveur peut vérifier plus que le changement d'IP, la fréquence des appels 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 des jetons volés / abus de service en mettant en œuvre sur chaque api appeler le chien de garde IP de base ou toute autre mesure. Mais cela coûte cher car vous devez lire et écrire des enregistrements sur l'utilisateur et ralentir la réponse de votre serveur.


@laalaguer Avez-vous des politiques plus fines comme par exemple: Ne révoquez pas le jeton lorsque l'adresse IP de l'utilisateur est modifiée (lorsque le téléphone mobile se déconnecte du WiFi et se connecte au réseau 3G / 4G)?
svlada

65
Ce sont d'excellentes politiques et idées, mais je ne vois rien dans votre réponse qui nécessite intrinsèquement l'utilisation de jetons d'actualisation. Toutes ces fonctionnalités peuvent être implémentées avec uniquement le jeton d'accès.
Evert

12
@Evert, l'un des avantages de l'utilisation des jetons d'accès et d'actualisation est que les jetons d'accès peuvent être de courte durée et qu'il ne s'agit donc pas d'un compromis de sécurité de leur faire confiance sans condition sans vérifier auprès du serveur qui les a initialement émis. Cela peut vous permettre de faire évoluer votre infrastructure afin que des parties non critiques de celle-ci puissent faire confiance aux informations stockées dans le jeton (signé) sans accès direct aux informations de compte de l'utilisateur.
Avi Cherry

7
@Avi Cherry - Oui, un jeton d'accès peut être de courte durée, et il peut également être actualisé si l'utilisateur est toujours considéré comme valide. Ne nécessite pas de jeton d'actualisation pour ce faire.
Rick Jolly

10
Je crois que cette réponse suppose que nous ne voulons jamais que les serveurs de ressources effectuent eux-mêmes un contrôle d'accès avancé (par exemple, vérifient l'activité IP par rapport à diverses bases de données, etc.) et qu'ils ne peuvent se fier qu'à la vérification du jeton d'accès de manière totalement isolée. Bien que cela puisse être évident à l'échelle (pour des raisons de performances), cela n'est clairement pas évident pour tout le monde ici, étant donné la confusion dans d'autres articles et commentaires. C'est un bon article avec de belles informations, mais je pense qu'il manque beaucoup le point de la question d'origine. Je recommande au moins de rendre explicite l'hypothèse susmentionnée.
2017 à

72

Aucune de ces réponses n'atteint la raison principale pour laquelle les jetons d'actualisation existent. Évidemment, vous pouvez toujours obtenir une nouvelle paire jeton d'accès / jeton d'actualisation en envoyant vos informations d'identification client au serveur d'authentification - c'est ainsi que vous les obtenez en premier lieu.

Par conséquent, le seul objectif du jeton d'actualisation est de limiter l'utilisation des informations d'identification du client envoyées par câble au service d'authentification. Plus le ttl du jeton d'accès est court, plus les informations d'identification client devront être utilisées pour obtenir un nouveau jeton d'accès, et donc plus les attaquants auront de possibilités de compromettre les informations d'identification client (bien que cela puisse être très difficile de toute façon si un cryptage asymétrique est utilisé pour les envoyer). Donc, si vous avez un jeton d'actualisation à usage unique, vous pouvez réduire arbitrairement le ttl des jetons d'accès sans compromettre les informations d'identification du client.


16
C'est intéressant car dans le cas de Google, lorsque vous demandez un jeton d'actualisation, vous envoyez également l'ID client et le secret client. Vous comprenez donc toutes les heures de toute façon.
Rots

1
Alexander, en fait, plus le ttl est court, plus le client devra souvent obtenir un nouveau jeton d'accès (ce qui nécessite l'utilisation des informations d'identification du client). Donc, je veux dire en fait «plus court» là-bas. Je vais ajouter une note pour clarifier.
BT

2
"but unique" - ne se lave pas. Faire le TTL du jeton d'accès aussi longtemps que celui du jeton de rafraîchissement imaginé atteindra exactement la même chose.
Rhubarbe

8
Étant donné que la norme exige que les informations d'identification du client soient envoyées avec le jeton d'actualisation, la prémisse de cette réponse est simplement fausse. "Parce que les jetons d'actualisation sont généralement des informations d'identification de longue durée utilisées pour demander des jetons d'accès supplémentaires ... le client DOIT s'authentifier auprès du serveur d'autorisation." Voir également le commentaire de @Rots.
Kevin Christopher Henry

8
A) Je pense que vous mélangez les secrets des clients et les secrets des utilisateurs. Le secret client n'est jamais envoyé depuis la machine utilisateur, uniquement depuis l'application backend d'accès vers l'application backend fournissant des données. B) Le serveur oAuth qui autorise l'octroi de mot de passe pour un client public (un client qui ne peut pas garder un client secret tel qu'une application native ou javascript) fournira également une autorisation d'actualisation pour ce client public, vous n'avez donc pas besoin de envoyer un secret client lors de l'actualisation de votre token. C) Le jeton de rafraîchissement fournit au backend un "battement de coeur" quand vérifier la validité de l'utilisateur!
Andreas Lundgren

55

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

Le client est une application / site Web / programme / ..., soutenu par un serveur, qui souhaite authentifier un utilisateur à l'aide d'un service d'authentification tiers. Le secret client est une chaîne (aléatoire) connue de ce client et du serveur d'authentification. À l'aide de ce secret, le client peut s'identifier auprès du serveur d'authentification et recevoir l' autorisation de 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 utilisateur
  • L'ID client
  • Le secret client

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

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

Cela montre clairement la différence: lors de l'actualisation, le client reçoit l'autorisation de rafraîchir les jetons d'accès en utilisant son secret client, et peut ainsi ré-authentifier l'utilisateur à l'aide du jeton de rafraîchissement au lieu de l'ID utilisateur + mot de passe. Cela évite effectivement à l'utilisateur d'avoir à ressaisir son mot de passe.

Cela montre également que la perte d'un jeton d'actualisation ne pose aucun problème car l'ID client et le secret ne sont pas connus. Cela montre également que le maintien de l'ID client et du secret client est vital .


1
"Cela montre également que la perte d'un jeton d'actualisation n'est pas un problème car l'ID client et le secret ne sont pas connus". Mais je n'en ai pas besoin. Si j'ai un jeton d'actualisation, je peux le transmettre à votre serveur d'applications. Il ajoute client_id et secret, puis passe les trois au service OAuth. À quoi ça sert?
3DFace

7
Le serveur d'applications ne fournit pas un moyen de fournir vous-même un jeton d'actualisation, vous ne pouvez pas lui demander de générer un nouveau jeton d'authentification en lui donnant un jeton d'actualisation. Il renouvelle le jeton d'authentification lui-même en cas de besoin, "dans les coulisses".
Adversus

2
Notez que vous avez en fait besoin du secret client pour obtenir le jeton d'actualisation en premier lieu. Vous pensez peut-être au flux d'authentification implicite, où vous n'avez pas besoin de secret, mais les jetons d'actualisation ne sont pas émis ou utilisés dans ce cas.
Kevin Christopher Henry

@KevinChristopherHenry ce genre de suggestion que pour un utilisateur final se connectant simplement au site Web de l'entreprise XYZ.com un jeton d'actualisation n'a aucun sens pour obtenir un nouveau jeton d'accès pour XYZ.com? Mais un jeton d'actualisation peut être n'importe quelle chaîne non devinable - comme un guide - stockée dans une table qui peut être recherchée très rapidement. Alors qu'un jeton d'accès peut être beaucoup plus long et plus difficile à indexer dans une base de données. Ainsi, le jeton d'actualisation PEUT être stocké et présente des avantages pour l'utilisateur final. [bien que puisque cette question parle de oauth2, toutes les réponses sans un service tiers qui agit au nom d'une personne ne sont peut-être pas pertinentes de toute façon]
Simon_Weaver

pourquoi ne pouvez-vous pas simplement transmettre «L'identifiant client» + «Le secret client» + «Jeton d'accès expiré» pour obtenir un nouveau jeton d'accès?
Honey

37

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


La durée de vie d'un jeton d'actualisation dépend du serveur d'autorisation (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 ne retourne qu'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 pourrait même ne plus être là, ce qui est en fait le cas d'utilisation prévu du jeton d'actualisation. L'actualisation du jeton d'accès vous donnera accès à une API au nom de l'utilisateur, il ne vous dira pas si l'utilisateur s'y trouve.

OpenID Connect ne vous donne pas seulement des informations utilisateur à partir d'un jeton d'accès, il vous donne également un jeton ID. Il s'agit d'une donnée distincte dirigée vers le client lui-même, pas l'AS ou le RS. Dans OIDC, vous ne devriez considérer quelqu'un réellement «connecté» par le protocole que si vous pouvez obtenir un nouveau jeton d'identification. Le rafraîchir ne suffira probablement pas.

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


Cela semble concerner OpenID Connect et l'authentification, donc je ne vois pas comment cela répond à la question, qui concerne la motivation pour avoir un rafraîchissement de jeton.
sleske

18

Les clients peuvent être compromis de plusieurs manières. Par exemple, un téléphone portable peut être cloné. La date d'expiration d'un jeton d'accès signifie que le client est obligé 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 (l'IOW effectue une gestion adaptative des accès).

Les jetons d'actualisation permettent une réauthentification uniquement pour le client, alors que la nouvelle autorisation force une boîte de dialogue avec l'utilisateur, ce que beaucoup ont indiqué qu'ils préféreraient 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 après environ une heure (par exemple, un site bancaire). Il n'est pas très utilisé à l'heure actuelle, car la plupart des sites Web sociaux ne réauthentifient pas les utilisateurs Web, alors pourquoi réauthentifieraient-ils un client?


2
"Les jetons d'actualisation permettent une ré-authentification uniquement par le client ..." est un aspect important ici.
James

13

Pourquoi ne pas simplement faire durer access_token aussi longtemps que refresh_token et ne pas avoir un refresh_token?

En plus des excellentes réponses fournies par d'autres personnes, il y a une autre raison pour laquelle utiliser des jetons d'actualisation et son rapport avec les revendications.

Chaque jeton contient des revendications qui peuvent inclure n'importe quoi du nom des utilisateurs, de leurs rôles ou du fournisseur qui a créé la revendication. Lorsqu'un jeton est actualisé, ces revendications sont mises à jour.

Si nous actualisons les jetons plus souvent, nous mettons évidemment plus de pression sur nos services d'identité, mais nous obtenons des réclamations plus précises et à jour.


4
Ce serait une mauvaise pratique inhabituelle de mettre de telles «revendications» dans le jeton d'accès. Comme décrit dans la spécification , le jeton d'accès "est généralement opaque pour le client". Avez-vous des exemples de fournisseurs OAuth qui font cela?
Kevin Christopher Henry

3
@heymega Lorsque le rôle d'utilisateur est rétrogradé d'ADMIN à REGULAR_USER, le rôle d'utilisateur doit être révoqué immédiatement et non lorsque expire access_token. Il semble donc inévitable de toucher la base de données à chaque demande.
svlada

@svlada J'imagine que ce serait un cas où l'application déclassant une entité d'ADMIN à REGULAR_USER aurait (dans le même processus) également à révoquer le jeton approprié. c'est-à-dire si nous savons que les revendications vont changer, nous n'attendons pas l'expiration, nous révoquons immédiatement
e_i_pi

13

Pour simplifier davantage la réponse de BT: utilisez des jetons d'actualisation lorsque vous ne voulez généralement pas que l'utilisateur doive saisir à nouveau ses informations d'identification, mais que vous souhaitez toujours pouvoir révoquer les autorisations (en révoquant le jeton d'actualisation)

Vous ne pouvez pas révoquer un jeton d'accès, uniquement un jeton d'actualisation.


1
Vous pouvez révoquer un jeton d'accès, ce qui nécessite de vous reconnecter pour un autre jeton d'accès ou d'utiliser le jeton d'actualisation pour obtenir un autre jeton d'accès. Si le jeton d'actualisation n'était pas valide, l'utilisateur devra se ré-authentifier pour obtenir un nouveau jeton d'accès avec un nouveau jeton d'actualisation.
Atieh

10
Je ne suis pas d'accord. Un jeton d'accès est émis par le serveur d'authentification, signé avec une date d'expiration et envoyé au client. Lorsque le client envoie ce jeton au serveur de ressources, le serveur de ressources ne contacte pas le serveur d'authentification pour vérifier le jeton; il regarde juste la date d'expiration dans le jeton (signé et non falsifié). Donc, peu importe ce que vous faites sur le serveur d'authentification pour essayer de «révoquer», le serveur de ressources s'en fiche. Certaines personnes se réfèrent à la déconnexion du client comme une révocation (c'est-à-dire que le client supprime son jeton) mais à mon humble avis, c'est une terminologie trompeuse - nous voulons «révoquer» un jeton sur le serveur, pas sur le client
bitcoder

1
Ne pas dire que vous ne pouviez pas écrire de code personnalisé pour ignorer certains jetons (comme ici stackoverflow.com/questions/22708046/… ), mais cela implique probablement des déplacements réseau du serveur de ressources vers le serveur oauth / db chaque fois que le client effectue un appel. Vous évitez ces appels en utilisant des jetons d'actualisation à la place, et je pense que cela correspond davantage à ce que les auteurs de Oauth voulaient.
bitcoder

13

Cette réponse a été élaborée avec l'aide de deux développeurs seniors (John Brayton et David Jennes).

La principale raison d'utiliser un jeton d'actualisation est de réduire la surface d'attaque.

Supposons qu'il n'y ait pas de clé d'actualisation et passons par cet exemple:

Un bâtiment a 80 portes. Toutes les portes sont ouvertes avec la même clé. La clé change toutes les 30 minutes. À la fin des 30 minutes, je dois remettre l'ancienne clé au fabricant de clés et obtenir une nouvelle clé.

Si je suis le pirate informatique et que je récupère votre clé, à la fin des 30 minutes, je vais l'envoyer par courrier au fabricant de clés et obtenir une nouvelle clé. Je pourrai ouvrir toutes les portes en continu quel que soit le changement de clé.

Question: Pendant les 30 minutes, combien de possibilités de piratage ai-je eues contre la clé? J'ai eu 80 opportunités de piratage, chaque fois que vous avez utilisé la clé (pensez à cela comme faisant une demande réseau et en passant le jeton d'accès pour vous identifier). C'est donc une surface d'attaque 80X.

Passons maintenant au même exemple mais cette fois supposons qu'il y a une clé de rafraîchissement.

Un bâtiment a 80 portes. Toutes les portes sont ouvertes avec la même clé. La clé change toutes les 30 minutes. Pour obtenir une nouvelle clé, je ne peux pas transmettre l'ancien jeton d'accès. Je dois seulement passer la clé de rafraîchissement.

Si je suis le pirate informatique et que je récupère votre clé, je peux l'utiliser pendant 30 minutes, mais à la fin des 30 minutes, l'envoyer au keymaker n'a aucune valeur. Si je le fais, le keymaker dirait simplement ce mauvais jeton de rafraîchissement. Pour pouvoir étendre mon hack, je devrais pirater le courrier du keymaker. Le courrier a une clé distincte (pensez-y comme un jeton de rafraîchissement).

Question: Pendant les 30 minutes, combien de possibilités de piratage ai-je eues contre la touche d'actualisation? 80? Non, je n'ai eu qu'une seule possibilité de piratage. Pendant le temps, le courrier communique avec le keymaker. C'est donc une surface d'attaque 1X. J'ai eu 80 opportunités de piratage contre la clé, mais elles ne sont pas bonnes après 30 minutes.


Un serveur vérifierait un jeton d'accès basé sur les informations d'identification et la signature (généralement) d'un JWT.

Une fuite de jeton d'accès est mauvaise, mais une fois expirée, elle n'est plus utile à un attaquant. Un jeton de rafraîchissement qui fuit est bien pire, mais il est probablement moins probable. (Je pense qu'il est possible de se demander si la probabilité d'une fuite de jeton d'actualisation est beaucoup plus faible que celle d'une fuite de jeton d'accès, mais c'est l'idée.)

Le fait est que le jeton d'accès est ajouté à chaque demande que vous faites, alors qu'un jeton de rafraîchissement n'est utilisé que pendant le flux de rafraîchissement.

La fréquence aide un attaquant. Des failles de sécurité potentielles de type Heartbleed dans SSL, des failles de sécurité potentielles dans le client et des failles de sécurité potentielles dans le serveur permettent toutes des fuites.

En outre, si le serveur d'autorisation est distinct du serveur d'applications traitant d'autres demandes client, ce serveur d'applications ne verra jamais de jetons d'actualisation. Il ne verra que les jetons d'accès qui ne vivront pas longtemps.

La compartimentation est bonne pour la sécurité.

Dernier point mais non le moindre, voyez cette réponse impressionnante


De quel jeton d'actualisation n'est PAS question?

La possibilité de mettre à jour / révoquer le niveau d'accès via des jetons d'actualisation est un sous-produit du choix d'utiliser des jetons d'actualisation, sinon un jeton d'accès autonome pourrait être révoqué ou avoir son niveau d'accès modifié à son expiration et les utilisateurs obtiennent un nouveau jeton


2
il est difficile de suivre cette comparaison car les questions sont différentes 1. "Pendant les 30 minutes, combien de possibilités de piratage ai-je eues contre la clé?" (N'avais-je pas d'abord la clé en tant que pirate?) 2. "Pendant les 30 minutes, combien de possibilités de piratage ai-je eues contre le coursier?". Que serait une «opportunité de piratage»? En tant que hacker, je n'avais pas la clé en premier lieu?
Cesc

1
Tu as raison. J'ai apporté des modifications
Honey

4

Supposons que vous faites le access_tokendernier très longtemps, et que vous ne l'avez pas refresh_token, alors en un jour, le pirate récupère cela access_tokenet il peut accéder à toutes les ressources protégées!

Mais si vous l'avez refresh_token, le access_tokentemps de live est court, donc le pirate est difficile à pirater access_tokencar il sera invalide après une courte période. Access_tokenne peut être récupéré qu'en utilisant non seulement refresh_tokenmais aussi par client_idet client_secret, ce que le pirate n'a pas.


2
"en utilisant non seulement refresh_token mais aussi par client_id et client_secret, que le pirate n'a pas." 1. supposons que ce n'est qu'un jeton d'accès, alors le pirate n'a-t-il pas encore besoin de client_id et client_secret? 2. si un pirate est un bon pirate, il peut également pirater client_id et client_secret. Quelle que soit cette partie, le piratage de choses supplémentaires ne devrait pas avoir d'importance pour la comparaison, car s'il est difficile de pirater, il est également difficile de pirater dans le cas de l'utilisation d'un jeton d'accès ... bref, vous ne comparez pas des situations identiques. Vous les
mélangez

2

Le jeton d'actualisation est conservé par le serveur d'autorisation. Les jetons d'accès sont autonomes afin que le serveur de ressources puisse le vérifier sans le stocker, ce qui économise l'effort de récupération en cas de validation. Un autre point manquant dans la discussion provient de rfc6749 # page-55

"Par exemple, le serveur d'autorisation pourrait utiliser une rotation de jeton d'actualisation dans laquelle un nouveau jeton d'actualisation est émis avec chaque réponse d'actualisation du jeton d'accès. Le jeton d'actualisation précédent est invalidé mais conservé par le serveur d'autorisation. Si un jeton d'actualisation est compromis et ensuite utilisé par à la fois l'attaquant et le client légitime, l'un d'eux présentera un jeton d'actualisation invalidé, qui informera le serveur d'autorisation de la violation. "

Je pense que l'intérêt d'utiliser le jeton de rafraîchissement est que même si l'attaquant parvient à obtenir le jeton de rafraîchissement, l'ID client et la combinaison secrète. Avec les appels ultérieurs pour obtenir un nouveau jeton d'accès de l'attaquant, il peut être suivi au cas où chaque demande de rafraîchissement entraînerait un nouveau jeton d'accès et un nouveau jeton de rafraîchissement.


Je pense que c'est un point très important :-) Cela invalide également - dans une certaine mesure - l'argument ici auth0.com/docs/tokens/refresh-token/current#restrictions queA Single-Page Application (normally implementing Single-Page Login Flow) should not under any circumstances get a Refresh Token. The reason for that is the sensitivity of this piece of information. You can think of it as user credentials, since a Refresh Token allows a user to remain authenticated essentially forever. Therefore you cannot have this information in a browser, it must be stored securely.
Simon_Weaver

1

Prenons un système où chaque utilisateur est lié à un ou plusieurs rôles et chaque rôle est lié à un ou plusieurs privilèges d'accès. Ces informations peuvent être mises en cache pour de meilleures performances API. Mais alors, il peut y avoir des changements dans les configurations d'utilisateur et de rôle (par exemple, un nouvel accès peut être accordé ou l'accès actuel peut être révoqué) et ceux-ci doivent être reflétés dans le cache.

Nous pouvons utiliser des jetons d'accès et d'actualisation à cette fin. Lorsqu'une API est invoquée avec un jeton d'accès, le serveur de ressources vérifie le cache pour les droits d'accès. S'il y a de nouvelles autorisations d'accès, cela ne se reflète pas immédiatement. Une fois le jeton d'accès expiré (disons dans 30 minutes) et le client utilise le jeton d'actualisation pour générer un nouveau jeton d'accès, le cache peut être mis à jour avec les informations de droit d'accès utilisateur mises à jour à partir de la base de données.

En d'autres termes, nous pouvons déplacer les opérations coûteuses de chaque appel d'API à l'aide de jetons d'accès vers l'événement de génération de jeton d'accès à l'aide d'un jeton d'actualisation.


0

Tout d'abord, le client s'authentifie auprès du serveur d'autorisation en accordant l'autorisation d'accord.

Ensuite, le client demande au serveur de ressources la ressource protégée en donnant le jeton d'accès.

Le serveur de ressources valide le jeton d'accès et fournit la ressource protégée.

Le client fait la demande de ressource protégée au serveur de ressources en accordant le jeton d'accès, où le serveur de ressources la valide et sert la demande, si elle est valide. Cette étape continue de se répéter jusqu'à l'expiration du jeton d'accès.

Si le jeton d'accès expire, le client s'authentifie auprès du serveur d'autorisation et demande un nouveau jeton d'accès en fournissant un jeton d'actualisation. Si le jeton d'accès n'est pas valide, le serveur de ressources renvoie la réponse d'erreur de jeton non valide au client.

Le client s'authentifie auprès du serveur d'autorisation en accordant le jeton d'actualisation.

Le serveur d'autorisation valide ensuite le jeton d'actualisation en authentifiant le client et émet un nouveau jeton d'accès, s'il est valide.


Cela ne mentionne pas en fait l'origine du jeton d'actualisation. Je suppose que le deuxième paragraphe devrait dire access token + refresh token?
Simon_Weaver
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.