Pourquoi est-ce OAuth v2 ont tous deux accès et Refresh Tokens?

StackOverflow https://stackoverflow.com/questions/3487991

Question

Section 4.2 du projet OAuth 2.0 protocole indique qu'un serveur d'autorisation peut retourner à 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 une nouvelle access_token:

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

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

Était-ce utile?

La solution

L'idée de jetons rafraîchissement est que si un jeton d'accès est compromise, car elle est de courte durée, l'attaquant a une fenêtre limité pour abuser.

Actualiser jetons, si compromis, sont inutiles parce que l'attaquant exige l'identifiant client et secret, en plus de l'actualisation du jeton afin d'obtenir un jeton d'accès.

Cela dit , parce que chaque appel à la fois le serveur d'autorisation et le serveur de ressources se fait via SSL - y compris l'identifiant client original et secret, lorsqu'ils demandent des jetons d'accès / rafraîchissement - Je ne suis pas sûr la façon dont le jeton d'accès est plus « compromisable » que le jeton de rafraîchissement longue durée de vie et combinaison clientid / secret.

est bien sûr différent implémentations où vous ne contrôlez pas les deux serveurs d'autorisation et de ressources.

Voici un bon fil parle d'utilisation de jetons: OAuth Archives .

Une citation de ce qui précède, parler des raisons de sécurité du jeton rafraîchissement:

  

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

Autres conseils

Le lien à la discussion, fourni par Catchdave, a une autre bon point (lien d'origine, mort) fait par Dick Hardt, que je crois vaut la peine d'être mentionné ici, en plus de ce qui a été écrit ci-dessus:

  

je me souviens de 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 par l'émission de nouveaux ne 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 le jeton de validation d'accès valid.This et facilite à l'échelle et de soutenir 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ù des ressources serveur et serveur d'autorisation est la même entité, et où la connexion entre l'utilisateur et l'un d'eux est (en général) assurer également, il n'y a pas beaucoup de sens pour garder rafraîchissement jeton séparé du jeton d'accès .

Bien que, comme mentionné dans la citation, un autre rôle de jetons rafraîchissement est d'assurer le jeton d'accès peut être révoquée à tout moment par l'utilisateur (via l'interface web dans leurs profils, par exemple) tout en gardant le système évolutive à en même temps.

En général, les jetons peuvent être soit des identifiants aléatoires pointant vers le dossier spécifique dans la base de données du serveur, ou ils peuvent contenir toutes les informations en elles-mêmes (sans doute, ces informations doivent être signés, avec MAC , par exemple).

Comment le système avec des jetons d'accès à long terme doit travailler

Le serveur permet au client d'avoir accès aux données de l'utilisateur dans un ensemble de champs prédéfinis par l'émission d'un jeton. Comme nous voulons garder l'révocable jeton, il faut stocker dans la base de données le jeton avec le drapeau « révoquées » être activé ou désactivé (sinon, comment voulez-vous faire avec autonome jeton?) Base de données peut contenir jusqu'à len(users) x len(registered clients) x len(scopes combination) dossiers. Chaque requête API doit alors frapper la base de données. Bien qu'il soit tout à fait banal pour faire des requêtes à cette base de données O exécutant (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.

Comment le système avec une longue durée de rafraîchissement jeton et jeton d'accès de courte durée devrait fonctionner

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

.

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

Néanmoins, nous avons encore de garder la base de données de jetons de rafraîchissement, mais le nombre de demandes à cette base de données est généralement définie par la durée de vie du jeton d'accès (plus la durée de vie, plus le taux d'accès).

Pour révoquer l'accès des clients à partir d'un utilisateur particulier, nous devrions marquer l'actualisation correspondante jeton « révoqué » (ou l'enlever complètement) et cesser d'émettre de nouveaux jetons d'accès. Il est évident qu'il ya bien une fenêtre au cours de laquelle le jeton rafraîchissement a été révoqué, mais son jeton d'accès peut être encore valide.

Compromis

Actualiser jetons éliminer partiellement le SPOF (Single Point of Failure) d'accès base de données Token, mais ils ont quelques inconvénients évidents.

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

  2. Le complication de la logique du client.

    sans jeton rafraîchissement

    • envoyer la demande de l'API avec jeton d'accès
    • si le jeton d'accès est invalide, échec et demander à l'utilisateur de réauthentifier

    jeton rafraîchissement

    • envoyer la demande de l'API avec jeton d'accès
    • Si le jeton d'accès est non valide, essayez de le mettre à jour à l'aide de rafraîchissement jeton
    • si la demande de rafraîchissement passe, mettez à jour le jeton d'accès et envoyer de nouveau la demande API initiale
    • Si la demande de rafraîchissement échoue, demander à l'utilisateur de réauthentifier

