Pourquoi OAuth v2 possède-t-il à la fois des Tokens D'accès et de rafraîchissement?
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 les deux? Pourquoi ne pas simplement faire durer le access_token aussi longtemps que le refresh_token et ne pas avoir un refresh_token ?
13 réponses
l'idée des tokens de rafraîchissement est que si un token d'accès est compromis, parce qu'il est de courte durée, l'attaquant a une fenêtre limitée dans laquelle l'abuser.
Les tokens de rafraîchissement, s'ils sont compromis, sont inutiles parce que l'attaquant a besoin de l'id du client et du secret en plus du token de rafraîchissement pour obtenir un token d'accès.
ayant dit que , parce que chaque appel à la fois le serveur d'autorisation et le le serveur de ressources est fait sur SSL-y compris l'id client d'origine et le secret quand ils demandent les tokens d'accès/rafraîchissement - Je ne suis pas sûr de savoir comment le token d'accès est plus "conciliable" que la longue durée de vie du token de rafraîchissement et de la combinaison clientid/secret.
ceci est bien sûr différent pour les implémentations où vous ne contrôlez pas à la fois les serveurs d'autorisation et de ressources.
voici un bon fil parlant des utilisations des tokens de rafraîchissement: Archives De OAuth .
une citation de ce qui précède, parlant des buts de sécurité du jeton de rafraîchissement:
Actualisation des jetons... atténue le risque d'une fuite d'access_token de longue durée (requête param dans un fichier journal sur un serveur de ressources non sécurisé, application de serveur de ressources bêta ou mal codée, client SDK JS sur un site non https qui met access_token dans un cookie, etc)
le lien à la discussion, fourni par Catchdave, a un autre point valide fait par Dick Hardt, qui je crois vaut la peine d'être mentionné ici en plus de ce qui a été écrit ci-dessus:
mes souvenirs de jetons de rafraîchissement étaient 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 nouveau les 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.Cela simplifie la validation des tokens 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 des ils sont (habituellement) également sécurisés, il n'y a pas beaucoup de sens à garder le jeton refresh séparé du jeton d'accès.
bien que, comme mentionné dans la citation, un autre rôle des tokens de rafraîchissement est de s'assurer que le token d'accès peut être révoqué à tout moment par l'utilisateur (via l'interface web dans leurs profils, par exemple) tout en maintenant le système évolutif en même temps.
généralement, les jetons peuvent être soit des identificateurs aléatoires pointant vers l'enregistrement spécifique la base de données du serveur, ou ils peuvent contenir toutes les informations en eux-mêmes (certainement, cette information doit être signée, avec MAC , par exemple).
Comment le système avec la longue durée de vie des jetons d'accès doit travailler
le serveur permet au Client d'accéder aux données de l'utilisateur dans un ensemble prédéfini de portées en émettant un token. Comme nous voulons garder le token révocable, nous devons stocker dans la base de données token avec le drapeau "révoqué" étant mis ou désactivé (sinon, comment feriez-vous avec un token autonome?) La base de données peut contenir jusqu'à len(users) x len(registered clients) x len(scopes combination) . Chaque requête API doit alors s'appuyer sur la base de données. Bien qu'il soit assez trivial de faire des requêtes à une telle base de données exécutant O(1), le seul point de défaillance lui-même peut avoir un impact négatif sur l'évolutivité et la performance du système.
Comment le système avec la longue durée d'actualisation de jeton et le jeton d'accès de courte durée devrait fonctionner
nous émettons ici deux clés: un jeton de rafraîchissement 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 Date d'expiration.
comme le token d'accès est autonome, nous n'avons pas à accéder à 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 tokens de rafraîchissement, mais le nombre de requêtes à cette base de données est généralement défini par la durée de vie du token 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 D'un Client d'un utilisateur particulier, nous devrions marquer le token de rafraîchissement correspondant comme" révoqué " (ou le supprimer complètement) et cesser d'émettre de nouveaux tokens d'accès. Il est évident cependant qu'il y a une fenêtre au cours de laquelle le jeton d'actualisation a été révoqué, mais son jeton d'accès peut être encore valide.
Compromis
Les tokens de rafraîchissementéliminent partiellement le SPoF (Single Point of Failure) de la base de données des tokens D'accès, mais ils présentent des inconvénients évidents.
-
la " fenêtre". Un délai entre les événements de l'utilisateur "révoque l'accès" et "l'accès est garanti d'être révoqué".
-
la complexité de La logique Client.
sans jeton de rafraîchissement
- envoyer la demande d'API avec jeton d'accès
- si le token d'accès est invalide, fail et demander à l'utilisateur de se réauthentifier""
avec "1519100920 d'actualisation" jeton
- envoyer la demande API avec le jeton d'accès
- si le token d'accès n'est pas valide, essayez de le mettre à jour en utilisant le token de rafraîchissement
- si la requête refresh passe, mettez à jour le token d'accès et ré-envoyez la requête API initiale
- si la requête de rafraîchissement échoue, demander à 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 noter également que certains bien connus OAuth2 les fournisseurs, y compris GitHub et foursquare adoptent le protocole sans rafraîchir les tokens, et semblent satisfaits de cela.
en dépit de toutes les grandes réponses ci-dessus, moi en tant qu'étudiant en sécurité maître et programmeur qui a déjà travaillé à eBay lorsque j'ai examiné la protection de l'acheteur et la fraude, peut dire de séparer token d'accès et rafraîchir token a son meilleur équilibre entre l'utilisateur harcelant de fréquent nom d'utilisateur/mot de passe d'entrée et de garder l'autorité en 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 actualiser jeton beaucoup plus longue comme un jour.
-
l'utilisateur est un bon utilisateur, il est à la maison et obtient sur/hors de votre magasinage site web et la recherche sur son iPhone. Son adresse IP ne change pas et a une charge très faible sur votre serveur. Comme 3-5 pages demandent chaque minute. Quand ses 3600 secondes sur le jeton d'accès est de plus, il nécessite une nouvelle avec le jeton d'actualisation. Nous, du côté du serveur, vérifions son historique d'activité et son adresse IP, pensons qu'il est humain et se comporte lui-même. Nous lui accorder un nouveau jeton d'accès pour continuer à utiliser notre service. L'utilisateur n'aura pas besoin d'entrer à nouveau le nom d'utilisateur/mot de passe jusqu'à ce qu'il ait atteint la durée de vie d'un jour du jeton de rafraîchissement lui-même.
-
l'utilisateur est un utilisateur négligent . Il vit à New York, USA a été piraté par un hacker dans Poland . Lorsque le hacker a obtenu le token d'accès et le token de rafraîchissement, il essaie de se faire passer pour l'utilisateur et d'utiliser notre service. Mais après que le jeton d'accès en direct court expire, quand le hacker essaye de rafraîchir le jeton d'accès, nous, sur le serveur, avons remarqué un changement d'IP spectaculaire dans l'histoire du comportement de l'utilisateur (hey, ce gars se connecte aux USA et maintenant rafraîchir l'accès en Pologne après seulement 3600 ???). Nous mettons fin à la rafraîchir le processus, invalider le jeton de rafraîchissement lui-même et demander à entrer le nom d'utilisateur/mot de passe à nouveau.
-
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 essaye de rafraîchir le token d'accès, nous avons remarqué son comportement et pensons qu'il pourrait ne pas être un humain. Nous rejetons et mettons fin au processus de rafraîchissement et demandez-lui d'entrer à nouveau son nom d'utilisateur et son mot de passe. Cela pourrait potentiellement briser le flux automatique de son robot. Au moins lui fait mal à l'aise.
vous pouvez voir que le jeton de rafraîchissement a fonctionné parfaitement 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 de token volé/abus de service en mettant en œuvre sur chaque appel api le chien de veille IP de base ou toute autre mesure. Mais cela coûte cher car vous devez lire et écrire un document sur l'utilisateur et ralentira la réponse de votre serveur.
ni l'une ni l'autre de ces réponses n'arrive au noyau raison refresh tokens existent. Évidemment, vous pouvez toujours obtenir une nouvelle paire accès-token/rafraîchir-token en envoyant vos informations d'identification de client au serveur auth - c'est comme ça que vous les obtenez en premier lieu.
ainsi, le seul but du jeton de rafraîchissement est de limiter l'utilisation des justificatifs d'identité des clients envoyés par le biais du service auth. Plus la ttl du jeton d'accès est courte, plus les justificatifs d'identité du client seront doivent être utilisés pour obtenir un nouveau jeton d'accès, et donc plus les attaquants d'opportunités doivent compromettre les justificatifs d'identité du client (bien que cela puisse être super difficile de toute façon si le chiffrement asymétrique est utilisé pour les envoyer). Ainsi, si vous avez un jeton de rafraîchissement à usage unique, vous pouvez rendre le ttl des tokens d'accès arbitrairement petit sans compromettre les justificatifs d'identité du client.
cette réponse est de Justin Richer via la liste d'e-mails de OAuth 2. C'est publié avec son autorisation.
la durée de vie d'un token de rafraîchissement dépend du (AS) serveur d'autorisation - ils peuvent expirer, être révoqués, etc. La différence entre un jeton d'actualisation et un jeton d'accès est le public: l'actualisation token remonte vers le serveur d'autorisation, le jeton d'accès va à la (RS) serveur de ressources.
Aussi, juste obtenir un jeton d'accès ne signifie pas que l'utilisateur est connecté. En fait, l'utilisateur peut même pas être là, ce qui est effectivement le cas d'utilisation de l'actualisation de jeton. Rafraîchir le token d'accès vous donnera accès à une API au nom de l'utilisateur, il ne vous dira pas si l'utilisateur est là.
OpenID Connect ne vous donne pas seulement des informations utilisateur à partir d'un token d'accès, il vous donne aussi un token D'identification. C'est une feuille de données il s'adresse au client lui-même, et non à L'AS ou à la RS. Dans L'OIDC, vous ne devriez considérer quelqu'un comme "connecté" par le protocole que si vous pouvez obtenir un nouveau jeton D'identification. Le rafraîchissement ne sera probablement pas suffisant.
pour plus d'information Lire http://oauth.net/articles/authentication /
pour clarifier une certaine confusion , vous devez comprendre les rôles du secret client et le mot de passe utilisateur , qui sont très différents.
Le client est une application/site web/programme/..., soutenu par un serveur, qui veut authentifier a utilisateur en utilisant un service d'authentification tiers. Le secret du client est (random) chaîne de caractères qui est connue à la fois de ce client et du serveur d'authentification. En utilisant ce secret, le client peut s'identifier avec le serveur d'authentification, recevant autorisation pour demander des tokens d'accès.
pour obtenir le token d'accès initial et le token de rafraîchissement, ce qui est requis est:
- l'ID de L'utilisateur
- le mot de passe de l'utilisateur
- l'identification du client
- le secret du client
pour obtenir un token d'accès rafraîchi mais le" client utilise les informations suivantes:
- client ID
- le secret du client
- le jeton de rafraîchissement
cela montre clairement la différence: lors du rafraîchissement, le client reçoit l'autorisation de rafraîchir les jetons d'accès en utilisant ses client secret, et peut ainsi ré-authentifier l'utilisateur en utilisant le jeton de rafraîchissement à la place de L'ID utilisateur + mot de passe. Cela évite effectivement à l'utilisateur d'avoir à entrer à nouveau son mot de passe.
cela montre aussi que la perte d'un jeton de rafraîchissement n'est pas un problème car l'identification du client et le secret ne sont pas connus. Il montre également que garder L'identité du client et le secret client est vital .
les Clients peuvent être compromis de plusieurs façons. Par exemple, un téléphone cellulaire peut être cloné. L'expiration d'un jeton d'accès signifie que le client est forcé de se réauthentifier au serveur d'autorisation. Pendant la réauthentification, le serveur d'autorisation peut vérifier d'autres caractéristiques (IOW effectue la gestion adaptative des accès).
Les tokens de rafraîchissementne permettent qu'une réauthentification du client, où la réautorisation force un dialogue avec l'utilisateur que beaucoup ont indiqué ils préfèrent ne pas le faire.
les jetons de rafraîchissement s'inscrivent essentiellement au même endroit où les sites Web normaux pourraient choisir de ré-authentifier périodiquement les utilisateurs après une heure ou plus (par exemple un site bancaire). Il n'est pas très utilisé à l'heure actuelle puisque la plupart des sites Web sociaux ne ré-authentifient pas les utilisateurs du web, alors pourquoi ré-authentifier un client?
pour simplifier davantage la réponse de B T: utilisez des tokens de rafraîchissement quand vous ne voulez pas typiquement que l'utilisateur ait à nouveau à taper des informations d'identification, mais voulez toujours que le pouvoir soit en mesure de révoquer les permissions (en révoquant le token de rafraîchissement)
vous ne pouvez pas révoquer un token d'accès, seulement un token de rafraîchissement.
pourquoi ne pas faire durer l'access_token aussi longtemps que le refresh_token et ne pas avoir un refresh_token?
en plus des grandes réponses que d'autres personnes ont fournies, il y a une autre raison pour laquelle on utiliserait des jetons de rafraîchissement et its pour faire des revendications.
chaque token contient des revendications qui peuvent inclure n'importe quoi du nom d'utilisateur, leurs rôles ou le fournisseur qui a créé la revendication. Un jeton est réactualisé ces les réclamations sont à jour.
si nous rafraîchissons les jetons plus souvent, nous mettons évidemment plus de pression sur nos services d'identité, mais nous obtenons des déclarations plus exactes et à jour.
tout d'abord, le client s'authentifie avec le serveur d'autorisation en donnant la subvention d'autorisation.
ensuite, le client demande le serveur de ressources pour la ressource protégée en donnant le jeton d'accès.
le serveur ressource 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 ressource en accordant l'accès token, où le serveur de ressources le valide et sert la requête, si elle est valide. Cette étape continue de se répéter jusqu'à ce que le jeton d'accès expire.
si le jeton d'accès expire, le client s'authentifie avec le serveur d'autorisation et demande un nouveau jeton d'accès en fournissant un jeton de rafraîchissement. Si le token d'accès n'est pas valide, le serveur ressource renvoie au client la réponse d'erreur du token invalide.
le client s'authentifie auprès du serveur d'autorisation en accordant le token de rafraîchissement.
le serveur d'autorisation valide alors le token de rafraîchissement en authentifiant le client et émet un nouveau token d'accès, s'il est valide.
supposons que vous faites durer l'access_token très longtemps, et ne pas avoir refresh_token, donc en un jour, hacker obtenir ce access_token et il peut accéder à toutes les ressources protégées!
mais si vous avez refresh_token, le temps de live de access_token est court, donc le hacker est difficile de hacker votre access_token parce qu'il sera invalide après une courte période de temps. Access_token ne peut être récupéré qu'en utilisant non seulement refresh_token mais aussi client_id et client_secret, qui hacker ne pas avoir.
considérons un système où chaque utilisateur est lié à un ou plusieurs rôles et chaque rôle est associé à un ou plusieurs des privilèges d'accès. Ces informations peuvent être mises en cache pour une meilleure performance de L'API. Mais ensuite, il peut y avoir des changements dans la configuration de l'utilisateur et du rôle (par exemple, un nouvel accès peut être accordé ou l'accès actuel peut être révoqué) et ceux-ci devraient être reflétés dans le cache.
nous pouvons utiliser des tokens d'accès et de rafraîchissement à cette fin. Lorsqu'une API est invoquée avec jeton d'accès, le serveur de ressources vérifie le cache pour les droits d'accès. S'il y a de nouvelles subventions d'accès, elles ne sont pas reflétées immédiatement. Une fois que le jeton d'accès expire (disons dans 30 minutes) et que le client utilise le jeton de rafraîchissement pour générer un nouveau jeton d'accès, le cache peut être mis à jour avec les informations mises à jour sur le droit d'accès de l'utilisateur à partir de la base de données.
en d'autres termes, nous pouvons déplacer les opérations coûteuses de chaque appel API en utilisant des tokens d'accès à l'événement de token d'accès génération utilisant le jeton de rafraîchissement.
alors que le token de rafraîchissement est conservé par le serveur D'autorisation. Les tokens d'accès sont autonomes de sorte que le serveur de ressources peut les vérifier sans les stocker, ce qui économise 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 peut utiliser un token de rafraîchissement rotation dans laquelle un nouveau jeton de rafraîchissement est émis avec chaque accès jeton d'actualisation de réponse.La précédente actualiser jeton est invalidé, mais retenu par le serveur d'autorisation. Si un jeton de rafraîchissement est compromise et par la suite utilisé par l'attaquant et le client légitime, l'un d'eux présentera un rafraîchissement invalidé jeton, qui en informe le serveur d'autorisation de la violation."
je pense que le but de l'utilisation de refresh token est que même si l'attaquant parvient d'une manière ou d'une autre à obtenir refresh token, l'ID du client et la combinaison secrète. Avec la suite les appels pour obtenir un nouveau token d'accès de la part de l'attaquant peuvent être suivis au cas où chaque demande de rafraîchissement aboutirait à un nouveau token d'accès et à un token de rafraîchissement.