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:
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.)
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.
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é».
La complication de la logique client.
sans jeton d'actualisation
avec jeton d'actualisation
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.
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.
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.
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.
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.
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.
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:
Cependant, pour obtenir un jeton d'accès actualisé, le client utilise les informations suivantes:
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 .
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/
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?
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.
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.
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
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.
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.
A 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.
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.
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.
access token + refresh token?