tl;dr: C'est à cause des raisons de sécurité.
OAuth 2.0 voulu répondre à ces deux critères:
- Vous souhaitez permettre aux développeurs d'utiliser non HTTPS redirect URI parce que tous les développeurs ont un serveur avec SSL activé et si ils le font, il n'est pas toujours correctement configuré (non auto-signé, de confiance des certificats SSL, synchronisé horloge du serveur...).
- Vous ne voulez pas que les pirates pour être en mesure de voler accès/actualiser les jetons par interception des requêtes.
Les détails ci-dessous:
L'implicite débit n'est possible que dans un environnement de navigateur pour des raisons de sécurité:
Dans l'implicite de flux le jeton d'accès est passé comme un fragment de hachage, seuls les navigateurs sont informés de fragment de hachage. Les navigateurs passer le fragment de hachage directement à la page web de destination/l'URI de redirection qui est le client de son site web (fragment de hachage ne font pas partie de la requête HTTP), de sorte que vous avez à lire le fragment de hachage à l'aide de Javascript. Fragment de hachage ne peut pas être intercepté par l'intermédiaire de serveurs/routeurs (c'est important).
Dans le code d'autorisation de flux, il n'est pas possible de passer d'un jeton d'accès directement dans un paramètre de l'URL, car les paramètres d'URL sont la partie de la Requête HTTP, donc un serveur intermédiaire/routeurs par lesquels votre demande de passer (peut-être des centaines) pourrait être en mesure de lire le jeton d'accès si vous n'êtes pas en utilisant une connexion sécurisée (HTTPS), permettant de ce qui est connu comme " Man-in-the-middle attaques.
Passer le jeton d'accès directement dans l'URL param pourrait, en théorie, être possible, mais la auth sever faudrait assurez-vous que le redirect URI est l'aide de HTTPS avec le cryptage TLS et "de confiance" certificat SSL pour être sûr que le serveur de destination est correcte et que la requête HTTP est entièrement cryptée. Avoir tous les développeurs d'acheter un certificat SSL et configurer SSL sur leur domaine serait une énorme douleur et permettrait de ralentir l'adoption de descendre énormément. C'est pourquoi un intermédiaire d'un emploi du temps code d'autorisation est utilisé comme nous sommes certains que seul le développeur sera en mesure d'échanger le auth code (parce que vous avez besoin de la clé secrète client) et que le code sera inutile de potentiels pirates d'intercepter les demandes de plus de transactions non chiffrés (parce qu'ils ne connaissent pas les secrets du client).
Vous pourrait aussi affirmer que l'implicite débit est moins sûr, il existe des vecteurs d'attaque potentiels comme l'usurpation du domaine lors de la redirection par exemple par le détournement de l'adresse IP du site internet du client. C'est une des raisons pour lesquelles l'implicite débit accorde uniquement des jetons d'accès et de ne jamais actualisation des jetons (qui ont plus de valeur). Pour remédier à ce problème, je vous conseille d'utiliser le protocole HTTPS chaque fois que possible.
