Pourquoi existe-t-il un flux de "code d'autorisation" dans OAuth2 alors que le flux "implicite" fonctionne si bien?
Avec le flux "implicite", le client (probablement un navigateur) recevra un jeton d'accès, après que le propriétaire de la ressource (c'est-à-dire l'utilisateur) en ait donné l'accès.
Avec le flux "Code d'autorisation", le client (généralement un serveur Web) ne reçoit un code d'autorisation qu'après que le propriétaire de la ressource (c'est-à-dire l'utilisateur) a donné l'accès. Avec ce code d'autorisation, le client appelle ensuite l'API en transmettant à client_id et client_secret le code d'autorisation permettant d'obtenir le jeton d'accès. Tous bien décrits ici .
Les deux flux ont exactement le même résultat: un jeton d'accès. Cependant, le flux "implicite" est beaucoup plus simple.
La question: Pourquoi s'embêter avec le flux de "Code d'autorisation", alors que le flux "implicite" semble bien aller? Pourquoi ne pas utiliser également "Implicite" pour le serveur Web?
C'est plus de travail à la fois pour le fournisseur et le client.
tl; dr: C'est tout pour des raisons de sécurité.
OAuth 2.0 voulait répondre à ces deux critères:
- Vous souhaitez autoriser les développeurs à utiliser une URI de redirection non HTTPS car tous les développeurs ne disposent pas d'un serveur compatible SSL et, s'ils le font, il n'est pas toujours correctement configuré (certificats SSL non auto-signés, sécurisés, horloge de serveur synchronisée, etc.).
- Vous ne voulez pas que les pirates informatiques puissent voler des jetons d'accès/rafraîchir en interceptant des requêtes.
Détails ci-dessous:
Le flux implicite n'est possible que dans un environnement de navigateur pour des raisons de sécurité:
Dans le flux implicite, le jeton d'accès est transmis directement sous forme de fragment de hachage (et non sous forme de paramètre d'URL). Une chose importante à propos du fragment de hachage est que, une fois que vous suivez un lien contenant un fragment de hachage, seul le navigateur est au courant du fragment de hachage. Les navigateurs passeront le fragment de hachage directement à la page Web de destination (l'URI de redirection/la page Web du client). Les fragments de hachage ont les propriétés suivantes:
- Ils ne font pas partie de la requête HTTP et ne peuvent donc pas être lus par les serveurs. Ils ne peuvent donc pas être interceptés par des serveurs/routeurs intermédiaires (c'est important).
- Ils n'existent que sur le navigateur - côté client -. Le seul moyen de lire le fragment de hachage est donc d'utiliser JavaScript qui s'exécute sur la page.
Cela permet de transmettre un jeton d'accès directement au client sans risquer d'être intercepté par un serveur intermédiaire. Cela a pour inconvénient de n'être que le côté client possible et d'avoir besoin de JavaScript côté client en cours d'exécution pour utiliser le jeton d'accès.
Dans le flux de code d'autorisation, il n'est pas possible de passer un jeton d'accès directement dans un paramètre d'URL car les paramètres d'URL font partie de la demande HTTP. Par conséquent, tout serveur/routeur intermédiaire par lequel votre demande serait transmise (pourrait être des centaines) pourrait être en mesure de lire le jeton d'accès si vous n'utilisez pas une connexion cryptée (HTTPS) permettant des attaques dites de type "Man-in-the-middle".
Transmettre le jeton d'accès directement dans un paramètre d'URL pourrait en théorie être possible, mais le serveur d'authentification devrait s'assurer que l'URI de redirection utilise HTTPS avec chiffrement TLS et un certificat SSL "de confiance" (généralement d'une autorité de certification non libre). pour vous assurer que le serveur de destination est légitime et que la requête HTTP est entièrement chiffrée. Si tous les développeurs achetaient un certificat SSL et configuraient correctement SSL sur leur domaine, cela poserait un gros problème et ralentirait considérablement leur adoption. C’est la raison pour laquelle un "code d’autorisation" à usage unique et intermédiaire est fourni, que seul le destinataire légitime pourra échanger (car vous avez besoin du secret client) et que le code sera inutile pour les pirates potentiels qui intercepteraient les demandes via des transactions non chiffrées. (parce qu'ils ne connaissent pas le secret du client).
Vous pouvez également faire valoir que le flux implicite est moins sécurisé. Il existe des vecteurs d'attaque potentiels, tels que l'usurpation du domaine lors de la redirection - par exemple en détournant l'adresse IP du site Web du client. C'est l'une des raisons pour lesquelles le flux implicite n'accorde que des jetons d'accès (censés avoir une utilisation limitée dans le temps) et n'actualise jamais les jetons (qui sont illimités dans le temps). Pour remédier à ce problème, je vous conseille d'héberger vos pages Web sur un serveur compatible HTTPS chaque fois que cela est possible.
Le flux implicite rend le flux complet assez facile, mais également moins sécurisé .
Comme l’application client, qui est généralement le JavaScript exécuté dans un navigateur, est moins fiable, aucun jeton d’actualisation pour un accès de longue durée n’est renvoyé.
Vous devez utiliser ce flux pour les applications nécessitant un accès temporaire (quelques heures) aux données de l’utilisateur.
Le renvoi d’un jeton d’accès aux clients JavaScript signifie également que votre application basée sur un navigateur doit faire particulièrement attention - pensez aux attaques XSS susceptibles de provoquer une fuite du jeton d’accès vers d’autres systèmes.
https://labs.hybris.com/2012/06/05/oauth2-the-implicit-flow-aka-as-the-client-side-flow
De la spécification OAuth :
4.2. Subvention implicite
Le type d'accord implicite est utilisé pour obtenir des jetons d'accès (il ne prend pas en charge l'émission de jetons d'actualisation) et est optimisé pour les clients publics connus pour exploiter un URI de redirection particulier. Ces clients sont généralement implémentés dans un navigateur utilisant un langage de script tel que JavaScript.
S'agissant d'un flux basé sur la redirection, le client doit être capable d'interagir avec l'agent utilisateur du propriétaire de la ressource (généralement un navigateur Web) et de recevoir les demandes entrantes (via la redirection) du serveur d'autorisation.
Contrairement au type d'attribution de code d'autorisation, dans lequel le client effectue des demandes d'autorisation distinctes et d'un jeton d'accès, le client reçoit le jeton d'accès à la suite de la demande d'autorisation.
Le type d'octroi implicite n'inclut pas l'authentification du client et repose sur la présence du propriétaire de la ressource et sur l'enregistrement de l'URI de redirection. Le jeton d'accès étant codé dans l'URI de redirection, il peut être exposé au propriétaire de la ressource et à d'autres applications résidant sur le même périphérique.
Donc, ce que nous pouvons concider:
Ceci est destiné au public OAuth c’est-à-dire lorsque le client n’a pas besoin d’être enregistré et n’a pas ses propres secrets. Mais quel serveur auth vérifie l’URL de redirection et c’est en fait suffisant pour la sécurité.
Le jeton d’accès apparaît dans la barre d’adresse du navigateur. L’utilisateur peut donc copier l’URL et l’envoyer à une autre personne. Il est également consigné en tant qu’utilisateur, c’est-à-dire qu’il s’agit d’une réparation de session. Mais le navigateur fait une redirection supplémentaire en remplaçant l'historique pour supprimer le fragment de hachage de l'URL. Il est également possible à un pirate de voler le jeton d'accès en détectant un trafic HTTP, mais cela peut être facilement protégé par HTTPS. Certaines extensions de navigateur malveillantes peuvent avoir un accès aux URL à partir de la barre d’adresse, mais il s’agit finalement d’une mauvaise situation comme un certificat HTTPS défectueux. Et même le flux de code Auth ne peut pas aider ici, ether. Donc, ce que je peux voir, c'est que le passage de jeton d'accès via un fragment de hachage est absolument sûr.
La séparation du jeton d'accès éphémère et du jeton d'actualisation est inutile lors de l'utilisation d'un protocole HTTPS et, pour être honnête, elle n'est pas aussi utile, même sur un HTTP brut. Mais le fait que le client via un flux implicite ne puisse pas recevoir le jeton d'actualisation est également absurde.
Ainsi, je pense que nous devrions introduire un nouveau flux de subventions "sûr implicite" qui fonctionne strictement sur https, permet d'actualiser le jeton (ou nous devrions nous en débarrasser du tout), et est préférable au flux de subventions Auth Cose.
Ma réponse est la suivante: vous ne pouvez pas implémenter le flux implicite de manière simple et sécurisée avec le serveur d'applications Web.
Le processus d'autorisation des applications Web implique une interaction de l'utilisateur. Le serveur d'authentification doit rediriger le navigateur de l'utilisateur vers la page cible de l'application Web après l'authentification et le consentement de l'utilisateur (je ne vois pas d'autre moyen de renvoyer l'utilisateur au Web-app après une interaction avec Authentication Server).
Le jeton doit donc être transmis à l'application Web à l'aide de l'URL de redirection, n'est-ce pas?
Comme @NicolasGarnier l'a expliqué dans sa réponse et ses commentaires, il n'existe aucun moyen de transmettre un jeton sous forme de fragment d'URL - il ne parviendra pas au serveur d'applications Web.
Et passer un jeton en tant que paramètre URL de l'URL de redirection serait dangereux même sous HTTPS: si la page cible (que ce soit "page d'accueil") contient des ressources (images, scripts, etc.), ces ressources seront obtenues par le navigateur de la série. de requêtes HTTP (S) (chacune ayant Referer en-tête HTTP contenant l'URL exacte de la "page d'accueil", y compris les paramètres d'URL). C'est la façon dont le jeton peut fuir.
Il semble donc qu'il n'y ait aucun moyen de transmettre un jeton dans l'URL de redirection. C'est pourquoi vous avez besoin d'un deuxième appel (du serveur d'authentification au client (mais à quelle URL?) Ou du client au serveur d'authentification (le deuxième appel dans le flux du code d'autorisation))