Quel est le but du type d'autorisation de subvention implicite dans OAuth 2?
Je ne sais pas si j'ai un angle mort ou quoi, mais j'ai lu le cahier des charges d'OAuth 2 à plusieurs reprises et consulté les archives de la liste de diffusion, et je n'ai pas encore trouvé de bonne explication quant à la raison pour laquelle la subvention implicite le flux d’obtention des jetons d’accès a été mis au point. Comparé à l'autorisation de code d'autorisation, il semble abandonner tout simplement l'authentification du client sans raison très convaincante. Comment cela est-il "optimisé pour les clients mis en œuvre dans un navigateur utilisant un langage de script" (pour citer la spécification)?
Les deux flux démarrent de la même manière (source: http://tools.ietf.org/html/draft-ietf-oauth-v2-22 ):
- Le client initie le flux en dirigeant l'agent utilisateur du propriétaire de la ressource vers le noeud final d'autorisation.
- 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.
- En supposant que le propriétaire de la ressource accorde l'accès, le serveur d'autorisation redirige l'agent utilisateur vers le client en utilisant l'URI de redirection fourni précédemment (dans la demande ou lors de l'enregistrement du client) .
- L'URI de redirection comprend un code d'autorisation (flux de codes d'autorisation)
- L'URI de redirection comprend le jeton d'accès dans le fragment d'URI (flux implicite).
Voici où les flux se séparent. Dans les deux cas, l'URI de redirection à ce stade concerne un point d'extrémité hébergé par le client:
- Dans le flux de codes d'autorisation, lorsque l'agent d'utilisateur atteint ce noeud final avec le code d'autorisation dans l'URI, le code situé sur ce noeud final échange le code d'autorisation avec ses informations d'identification client pour un jeton d'accès qu'il peut ensuite utiliser en fonction des besoins. 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 du client et charge simplement une page Web avec un script client. Il existe une astuce intéressante avec le fragment d'URL qui empêche le jeton d'accès de trop circuler, mais le résultat final est essentiellement identique: le site hébergé par le client affiche une page contenant un script capable de 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?
Voici mes pensées:
L'objet de code d'autorisation + jeton dans le flux de code d'autorisation est que le jeton et le secret client ne soient jamais exposés au propriétaire de la ressource, car ils voyagent de serveur à serveur.
D'autre part, le flux d'octroi implicite concerne les clients entièrement implémentés à l'aide de javascript et s'exécutant dans le navigateur du propriétaire de la ressource. Vous n'avez besoin d'aucun code côté serveur pour utiliser ce flux. Ensuite, si tout se passe dans le navigateur du propriétaire de la ressource, émettre un code d'authentification et le secret du client n'a plus de sens, car le secret du jeton et du client sera toujours partagé avec le propriétaire de la ressource. L'inclusion du code d'autorisation et du secret du client rend le flux plus complexe sans ajouter de sécurité supplémentaire.
Donc, la réponse sur "qu'est-ce qui a été gagné?" est la "simplicité".
C'est là pour des raisons de sécurité, pas pour la simplicité.
Vous devez considérer la différence entre le user agent et le client :
L'agent d'utilisateur est le logiciel par lequel l'utilisateur ("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 de l'agent utilisateur et du client découplés, le Autorisation du code d'autorisation a un sens. Par exemple. l'utilisateur utilise un navigateur Web (agent utilisateur) pour se connecter à son compte Facebook sur Kickstarter. Dans ce cas, le client est l'un des serveurs de Kickstarter, qui gère les connexions des utilisateurs. 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 interaction de l'utilisateur.
Si l'agent utilisateur et le client sont couplés (par exemple, application mobile native, application javascript), le flux de travaux 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 indiquant que cette méthode n'est pas conçue pour accéder aux ressources de l'utilisateur en l'absence de l'utilisateur.
L'explication habituelle est que la subvention implicite est plus facile à mettre en œuvre lorsque vous utilisez un client JavaScript. Mais je pense que ce n'est pas la bonne façon de voir les choses. Si vous utilisez un client JavaScript qui demande directement des ressources protégées via XMLHttpRequest, la subvention implicite est votre seule option, même si elle est moins sécurisée.
L'attribution de code d'autorisation fournit une sécurité supplémentaire, mais elle ne fonctionne que si un serveur Web demande les ressources protégées. Étant donné que le serveur Web peut stocker le jeton d'accès, vous exposez moins le jeton d'accès à Internet et vous pouvez émettre un jeton qui dure longtemps. Et comme le serveur Web est approuvé, un "jeton d'actualisation" peut lui être attribué afin qu'il puisse obtenir un nouveau jeton d'accès lorsque l'ancien expirera.
Mais - et c’est un point facile à manquer -, la sécurité du flux de codes d’autorisation ne fonctionne que si le serveur Web est protégé par une session, établie avec l’authentification de l’utilisateur (connexion). Sans session, un utilisateur non approuvé pourrait simplement adresser des requêtes au serveur Web à l'aide de l'identifiant client_id. 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 JS webapp, pas l'authentification de cette webapp.
Cela signifie également que vous pouvez mettre fin à la session avant l'expiration du jeton OAuth. Il n'y a pas de moyen standard d'invalider un jeton d'accès. Mais si votre session expire, le jeton d'accès est inutile, car personne ne le sait sauf le serveur Web. Si un utilisateur non approuvé 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 approuvé y accède, il peut l’utiliser jusqu’à son expiration. Cela signifie qu'ils y auront accès plus longtemps qu'avec une autorisation de code d'autorisation. Vous pouvez donc envisager de rendre le jeton expirer plus tôt et d'éviter de donner accès à des ressources plus sensibles.
Cela se résume à ceci: Si un utilisateur exécute une application Web (JavaScript) basée sur un navigateur, ou "publique", sans composant côté serveur, alors l'utilisateur implicitement approuve l'application (et le navigateur où il fonctionne, éventuellement avec d'autres applications basées sur un navigateur ...).
Il n'y a pas de serveur distant tiers, uniquement le serveur de ressources. Un code d'autorisation ne présente aucun avantage, car il n'y a pas d'agent autre sauf le navigateur qui agit pour le compte de l'utilisateur. Les informations d'identification du client ne présentent aucun avantage pour la même raison. (Le client _ {Any}} peut essayer d'utiliser ce flux.)
Les conséquences pour la sécurité sont toutefois importantes. De http://tools.ietf.org/html/rfc6749#section-10.3 :
Lors de l'utilisation du type d'attribution implicite, le jeton d'accès est transmis dans le fragment d'URI, ce qui peut l'exposer à des tiers non autorisés.
De http://tools.ietf.org/html/rfc6749#section-10.16 :
Un propriétaire de ressource peut déléguer volontairement l'accès à une ressource de attribution d'un jeton d'accès au client malveillant d'un attaquant. Ceci peut être due au phishing ou à un autre prétexte ...
Je ne suis pas sûr d'avoir bien compris la réponse et le commentaire de Dan. Il me semble que la réponse indique que certains faits sont exacts, mais elle indique exactement ce que demande OP. Si je comprends bien, l’avantage majeur du flux d’octroi implicite est qu’un client tel que JS app (par exemple une extension Chrome) n’a pas à exposer le secret du client.
Dan Taflin a déclaré:
... dans le flux de code d'autorisation, le propriétaire de la ressource n'a jamais besoin de voir le jeton d'accès, alors que dans les clients javascript, c'est inévitable. Le secret du client peut toujours être gardé des clients javascript à l'aide du flux de code d'autorisation, cependant.
Je vous ai peut-être mal compris, mais le client (application JS dans ce cas) doit transmettre les informations d'identification du client (clé client et secret) au serveur de ressources dans le flux de codes d'autorisation, n'est-ce pas? Le secret du client ne peut pas être "gardé de JS".
Alors que Implicit Grant était conçu pour prendre en charge des applications ne pouvant pas protéger un secret client, y compris des applications JavaScript côté client, certains fournisseurs implémentent une alternative utilisant un code d'autorisation sans secret client. Le document OAuth 2.0 IETF RFC-6749 a été publié en 2012 et les recommandations actuelles, dont certaines discussions récentes, datent de 2017.
La discussion de 2017 sur la liste de diffusion IETF OAuth est disponible auprès de ces développeurs:
- Redhat: https://www.ietf.org/.../oauth/current/msg16966.html
- Deutsche Telekom: https://www.ietf.org/.../oauth/current/msg16968.html
- Smart Health IT: https://www.ietf.org/.../oauth/current/msg16967.html
Lire la suite ici:
- https://aaronparecki.com/oauth-2-simplified/
- https://aaronparecki.com/oauth-2-simplified/#single-page-apps
Implicit était précédemment recommandé pour les clients sans secret, mais a été remplacé par l'utilisation de l'attribution de code d'autorisation sans secret.
...
Auparavant, il était recommandé aux applications basées sur un navigateur d'utiliser le flux "implicite", qui renvoie immédiatement un jeton d'accès et ne comporte pas d'étape d'échange de jeton. Depuis la rédaction initiale de la spécification, la meilleure pratique de l'industrie a été modifiée pour recommander l'utilisation du flux de codes d'autorisation sans le secret client. Cela offre davantage d'opportunités pour créer un flux sécurisé, tel que l'utilisation du paramètre state. Références: Redhat , Deutsche Telekom , Smart Health IT .
Le passage à un code d'authentification sans secret client issu d'une subvention implicite est également mentionné pour les applications mobiles ici:
Dans le flux implicite, si le navigateur de l'utilisateur est corrompu (extension malveillante/virus), il parvient à accéder aux ressources de l'utilisateur et peut faire le nécessaire.
Dans le flux d'authentification, la corruption ne peut pas car elle ne connaît pas le secret du client.
en plus des autres réponses, il est également important de comprendre que le profil implicite permet un flux uniquement sur le canal frontal, par opposition au flux de code d'autorisation qui nécessite un rappel vers le serveur d'autorisations. cela devient évident dans OpenID Connect, qui est un protocole SSO basé sur Auth 2.0, dans lequel le flux implicite ressemble à la très populaire liaison SAML POST et le flux de code d'autorisation ressemble à la liaison SAML Artifact moins largement déployée.
Je pense que Will Cain a répondu à cela lorsqu'il a déclaré: "Les informations d'identification du client ne présentent aucun avantage pour la même raison. (Tout client peut essayer d'utiliser ce flux.)" Considérez également que redirect_uri pour le flux implicite est peut-être "localhost" - pas de rappel est faite à partir du serveur d'autorisations pour le flux implicite. Comme il n'existe aucun moyen de pré-approuver le client, l'utilisateur devrait approuver la publication de ses revendications.
https://tools.ietf.org/html/rfc6749#page-8
Implicite
L'attribution implicite est un flux de code d'autorisation simplifié optimisé pour les clients implémentés dans un navigateur utilisant un script langage tel que JavaScript. Dans le flux implicite, au lieu de en émettant un code d'autorisation au client, il reçoit un jeton d'accès directement (à la suite de l'autorisation du propriétaire de la ressource .__). Le type de subvention est implicite, pas d'intermédiaire les informations d'identification (telles qu'un code d'autorisation) sont émises (et plus tard, utilisées pour obtenir un jeton d'accès).
Lors de l’émission d’un jeton d’accès pendant le flux d’attribution implicite, le
Le serveur d'autorisation n'authentifie pas le client. Dans certaines
Dans certains cas, l'identité du client peut être vérifiée via l'URI de redirection.
utilisé pour délivrer 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 certains
les clients (tels qu'un client implémenté en tant qu'application dans le navigateur),
puisqu'il réduit le nombre d'allers et retours nécessaires pour obtenir un
jeton d'accès.
L'attribution implicite permet d'obtenir des jetons à partir de Authorization Endpoint avec un GET. Cela signifie que le serveur d'autorisation ne doit pas nécessairement prendre en charge CORS.
Si cela ne pose pas de problème et s'il n'y a pas d'autres problèmes liés au serveur d'autorisation qui ont été inflexibles (par exemple, les jetons d'actualisation ne sont pas facultatifs, pour une raison quelconque), le flux de code d'autorisation est privilégié, même pour les clients publics, selon recent tendances de l’industrie et au moins cette (actuelle) exemple de projet officiel .
Auparavant, il existait d'autres raisons d'implémenter le flux implicite, mais il semble que les avantages en termes de sécurité procurés par la concession de code d'autorisation, tels que:
- possibilité de remettre et d'utiliser les jetons sur un canal de retour pour les clients confidentiels
- ne pas exposer les jetons dans l'historique du navigateur pour les clients publics
- interrompre un flux non autorisé avant que des jetons ne soient émis - avec PKCE , pour "toutes sortes de clients OAuth"
Je viens de lire un article sur OAuth 2.0. L'auteur déclare que la raison derrière le flux implicite est que les applications JS étaient très limitées dans leurs requêtes:
si vous vous demandez pourquoi le type implicite a été inclus dans OAuth 2.0, l'explication est simple: politique d'origine identique. À l'époque, les applications frontales n'étaient pas autorisées à envoyer des requêtes à différents hôtes pour obtenir le jeton d'accès à l'aide de code. Aujourd'hui, nous avons CORS (Cross-Origin Resource Sharing).