tl; dr: Tout cela pour des raisons de sécurité.
OAuth 2.0 voulait répondre à ces deux critères:
- Vous souhaitez autoriser les développeurs à utiliser l'URI de redirection non HTTPS car tous les développeurs n'ont pas de serveur compatible SSL et s'ils le font, il n'est pas toujours correctement configuré (non-signé, certificats SSL de confiance, horloge du serveur synchronisé ...).
- Vous ne voulez pas que les pirates puissent voler des jetons d'accès / d'actualisation en interceptant les demandes.
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 en tant que fragment de hachage (et non en tant que 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 transmettront le fragment de hachage directement à la page Web de destination (l'URI de redirection / la page Web du client). Le fragment de hachage a les propriétés suivantes:
- Ils ne font pas partie de la requête HTTP, ils ne peuvent donc pas être lus par les serveurs et de ce fait, ils ne peuvent pas être interceptés par des serveurs / routeurs intermédiaires (c'est important).
- Ils n'existent que du côté du navigateur - côté client - donc la seule façon de lire le fragment de hachage est d'utiliser JavaScript qui s'exécute sur la page.
Cela permet de transmettre un Token d'accès directement au client sans risque d'être intercepté par un serveur intermédiaire. Cela a la mise en garde d'être uniquement possible côté client et nécessite que javascript soit exécuté côté client pour utiliser le jeton d'accès.
Le flux implicite présente également des problèmes de sécurité qui nécessitent une logique supplémentaire pour contourner / éviter, par exemple:
- Un attaquant pourrait obtenir un jeton d'accès d'un utilisateur sur un autre site Web / application (disons s'il est le propriétaire de l'autre site Web / application), enregistrer le jeton sur son site Web, puis le transmettre en tant que paramètre d'URL sur votre site Web. donc usurper l'identité de l'utilisateur sur votre site Web. Pour éviter cela, vous devez vérifier l'ID client associé au jeton d'accès (par exemple pour Google, vous pouvez utiliser le point de terminaison tokeninfo) pour vous assurer que le jeton a été émis avec votre propre ID client (c'est-à-dire par votre propre application) ou vérifier la signature si vous utilisez un IDToken (mais cela nécessite le secret de votre client).
- Si la demande d'authentification ne provient pas de votre propre propriété (appelée attaques de fixation de session), pour éviter cela, vous voudrez générer un hachage aléatoire à partir de votre site Web, l'enregistrer dans un cookie et transmettre ce même hachage dans le paramètre d'URL d'état de la demande d'authentification, lorsque l'utilisateur revient, vous vérifiez le paramètre d'état avec le cookie et il doit correspondre.
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 passerait (des centaines) pourrait être en mesure de lisez le jeton d'accès si vous n'utilisez pas de connexion cryptée (HTTPS) autorisant ce que l'on appelle les attaques d'homme au milieu
Passer 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 le cryptage TLS et un certificat SSL `` de confiance '' (généralement d'une autorité de certification qui n'est pas gratuite) pour être sûr que le serveur de destination est légitime et que la requête HTTP est entièrement cryptée. Faire en sorte que tous les développeurs achètent un certificat SSL et configurent correctement SSL sur leur domaine serait une énorme douleur et ralentirait considérablement l'adoption. C'est pourquoi un "code d'autorisation" à usage unique intermédiaire est prévu que seul le destinataire légitime pourra échanger (car vous avez besoin du secret client) et que le code sera inutile aux pirates potentiels interceptant les demandes sur des transactions non cryptées (parce qu'ils ne
Vous pouvez également affirmer que le flux implicite est moins sécurisé, il existe des vecteurs d'attaque potentiels comme 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 (qui sont censés avoir une utilisation limitée dans le temps) et ne rafraîchit 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 dans la mesure du possible.