J'espère que cette réponse ne du sens et aide quelqu'un à prendre une décision plus réfléchie. Je voudrais également noter que certains fournisseurs OAuth2, y compris github et adopter foursquare bien connu protocole sans jetons de rafraîchissement et semblent heureux.

En dépit de toutes les grandes réponses ci-dessus, je en tant qu'étudiant maître de sécurité et programmeur qui a déjà travaillé à eBay quand je pris un coup d'oeil dans la protection de l'acheteur et la fraude, peut dire à jeton et jeton rafraîchissement accès séparé a son meilleur équilibre entre harceler l'utilisateur de fréquents nom d'utilisateur / mot de passe entré et maintenir l'autorité dans la main pour révoquer l'accès au potentiel abus de votre service.

Pensez à un scénario comme celui-ci. Vous émettez utilisateur d'un jeton d'accès de 3600 secondes et rafraîchissez jeton beaucoup plus comme un jour.

  1. L'utilisateur est un bon utilisateur, il est à la maison et se met à / votre site shopping et la recherche sur son iPhone. Son adresse IP ne change pas et ont une très faible charge sur votre serveur. Comme 3-5 pages demandes chaque minute. Lorsque ses 3600 secondes sur le jeton d'accès est terminée, il a besoin d'un nouveau avec le jeton de rafraîchissement. Nous, du côté du serveur, vérifier son historique d'activité et l'adresse IP, pense qu'il est un être humain et se comporte. Nous lui accorder un nouveau jeton d'accès pour continuer à utiliser notre service. L'utilisateur n'a pas besoin de saisir à nouveau le nom d'utilisateur / mot de passe jusqu'à ce qu'il ait atteint une jours durée de vie de rafraîchissement jeton lui-même.

  2. L'utilisateur est négligente utilisateur. Il vit à New York, Etats-Unis et a obtenu son arrêt du programme de virus et a été piraté par un pirate informatique Pologne . Lorsque le pirate a obtenu le jeton d'accès et de rafraîchissement jeton, il essaie d'usurper l'identité de l'utilisateur et utiliser notre service. Mais après l'accès à court en direct jeton arrive à expiration, lorsque les tentatives de piratage pour actualiser le jeton d'accès, nous, sur le serveur, a constaté un changement IP dramatique dans l'histoire du comportement des utilisateurs (hey, ce logins gars aux Etats-Unis et l'accès Rafraîchissez en Pologne après seulement 3600s ???). Nous terminons le processus d'actualisation, d'invalider l'actualisation jeton lui-même et invite à entrer le nom d'utilisateur / mot de passe.

  3. L'utilisateur est malveillant utilisateur. Il a pour but d'abuser de notre service en appelant 1000 fois notre API chaque minute à l'aide d'un robot. Il peut bien faire jusqu'à ce que 3600 secondes plus tard, quand il essaie de rafraîchir l'jeton d'accès, nous avons remarqué son comportement et pense qu'il pourrait ne pas être un être humain. Nous rejetons et mettre fin au processus de rafraîchissement et lui demander de saisir le nom d'utilisateur / mot de passe. Cela pourrait potentiellement briser flux automatique de son robot. Au moins le rend mal à l'aise.

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

Un autre mot est que vous pouvez également essayer de limiter le contrôle des dommages d'abus de / jeton volé du service en mettant en place sur chaque appel api le chien de garde IP de base ou toute autre mesure. Mais cela coûte cher que vous devez lire et enregistrer en écriture sur l'utilisateur et va ralentir votre réponse du serveur.

Aucune de ces réponses se rendre à la raison de base existent des jetons de rafraîchissement. De toute évidence, vous pouvez toujours obtenir une nouvelle paire accès jeton / rafraîchissement-jeton en envoyant vos informations d'identification du client au serveur auth -. Thats comment vous les obtenez en premier lieu

Ainsi, le seul but de l'actualisation jeton est de limiter l'utilisation des informations d'identification du client envoyé sur le fil au service auth. Plus la ttl du jeton d'accès, les plus souvent les informations d'identification du client devront être utilisées pour obtenir un nouvel accès symbolique, et donc plus de possibilités attaquants doivent compromettre les informations d'identification du client (bien que cela puisse être de toute façon super difficile si chiffrement asymétrique est utilisé pour les envoyer). Donc, si vous avez un rafraîchissement jeton à usage unique, vous pouvez faire le ttl accès tokens arbitrairement petit, sans compromettre les informations d'identification du client.

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

client est une application / site / programme / ..., soutenu par un serveur, qui veut Authentifier utilisateur par en utilisant un service d'authentification tiers. Le secret client est une chaîne (aléatoire) qui est connu à la fois ce client et le serveur d'authentification. En utilisant ce secret le client peut s'identifier avec le serveur d'authentification, réception autorisation aux jetons d'accès à la demande.

Pour obtenir le jeton et le jeton rafraîchissement accès initial, ce qui est requis est:

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

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

  • L'ID client
  • Le secret client
  • Le jeton rafraîchissement

Cela montre clairement la différence: lors de l'actualisation, le client reçoit l'autorisation de jetons d'accès rafraîchissement en utilisant son code secret du client, et peut ainsi ré-authentifier l'utilisateur en utilisant l'actualisation jeton au lieu de l'ID utilisateur + mot de passe. Cela empêche efficacement l'utilisateur d'avoir à entrer de nouveau son / son mot de passe.

Cette montre également que la perte d'un jeton de rafraîchissement est pas de problème car on ne connaît pas l'ID client et secret. Il a également montre que le maintien de l'ID client et secret secret client est vital .

Les clients peuvent être compromis à bien des égards. Par exemple on peut cloner un téléphone cellulaire. Avoir un jeton d'accès expire signifie que le client est obligé de réauthentifier au serveur d'autorisation. Au cours de la ré-authentification, le serveur d'autorisation peut vérifier d'autres caractéristiques (OIEau effectuer la gestion d'accès adaptatif).

jetons Rafraîchir permettent à un client ne ré-authentification, où les forces réautoriser un dialogue avec l'utilisateur dont beaucoup ont indiqué qu'ils préféreraient ne pas faire.

Actualiser les jetons en forme essentiellement au même endroit où les sites Web normaux peuvent choisir d'utilisateurs périodiquement réauthentifier après une heure (par exemple un site bancaire). Il n'est pas très utilisé à l'heure actuelle puisque la plupart des sites Web sociaux font les internautes non réauthentifier, alors pourquoi seraient-ils ré-authentifier un client?

Pour simplifier encore la réponse de BT: Utilisez refresh jetons lorsque vous ne voulez pas généralement l'utilisateur d'avoir à taper à nouveau dans les informations d'identification, mais veulent toujours le pouvoir d'être en mesure de révoquer les autorisations (en retirant le jeton d'actualisation)

Vous ne pouvez pas révoquer un jeton d'accès, seul un jeton rafraîchissement.

  

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

En plus de grandes réponses d'autres personnes ont fourni il y a une autre raison pour laquelle utiliserait des jetons et son rafraîchissement à faire des réclamations.

Chaque jeton contient des revendications qui peuvent comprendre quoi que ce soit à partir du nom des utilisateurs, leurs rôles ou le fournisseur qui a créé la demande. En signe est rafraîchie ces demandes sont mises à jour.

Si nous jetons les plus rafraîchir souvent, nous mettons évidemment plus de pression sur nos services d'identité mais nous obtenons plus précis et les revendications mises à jour.

Supposons que vous faites la access_token très longtemps, et ne pas refresh_token, donc en un jour, pirate obtenir ce access_token et il peut accéder à toutes les ressources protégées!

Mais si vous avez refresh_token, le temps en direct du access_token est courte, de sorte que le pirate est difficile de pirater votre access_token car il sera invalide après courte période de temps. Access_token ne peut être récupéré en arrière à l'aide non seulement refresh_token mais aussi par client_id et client_secret, qui ne pirate pas.

Alors que jeton rafraîchissement est conservé par le serveur d'autorisation. Jeton d'accès sont autonomes si serveur de ressources peut le vérifier sans l'enregistrer qui permet d'économiser l'effort de récupération en cas de validation. Un autre point manquant dans la discussion est de rfc6749 # page-55

  

"Par exemple, le serveur d'autorisation pourrait employer jeton rafraîchissement   rotation dans laquelle est émis un nouveau jeton de rafraîchissement avec tous les accès   jeton rafraîchissement réponse.Dispositif précédent jeton de rafraîchissement est invalidée mais   conservé par le serveur d'autorisation. Si un jeton de rafraîchissement est   compromise et ensuite utilisé à la fois par l'attaquant et le   client légitime, l'un d'entre eux présentera une actualisation invalidée   jeton, qui informera le serveur d'autorisation de la violation. "

Je pense que toute la question de l'aide du jeton rafraîchissement est que même si l'attaquant réussit à obtenir jeton rafraîchissement, ID client et la combinaison secrète. Avec les appels suivants pour obtenir un nouveau jeton d'accès de l'attaquant peut être suivi en cas si chaque demande de rafraîchissement résultat dans le nouveau jeton d'accès et le jeton rafraîchissement.

Cette réponse a été mis en place à l'aide de deux devs supérieurs (John Brayton et David Jennes).

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

Soit Supposons qu'il n'y a pas de clé de rafraîchissement et nous allons passer 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.

Si je suis le pirate et obtenir votre clé, puis à la fin des 30 minutes, je vais à la messagerie qui keymaker et obtenir une nouvelle clé. Je serai en mesure d'ouvrir en permanence toutes les portes quel que soit le changement clé.

Question: Au cours des 30 minutes, combien d'occasions hacking ai-je contre la clé? J'ai eu 80 occasions de hacking, chaque fois que vous avez utilisé la clé (pensez à ce que de faire une demande de réseau et en passant le jeton d'accès pour vous identifier). Alors que sa surface d'attaque 80X.

Maintenant, nous allons passer par le même exemple, mais cette fois-ci, supposons qu'il ya une touche 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. Si je suis le pirate et obtenir votre clé, je peux l'utiliser pendant 30 minutes, mais à la fin des 30 minutes de l'envoyer à l'keymaker n'a pas de valeur. Si je le fais, alors le keymaker serait juste dire cette clé est expirée. Pour pouvoir prolonger mon bidouille je dois pirater le courrier au keymaker. Le courrier a une clé distincte (penser à cela comme un jeton rafraîchissement).

Question: Au cours des 30 minutes, combien d'occasions hacking ai-je contre le courrier? 80? Non, je ne ai eu 1 occasion de piratage. Pendant le temps le courrier communique avec le keymaker. Alors que sa surface d'attaque 1X. J'ai eu 80 occasions de piratage contre la clé, mais ils ne sont pas bons au bout de 30 minutes.

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

Un jeton d'accès qui fuit est mauvaise, mais une fois qu'il expire, il n'est plus utile à un attaquant. est bien pire Une fuite de jeton rafraîchissement, mais on peut supposer qu'il est moins probable. (Je pense qu'il ya de la place à la question de savoir si la probabilité d'une fuite de jeton rafraîchissement est inférieure beaucoup plus que celle d'un jeton d'accès fuite, mais c'est l'idée.)

Le point est que le jeton d'accès est ajouté à chaque demande que vous faites, alors qu'un jeton de rafraîchissement est utilisé uniquement pendant l'écoulement de rafraîchissement Donc, moins de chance d'un MITM voir le jeton

Fréquence aide un attaquant. heartbleed -comme les failles de sécurité potentielles dans SSL, les failles de sécurité potentielles dans le client et les failles de sécurité potentielles dans le serveur tous faire une fuite possible.

En outre, si le serveur d'autorisation est distinct du serveur d'applications de traitement d'autres demandes de client alors que le serveur d'applications ne verra jamais jetons rafraîchissement. Il ne verra que des jetons d'accès qui ne vivrai pas beaucoup plus longtemps.

compartimentation est bon pour la sécurité.

Qu'est-ce rafraîchissement jeton est pas?

La capacité de mise à jour / niveau d'accès Révoquer par jetons rafraîchissement est un sous-produit de choisir d'utiliser des jetons de rafraîchissement, sinon un jeton d'accès autonome pourrait être révoqué ou avoir son niveau d'accès modifié quand il expire et les utilisateurs obtient un nouveau jeton »

Considérons 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 améliorer les performances de l'API. Mais alors, il peut y avoir des changements dans les configurations utilisateur et rôle (pour peut être accordée ou l'accès actuel peut être révoqué par exemple un accès nouveau) et ceux-ci devraient se refléter dans le cache.

Nous pouvons utiliser l'accès et actualisez jetons à cette fin. Lorsqu'une API est appelée avec jeton d'accès, le serveur vérifie des ressources du cache des droits d'accès. En cas de nouvelles subventions d'accès, il ne se reflète pas immédiatement. Une fois que l'jeton d'accès expire (disons en 30 minutes) et le client utilise l'actualisation jeton pour générer un nouveau jeton d'accès, le cache peut être mis à jour avec l'accès utilisateur mise à jour des informations depuis le DB.

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

  

Tout d'abord, les authentifie client avec le serveur d'autorisation en donnant l'octroi de l'autorisation.

     

Ensuite, le client demande au serveur de ressources pour 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 valide et sert la demande, si elle est valide. Cette étape ne cesse de répéter jusqu'à ce que l'jeton d'accès arrive à expiration.

     

Si le jeton d'accès expire, l'authentification du client avec le serveur d'autorisation et les demandes d'un nouveau jeton d'accès en fournissant jeton rafraîchissement. Si le jeton d'accès est non valide, le serveur de ressources renvoie la réponse d'erreur jeton invalide au client.

     

Les authentifie client avec le serveur d'autorisation en accordant le jeton rafraîchissement.

     

Le serveur d'autorisation valide alors l'actualisation du jeton par authentification du client et émet un nouveau jeton d'accès, si elle est valide.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top