Pourquoi OAuth v2 ont tous deux accès et actualiser les jetons ?

Question

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:

http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-4.2

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

Answer 1

Le lien vers la discussion, fournis par Catchdave, a un autre point de Dick Hardt, qui, je crois, mérite d'être mentionné ici, en plus de ce qui a été écrit ci-dessus:

Mon souvenir de l'actualisation des jetons é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 la non-délivrance 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.Cela simplifie l'accès jeton de validation et le rend plus facile à l'échelle et prendre en charge 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ù 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 devrait fonctionner

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) des dossiers. 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 devrait fonctionner

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 d'horodatage.

Comme 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).

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 qu'il y a une fenêtre, lorsque l'accès est déjà révoqué, mais certains jetons d'accès peut encore avoir accès aux données de l'utilisateur.

Compromis

Actualisation des jetons d'éliminer en partie les SPoF de Jeton d'Accès de base de données, mais ils ont quelques inconvénients évidents.

1. 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é".

2. La complexité de la logique Client.

   sans jeton d'actualisation

   • envoyer la demande d'API avec jeton d'accès
   • si le jeton d'accès n'est pas valide, ne parviennent pas, et demander à l'utilisateur de s'authentifier à nouveau

   avec jeton d'actualisation

   • envoyer la demande d'API avec jeton d'accès
   • Si le jeton d'accès n'est pas valide, essayez de mettre à jour à l'aide jeton d'actualisation
   • si l'actualisation de la demande de passe, mise à jour le jeton d'accès et l'envoyer à nouveau la première demande d'API
   • Si l'actualisation de la requête échoue, demander à l'utilisateur de s'authentifier à nouveau

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.

Answer 2

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.

Aprè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.

Voici un bon fil de parler au sujet de l'utilisation de l'actualisation des jetons: OAuth Archives.

Une citation de la ci-dessus, de parler de la sécurité fins de l'actualisation du jeton:

Actualisation des jetons... atténue le risque d'une longue durée de vie access_token fuite (requête de paramètre dans un fichier journal sur une base solide de ressources de serveur, bêta ou mal codé de ressources de serveur d'application, JS SDK client sur un autre site en https, qui met l'access_token dans un cookie, etc)

Answer 3

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, 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.

Answer 4

Les Clients peuvent être compromis 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?