Quel est le but de la subvention implicite autorisation type dans OAuth 2 ?

Question

Je ne sais pas si j'ai juste une sorte de point aveugle ou quoi, mais j'ai lu le OAuth 2 spec de nombreuses reprises et lu les archives des listes de diffusion, et je n'ai pas encore trouvé une bonne explication de pourquoi la reconnaissance Implicite de l'écoulement pour l'obtention de jetons d'accès a été développé. Par rapport au Code d'Autorisation de la Subvention, il semble juste de donner de l'authentification du client pour pas très convaincante. Comment est-ce que "optimisé pour les clients mis en œuvre dans un navigateur à l'aide d'un langage de script" (pour citer la spécification)?

Les deux flux sont identiques au début (source: http://tools.ietf.org/html/draft-ietf-oauth-v2-22):

1. Le client initie le flux en dirigeant le propriétaire de la ressource de l'user-agent pour l'autorisation d'extrémité.
2. Le serveur d'autorisation authentifie le propriétaire de la ressource (via le user-agent) et établit que le propriétaire de la ressource accorde ou refuse l'accès du client demande.
3. En supposant que le propriétaire de la ressource donne accès, le serveur d'autorisation redirige l'utilisateur de l'agent vers le client en utilisant l'URI de redirection fournies précédemment (à la demande ou lors de l'inscription du client).
   • L'URI de redirection comprend un code d'autorisation (code d'Autorisation de flux)
   • L'URI de redirection comprend le jeton d'accès dans le fragment d'URI (Implicite débit)

C'est ici que le flux de split. Dans les deux cas, l'URI de redirection à ce point est à un point de terminaison, hébergées par le client:

• Dans le code d'Autorisation de flux, lorsque l'utilisateur de l'agent de hits que le point de terminaison avec le code d'Autorisation dans l'URI, le code à l'extrémité des échanges le code d'autorisation, ainsi que ses informations d'identification du client pour un jeton d'accès qu'il peut ensuite utiliser en tant que de besoin. Il pourrait, par exemple, écrire dans une page web un script sur la page accès.
• L'Implicite débit saute cette étape d'authentification du client tout à fait et juste des charges jusqu'à une page web avec un script client. Il y a un ptit truc ici avec le fragment d'URL qui garde le jeton d'accès d'être passé autour de trop, mais le résultat final est essentiellement le même: le client hébergé par le site propose une page avec un script qui peut saisir le jeton d'accès.
  

D'où ma question: ce qui a été acquis ici, en sautant l'étape d'authentification du client?

Answer 1

Voici mes réflexions: Le but de l'auth code + clé dans le code d'autorisation de flux, c'est que les jetons et les secrets du client ne seront jamais exposés à des ressources propriétaire car ils voyagent serveur-à-serveur. De l'autre côté, la reconnaissance implicite de l'écoulement est pour les clients qui ont mis en œuvre entièrement à l'aide de javascript et de l'exécution des ressources du propriétaire du navigateur. Vous n'avez pas besoin de tout côté serveur de code pour utiliser ce flux. Ensuite, si tout se passe dans les ressources du propriétaire du navigateur, il n'a pas de sens à la question "auth code" & client secret, car jeton & secrets du client sera toujours partagée avec le propriétaire de la ressource. Y compris auth code & secrets du client rend juste le débit le plus complexe sans ajouter plus de sécurité réelle.

Donc la réponse sur "ce qui a été acquis?" est "simplicité".

Answer 2

Vous devriez considérer la différence entre l' agent utilisateur et le client:

Le user-agent est le logiciel qui permet à l'utilisateur (la"ressource propriétaire") communique avec les autres composants du système (serveur d'authentification et le serveur de ressources).

Le client est le logiciel qui veut accéder aux ressources de l'utilisateur sur le serveur de ressources.

Dans le cas de découplée de l'agent utilisateur et client, le Code d'Autorisation de la Subvention de sens. E. g. l'utilisateur utilise un navigateur web (user-agent) pour vous connecter avec son Facebook compte sur Kickstarter. Dans ce cas, le client est l'une des Kickstarter serveurs, qui gère les connexions des utilisateurs. Ce serveur reçoit le jeton d'accès et l'actualisation de jeton à partir de Facebook. Ainsi, ce type de client considéré comme "sûr", à cause des restrictions d'accès, les jetons peuvent être enregistrées et Kickstarter peut accéder aux ressources et encore actualiser les jetons d'accès sans interaction de l'utilisateur.

Si le user-agent et le client sont couplés (par exemple, application mobile native, javascript de l'application), l' Implicite d'Autorisation de Flux de travail peuvent être appliquées. Il s'appuie sur la présence de la ressource propriétaire (pour entrer les informations d'identification) et ne prend pas en charge l'actualisation des jetons. Si ce client stocke le jeton d'accès pour les utiliser plus tard, ce sera un problème de sécurité, car le jeton peut être extraite facilement à d'autres applications/utilisateurs du client. L'absence de l'actualisation jeton est un indice supplémentaire, que cette méthode n'est pas conçu pour l'accès à l'utilisateur des ressources en l'absence de l'utilisateur.

Answer 3

L'explication habituelle est que la reconnaissance Implicite est plus facile à mettre en œuvre lorsque vous utilisez un client de JavaScript. Mais je pense que c'est la mauvaise façon de le regarder.

Le Code d'Autorisation de la subvention fournit une sécurité supplémentaire, mais il ne fonctionne que lorsque vous avez un serveur web. Depuis le serveur web enregistre le jeton d'accès, vous courez moins de risques de le jeton d'accès soient exposés à l'Internet, et vous pouvez émettre un jeton qui dure un temps long. Et depuis le serveur web est digne de confiance, il peut être donné une actualisation "jeton", de sorte qu'il peut en obtenir un nouveau jeton d'accès lors de l'expiration de l'ancien.

Mais -- et c'est un point qui est facile à manquer-cela ne fonctionne que si le serveur web est protégé par une session. Sans une session, un utilisateur non fiable peut juste faire des requêtes vers le serveur web, et ce serait le même que si l'utilisateur avait le jeton d'accès. L'ajout d'une séance signifie que seul le premier utilisateur peut accéder aux ressources protégées.

Cela signifie également que vous pouvez mettre fin à la session avant l'expiration de ce jeton OAuth. Il n'y a pas de méthode standard pour invalider un jeton d'accès. Mais si votre session expire, le jeton d'accès est inutile, car personne ne le sait, mais le serveur web. Si un utilisateur non fiable obtenu l'accès à votre clé de session, ils seront en mesure d'accéder aux ressources protégées aussi longtemps que la session est valide.

Si il n'y a pas de serveur web, vous devez utiliser la reconnaissance Implicite. Mais cela signifie que le jeton d'accès est exposée à l'Internet. Si un utilisateur non approuvé les gains d'accès, ils peuvent l'utiliser jusqu'à ce qu'il expire. Cela signifie qu'ils auront accès à plus long qu'avec un Code d'Autorisation de la subvention. Vous voudrez peut-être envisager de faire le jeton expireront plus tôt, et éviter de donner l'accès à plus de ressources sensibles.

Answer 4

Il se résume à: Si un utilisateur est en cours d'exécution basée sur un navigateur, ou "public", (JavaScript) web app avec aucun composant côté serveur, l'utilisateur implicitement les fiducies de l'application (et le navigateur dans lequel il s'exécute, potentiellement avec d'autres navigateur basé sur des applications...).

Il n'y a pas de 3ème partie serveur distant, seul le serveur de ressources. Il n'y a aucun avantage à un code d'autorisation, car il n'existe aucun autre agent en outre le navigateur agissant pour le compte de l'utilisateur. Il n'ya aucun avantage pour les informations d'identification du client pour la même raison. (Tout client peut tenter d'utiliser ce flux.)

Les implications en matière de sécurité, cependant, sont importants. À partir de http://tools.ietf.org/html/rfc6749#section-10.3:

Lors de l'utilisation de la reconnaissance implicite de type, le jeton d'accès est transmis dans le fragment d'URI, qui peut l'exposer à des tiers non autorisés.

À partir de http://tools.ietf.org/html/rfc6749#section-10.16:

Une ressource propriétaire peut volontiers déléguer l'accès à une ressource par l'octroi d'un jeton d'accès à un attaquant malveillant client. Cela peut être en raison de phishing ou de quelque autre prétexte...

Answer 5

Je ne suis pas sûr que je comprends bien la réponse et Dan commentaire. Il me semble que la réponse a déclaré certains faits exacts, mais il n'est point exactement ce que l'OP a demandé. Si je comprends bien, l'avantage majeur de la reconnaissance implicite de l'écoulement est qu'un client comme JS app (e.g extension Chrome) n'a pas à exposer les secrets du client.

Dan Taflin dit:

...dans le code d'autorisation de flux le propriétaire de la ressource ne doit jamais voir le jeton d'accès, alors que dans le javascript clients qui est inévitable. Client secret pourrait encore être conservés à partir de javascript clients à l'aide du code d'autorisation de flux, cependant..

J'ai peut-être mal compris, mais le client (JS application dans ce cas) doit transmettre les informations d'identification du client (client de la clé et le secret) pour le serveur de ressources dans le code d'autorisation de flux de, droite ? Le client secret ne peut pas être "JS".