tutorial - oauth2 implementation




Quel est le but du type d'autorisation de subvention implicite dans OAuth 2? (6)

Cela se résume à: Si un utilisateur exécute une application web (ou JavaScript) basée sur navigateur, ou publique, sans composant côté serveur, l'utilisateur approuve implicitement l'application (et le navigateur où il s'exécute, potentiellement avec un autre navigateur) applications basées sur ...).

Il n'y a pas de serveur distant tiers, seul le serveur de ressources. Il n'y a aucun avantage à un code d'autorisation, car il n'y a pas d' autre agent que le navigateur agissant au nom de l'utilisateur. Il n'y a aucun avantage pour les informations d'identification du client pour la même raison. ( Tout client peut essayer d'utiliser ce flux.)

Les implications de sécurité, cependant, sont significatives. De http://tools.ietf.org/html/rfc6749#section-10.3 :

Lors de l'utilisation du type de subvention implicite, le jeton d'accès est transmis dans le fragment d'URI, ce qui peut l'exposer à des parties non autorisées.

De http://tools.ietf.org/html/rfc6749#section-10.16 :

Un propriétaire de ressource peut volontairement déléguer l'accès à une ressource en accordant un jeton d'accès au client malveillant d'un attaquant. Cela peut être dû à l'hameçonnage ou à d'autres prétextes ...

Je ne sais pas si j'ai juste une sorte de point aveugle ou quoi, mais j'ai lu plusieurs fois la spécification OAuth 2 et j'ai parcouru les archives de la liste de diffusion, et je n'ai pas encore trouvé une bonne explication de pourquoi la subvention implicite flux pour obtenir des jetons d'accès a été développé. Comparé à la subvention de code d'autorisation, il semble juste abandonner l'authentification du client pour aucune raison très convaincante. Comment cela est-il "optimisé pour les clients implémentés dans un navigateur en utilisant un langage de script" (pour citer la spécification)?

Les deux flux commencent le même (source: http://tools.ietf.org/html/draft-ietf-oauth-v2-22 ):

  1. Le client initie le flux en dirigeant l'agent utilisateur du propriétaire de la ressource vers le point de terminaison d'autorisation.
  2. Le serveur d'autorisation authentifie le propriétaire de la ressource (via l'agent utilisateur) et détermine si le propriétaire de la ressource accorde ou refuse la demande d'accès du client.
  3. En supposant que le propriétaire de la ressource accorde l'accès, le serveur d'autorisation redirige l'agent utilisateur vers le client à l'aide de l'URI de redirection fournie précédemment (dans la demande ou lors de l'inscription du client).
    • L'URI de redirection inclut un code d'autorisation (flux de code d'autorisation)
    • L'URI de redirection inclut le jeton d'accès dans le fragment URI (flux implicite)

Voici où les flux se divisent. Dans les deux cas, l'URI de redirection à ce stade est à un point de terminaison hébergé par le client:

  • Dans le flux de code d'autorisation, lorsque l'agent utilisateur rencontre ce point de terminaison avec le code d'autorisation dans l'URI, le code de ce point de terminaison échange le code d'autorisation avec ses informations d'identification client pour un jeton d'accès. Il pourrait, par exemple, l'écrire dans une page Web à laquelle un script de la page pourrait accéder.
  • Le flux implicite ignore complètement cette étape d'authentification client et charge simplement une page Web avec le script client. Il y a un truc mignon ici avec le fragment d'URL qui empêche de trop passer le jeton d'accès, mais le résultat final est essentiellement le même: le site hébergé par le client sert une page avec un script qui peut récupérer le jeton d'accès .

D'où ma question: qu'est-ce qui a été gagné ici en sautant l'étape d'authentification du client?


Dans le flux implicite si le navigateur de l'utilisateur est corrompu (mal extension / virus) alors la corruption accède aux ressources de l'utilisateur et peut faire les mauvaises choses.

Dans le flux d'auth, la corruption ne peut pas parce qu'elle ne connaît pas le secret du client.


Je pense que Will Cain a répondu ceci quand il a dit "il n'y a aucun avantage aux identifiants de client pour la même raison. (Tout client peut essayer d'utiliser ce flux.)" Considérez également que le redirect_uri pour le flux implicite peut "localhost" - aucun callback est faite à partir du serveur d'autorisation pour le flux implicite. Comme il n'y a aucun moyen de pré-approuver le client, l'utilisateur devrait approuver la publication des revendications des utilisateurs.


L'explication habituelle est que l'allocation implicite est plus facile à implémenter lorsque vous utilisez un client JavaScript. Mais je pense que c'est la mauvaise façon de le regarder. Si vous utilisez un client JavaScript qui demande des ressources protégées directement via XMLHttpRequest, la subvention implicite est votre seule option, bien qu'elle soit moins sécurisée.

L'attribution de code d'autorisation offre une sécurité supplémentaire, mais elle ne fonctionne que si vous avez un serveur Web qui demande les ressources protégées. Comme le serveur Web peut stocker le jeton d'accès, vous courez moins de risques que le jeton d'accès soit exposé à Internet et vous pouvez émettre un jeton qui dure longtemps. Et comme le serveur Web est approuvé, il peut recevoir un «jeton d'actualisation», ce qui lui permet d'obtenir un nouveau jeton d'accès lorsque l'ancien expire.

Mais - et c'est un point qui est facile à manquer - la sécurité du flux de code d'autorisation ne fonctionne que si le serveur web est protégé par une session, qui est établie avec l'authentification de l'utilisateur (login). Sans une session, un utilisateur non autorisé pourrait simplement faire des demandes au serveur Web, en utilisant le client_id, et ce serait la même chose que si l'utilisateur avait le jeton d'accès. L'ajout d'une session signifie que seul un utilisateur authentifié peut accéder aux ressources protégées. Le client_id est juste "l'identité" de la webapp JS, pas l'authentification de cette webapp.

Cela signifie également que vous pouvez terminer la session avant l'expiration du jeton OAuth. Il n'existe aucun moyen standard d'invalider un jeton d'accès. Mais si votre session expire, le jeton d'accès est inutile, puisque personne ne le connaît mais le serveur web. Si un utilisateur non autorisé accède à votre clé de session, il ne pourra accéder aux ressources protégées que tant que la session sera valide.

S'il n'y a pas de serveur Web, vous devez utiliser la subvention implicite. Mais cela signifie que le jeton d'accès est exposé à Internet. Si un utilisateur non autorisé y accède, il peut l'utiliser jusqu'à son expiration. Cela signifie qu'ils y auront accès plus longtemps qu'avec une subvention du Code d'autorisation. Vous pouvez donc envisager de faire en sorte que le jeton expire plus tôt et d'éviter d'accéder à des ressources plus sensibles.


https://tools.ietf.org/html/rfc6749#page-8

Implicite

La subvention implicite est un flux de code d'autorisation simplifié optimisé pour les clients implémentés dans un navigateur utilisant un langage de script tel que JavaScript. Dans le flux implicite, au lieu d'émettre un code d'autorisation au client, le client reçoit directement un jeton d'accès (résultat de l'autorisation du propriétaire de la ressource). Le type de subvention est implicite, car aucune information d'identification intermédiaire (telle qu'un code d'autorisation) n'est émise (et utilisée ultérieurement pour obtenir un jeton d'accès).

Lors de l'émission d'un jeton d'accès pendant le flux de subvention implicite, le
Le serveur d'autorisation n'authentifie pas le client. Dans certaines
cas, l'identité du client peut être vérifiée via l'URI de redirection
utilisé pour fournir le jeton d'accès au client. Le jeton d'accès peut être exposé au propriétaire de la ressource ou à d'autres applications ayant accès à l'agent utilisateur du propriétaire de la ressource.

Les subventions implicites améliorent la réactivité et l'efficacité de certaines
les clients (comme un client implémenté en tant qu'application dans le navigateur),
puisqu'il réduit le nombre d'allers-retours requis pour obtenir un
jeton d'accès.


C'est là pour des raisons de sécurité, pas pour la simplicité.

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

L'agent utilisateur est le logiciel par lequel l'utilisateur (le «propriétaire de la ressource») communique avec d'autres parties du système (serveur d'authentification et 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 d'un user-agent et d'un client découplés, l' attribution de code d'autorisation a du sens. Par exemple, l'utilisateur utilise un navigateur Web (user-agent) pour se connecter avec son compte Facebook sur Kickstarter. Dans ce cas, le client est l'un des serveurs de Kickstarter, qui gère les connexions utilisateur. Ce serveur reçoit le jeton d'accès et le jeton d'actualisation de Facebook. Ainsi ce type de client considéré comme «sécurisé», en raison d'un accès restreint, les jetons peuvent être sauvegardés et Kickstarter peut accéder aux ressources des utilisateurs et même actualiser les jetons d'accès sans intervention de l'utilisateur.

Si l'agent utilisateur et le client sont couplés (application mobile native, application javascript, par exemple), le workflow d'autorisation implicite peut être appliqué. Il repose sur la présence du propriétaire de la ressource (pour entrer les informations d'identification) et ne prend pas en charge les jetons d'actualisation. Si ce client stocke le jeton d'accès pour une utilisation ultérieure, il s'agira d'un problème de sécurité, car le jeton peut être facilement extrait par d'autres applications ou utilisateurs du client. L'absence du jeton d'actualisation est un indice supplémentaire, que cette méthode n'est pas conçue pour accéder aux ressources utilisateur en l'absence de l'utilisateur.