Pourquoi Ne OAuth v2 Ont à la Fois l'Accès et l'Actualisation des Jetons?
La Section 4.2 du projet de protocole OAuth 2.0 protocole indique qu'un serveur d'autorisation peut renvoyer à la fois un access_token (qui est utilisé pour authentifier soi-même avec des ressources) ainsi que d'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 la access_token durer aussi longtemps que la refresh_token et ne pas avoir un refresh_token?
Vous devez vous connecter pour publier un commentaire.
L'idée de l'actualisation des jetons, c'est que si un jeton d'accès est compromis, car il est de courte durée, l'attaquant dispose d'un temps limité pour en abuser.
Actualisation des jetons, si compromise, sont inutiles parce que l'attaquant doit avoir l'id du client et le secret en outre à l'actualisation de jeton afin d'obtenir un jeton d'accès.
Avoir dit que, parce que chaque appel à la fois à l'autorisation du serveur et le serveur de ressources se fait sur SSL - y compris l'original d'identification du client et secret lorsqu'ils demandent l'accès/actualiser les jetons - je ne sais pas comment le jeton d'accès est plus "compromisable" que la longue durée de vie de rafraîchissement jeton et clientid/combinaison secrète.
Bien sûr, cela est différent pour les implémentations où vous n'avez pas le contrôle de la demande d'autorisation et de ressources serveurs.
Ici est un bon fil de parler au sujet de l'utilisation de l'actualisation des jetons: OAuth Archives.
Un devis à partir de ci-dessus, de parler de la sécurité fins de l'actualisation du jeton:
Le lien de la discussion, fournis par Catchdave, a un autre valide du point de (original, lien mort) de Dick Hardt, qui, je crois, mérite d'être mentionné ici, en plus de ce qui a été écrit ci-dessus:
En effet, dans la situation où les Ressources Serveur et le Serveur d'Autorisation de la même entité, et où la connexion entre l'utilisateur et l'un d'eux est (généralement) au même niveau de sécurité, il n'y a pas beaucoup de sens de garder le jeton d'actualisation séparé du jeton d'accès.
Bien que, comme mentionné dans le devis, un autre rôle de l'actualisation des jetons 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 conservant un système évolutif dans le même temps.
Généralement, les jetons peuvent être aléatoires identificateurs pointant vers le dossier dans le Serveur de base de données, ou ils peuvent contenir toutes les informations en elles-mêmes (certes, cette information doit être signé, avec MAC, par exemple).
Comment le système avec la longue durée de vie des jetons d'accès devraient travailler
Le serveur permet au Client d'obtenir l'accès aux données de l'Utilisateur à l'intérieur d'un ensemble pré-défini des étendues par l'émission d'un jeton. Comme nous voulons garder le jeton révocable, il faut stocker dans la base de données le jeton avec le drapeau "révoqué" ou unset (sinon, comment voulez-vous faire avec l'auto-contenue jeton?) Base de données peut contenir autant que
len(users) x len(registered clients) x len(scopes combination)enregistrements. Chaque demande d'API doit alors frapper la base de données. Bien qu'il est assez trivial de faire des requêtes de base de données tels que l'exécution 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.Comment le système avec la longue durée de vie jeton d'actualisation et de courte durée jeton d'accès devraient travailler
Ici, nous émettons deux clés: aléatoire actualiser jeton avec l'enregistrement correspondant dans la base de données, et signé autonome jeton d'accès, contenant entre autres l'expiration champ timestamp.
Que le jeton d'accès est indépendant, nous n'avons pas de frapper 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 avons encore de garder la base de données de l'actualisation des jetons, mais le nombre de demandes à 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, moins le taux d'accès à l').
Afin de révoquer l'accès d'un Client à partir d'un Utilisateur en particulier, nous devons marquer la mise à jour jeton comme "révoqué" (ou l'enlever complètement) et d'arrêter l'émission de nouveaux jetons 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
Actualisation des jetons partiellement éliminer les SPoF (Single Point of Failure) de Jeton d'Accès de base de données, mais ils ont quelques 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 complication de la logique Client.
sans actualiser jeton
avec actualiser jeton
J'espère que cette réponse ne fait sens et contribue à quelqu'un de faire plus de décision réfléchie. Je tiens à noter également que certains bien connus OAuth2 fournisseurs, y compris github et foursquare adopter le protocole sans actualisation des jetons, et semblent heureux.
En dépit de toutes les grandes réponses ci-dessus, j'en matière de sécurité, étudiante à la maîtrise et programmeur qui a déjà travaillé sur eBay quand j'ai pris un coup d'oeil dans la protection de l'acheteur et de la fraude, peut dire le jeton d'accès et d'actualisation de jeton a son meilleur équilibre entre les harcelant de l'utilisateur de fréquentes nom d'utilisateur/mot de passe d'entrée et de maintien de l'autorité dans la main de révoquer l'accès potentiel abus de votre service.
Penser à un tel scénario. 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 bonne de l'utilisateur, il est à la maison et se trouve sur/hors tension de votre site web shopping et la recherche sur son iPhone. Son adresse IP ne changera pas et ont une très faible charge sur votre serveur. Comme 3-5 demandes de page de chaque minute. Lors de son 3600 secondes sur le jeton d'accès est plus, il a besoin d'une nouvelle avec le jeton d'actualisation. Nous, sur le côté serveur, vérifier son historique d'activité et d'adresse IP, pense qu'il est un homme et qu'il 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 un jour la durée de vie de l'actualisation jeton de lui-même.
L'utilisateur est un négligent de l'utilisateur. Il vit dans New York, états-unis et a obtenu son programme de virus à l'arrêt et a été piraté par un hacker de Pologne. Lorsque le pirate a obtenu le jeton d'accès et d'actualisation de jeton, il essaie d'usurper l'identité de l'utilisateur et de l'utilisation de notre service. Mais après le court-live jeton d'accès de l'expiration, lorsque le pirate tente d'actualiser le jeton d'accès, nous, sur le serveur, a remarqué un dramatique IP du changement de comportement de l'utilisateur de l'histoire (hey, ce gars connexions aux etats-unis et maintenant l'actualisation de l'accès à la Pologne après seulement 3600s ???). Nous résilier le processus d'actualisation, la nullité de l'actualisation jeton de lui-même et l'invite à entrer le nom d'utilisateur/mot de passe de nouveau.
L'utilisateur est un malveillants de l'utilisateur. 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 d'actualiser le jeton d'accès, nous avons remarqué son comportement et de penser qu'il pourrait ne pas être un être humain. Nous rejetons et de mettre fin au processus d'actualisation et de lui demander d'entrer le nom d'utilisateur/mot de passe de nouveau. Cela pourrait potentiellement briser son robot automatique de l'écoulement. Au moins lui fait mal à l'aise.
Vous pouvez voir le jeton d'actualisation a agi parfaitement quand nous essayons de concilier nos travaux, l'expérience utilisateur et du risque potentiel d'un vol de jeton. Votre chien de garde sur le côté serveur peut vérifier plus de changement IP, la fréquence des appels de l'api pour déterminer si l'utilisateur doit être un bon utilisateur ou non.
Un autre mot, vous pouvez également essayer de limiter les dégâts de contrôle de vol de jeton/abus de service par la mise en œuvre sur chaque appel d'api l'IP de base de chien de garde ou de toute autre mesure. Mais c'est cher que vous avez à lire et à écrire, l'enregistrement sur l'utilisateur et va ralentir votre réponse du serveur.
Aucune de ces réponses rendre à la raison essentielle de l'actualisation des jetons existent. Évidemment, vous pouvez toujours obtenir un nouvel accès à jeton d'actualisation/-jeton paire en envoyant vos informations d'identification du client pour l'authentification du serveur, c'est comment vous les procurer dans la première place.
De sorte que le seul but de l'actualiser jeton est de limiter l'utilisation des informations d'identification du client d'être envoyés sur le fil pour le service de demenagement. La durée plus courte de la durée de vie de l'accès à jeton, le plus souvent, les informations d'identification du client devra être utilisé pour obtenir un nouvel accès à jeton, et donc les possibilités de plus les attaquants ont compromis les informations d'identification du client (bien que cela puisse être super difficile de toute façon si le chiffrement asymétrique est utilisé pour les envoyer). Donc, si vous avez un usage unique de l'actualisation de jeton, vous pouvez faire le ttl de l'accès jetons arbitrairement petite, sans compromettre les informations d'identification du client.
À clarifier la confusion, vous devez comprendre les rôles de la secrets du client et la mot de passe utilisateur, qui sont très différents.
La client est une application/site web/programme/..., soutenu par un serveur, qui veut authentifier un utilisateur à l'aide d'un tiers de service d'authentification. La clé secrète client est un (aléatoire) de la chaîne qui est connu à la fois le client et le serveur d'authentification. L'utilisation de ce secret, le client peut s'identifier avec le serveur d'authentification, de recevoir autorisation pour demander des jetons d'accès.
Pour obtenir la première jeton d'accès et d'actualisation de jeton, ce qui est requis est:
Pour obtenir une actualisation jeton d'accès cependant la client utilise les informations suivantes:
Ce qui montre clairement la différence: lors de l'actualisation, le client reçoit l'autorisation de l'actualisation des jetons d'accès à l'aide de sa clé secrète client, et peut donc se ré-authentifier l'utilisateur à l'aide de l'actualisation jeton au lieu de l'ID d'utilisateur + mot de passe. Cela empêche l'utilisateur d'avoir à re-saisir son mot de passe.
Cela montre aussi que la perte d'un jeton d'actualisation n'est pas un problème parce que l'ID du client et le secret sont pas connus. Il montre également que le maintien de l'ID du client et le client secret est vital.
Cette réponse est de Justin plus Riches via OAuth 2 standard corps de liste d'email. C'est publié avec son autorisation.
La durée de vie d'un jeton d'actualisation est à l' (COMME) le serveur d'autorisation — ils peuvent expirer, être révoquée, 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. L'actualisation de l'jeton d'accès, vous donnera accès à une API sur le compte de l'utilisateur, il ne sera pas vous dire si l'utilisateur n'.
OpenID Connect n'est pas seulement vous donner des informations de l'utilisateur à partir d'un jeton d'accès, il vous donne également un ID de jeton. C'est une feuille de données qui sont adressées au client lui-même, de ne pas le ou la RS. Dans OIDC, vous ne devriez penser à quelqu'un en fait “connecté” par le protocole si vous pouvez obtenir une nouvelle ID de jeton. Rafraîchissant, il n'est pas probable que ce soit suffisant.
Pour plus d'informations, veuillez lire http://oauth.net/articles/authentication/
Clients peut être compromise dans de nombreuses façons. Par exemple, un téléphone cellulaire peut être cloné. Avoir un jeton d'accès expire signifie que le client est obligé de se ré-authentifier sur le serveur d'autorisation. Au cours de la ré-authentification, le serveur d'autorisation pouvez consulter d'autres caractéristiques (OIE effectuer adaptatif de gestion de l'accès).
Actualisation des jetons de permettre à un client de ré-authentification, où en tant que ré-autoriser les forces d'un dialogue avec l'utilisateur que beaucoup ont indiqué qu'ils préfèrent ne pas le faire.
Actualisation des jetons ajustement pour l'essentiel, à l'endroit même où normales de sites web peut choisir d'périodiquement ré-authentifier les utilisateurs, après une heure ou deux (par ex. services bancaires). Il n'est pas très utilisé à l'heure actuelle puisque la plupart des sites web de réseaux sociaux de ne pas se ré-authentifier les utilisateurs sur le web, alors pourquoi ils se ré-authentifier un client?
Pour simplifier B T réponse: l'Utilisation d'actualisation des jetons lorsque vous ne souhaitez généralement à l'utilisateur d'avoir à saisir à nouveau les informations d'identification, mais qui veulent le pouvoir pour être en mesure de révoquer les autorisations (par la révocation de l'actualisation de jeton)
Vous ne peut pas révoquer un jeton d'accès, seulement un jeton d'actualisation.
En plus grande des réponses d'autres personnes ont fourni il y a une autre raison pourquoi l'utilisation d'actualisation des jetons et de sa à voir avec les revendications.
Chaque jeton contient des revendications qui peuvent inclure le nom des utilisateurs, de leurs rôles ou le fournisseur qui a créé la demande. Un jeton est réactualisé ces revendications sont mises à jour.
Si nous rafraîchir les jetons plus souvent, nous sommes évidemment à mettre plus de pression sur nos services d'identité toutefois nous deviennent plus précises et à jour de réclamations.
Supposons que vous faites l'access_token durer très longtemps, et n'ont 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, l'access_token de la durée de vie est courte, de sorte que le hacker est dur à pirater votre access_token, car il sera invalide après une courte période de temps.
Access_token qui ne peuvent être récupérées en utilisant non seulement refresh_token mais aussi par client_id et client_secret, qui hacker n'a pas.
Tandis que l'actualisation jeton est conservé par le serveur d'Autorisation. Jeton d'accès sont autonomes, afin que les ressources du serveur pouvez le vérifier sans le stocker ce qui permet à l'effort de récupération en cas de validation.
Un autre point manquant en discussion, c'est à partir de rfc6749#page-55
Je pense que le point de l'ensemble de l'aide jeton d'actualisation, c'est que même si l'attaquant réussit à obtenir d'actualisation jeton d'identification du client et combinaison secrète. Avec les appels suivants pour obtenir le nouveau jeton d'accès de l'attaquant peuvent être suivies dans le cas où si chaque demande d'actualiser le résultat dans une nouvelle jeton d'accès et d'actualisation de jeton.
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.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. Cette information peut être mis en cache pour une meilleure API performance. Mais ensuite, il peut y avoir des changements de l'utilisateur et le rôle des configurations (par exemple, de nouveaux accès peut être accordé ou d'accès actuel peut être révoquée) et ceux-ci devraient être reflétées dans le cache.
Nous pouvons utiliser l'accès et l'actualisation des jetons pour un tel but. Lorsque l'API est appelée avec un jeton d'accès, le serveur de ressources vérifie le cache pour les droits d'accès. SI il n'y a aucune nouvelle d'accès à des subventions, il n'est pas pris en compte immédiatement. Une fois le jeton d'accès de l'expiration (par exemple en 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 la mise à jour de l'utilisateur le droit d'accès de l'information à partir de la DB.
En d'autres termes, nous pouvons déplacer les opérations coûteuses de tous les appels de l'API à l'aide de jetons d'accès à l'événement de la génération jeton d'accès à l'aide jeton d'actualisation.
access token + refresh token?