Comment intégrer OAuth avec une seule page de l'application?

Ce que José F. Romaniello dit est correct. Cependant, votre question est large et donc je me sens toute offert conclusions sont juste des généralités à ce point.

L'état de l'Application

Par exemple, sans savoir comment la complexité de votre état de l'application est à la fois que vous voulez laisser à vos utilisateurs de se connecter, personne ne peut savoir à coup sûr si vous utilisez une redirection est même pratique à tous les. Considérez que vous pourriez être disposé à permettre à l'utilisateur de connecter très en retard dans son flux de production/utilisation d'une application, à un point où votre demande est titulaire d'état que vous ne voulez vraiment pas à sérialiser et enregistrez-les pour aucune bonne raison. Encore moins écrire du code pour la reconstruire.

Remarque: Vous verrez que de nombreux conseils afin de tout simplement ignorer ce sur le web. C'est parce que beaucoup de gens stockent plus de l'état de leur application dans de session côté serveur de stockage et très peu sur leur (maigre) client. Parfois, par erreur, parfois, il fait vraiment de sens -- assurez-vous qu'il fait pour vous si vous choisissez de l'ignorer. Si vous êtes le développement d'un client lourd, il n'est généralement pas le cas.

Popup dialogues

Je me rends compte que les popups ont une mauvaise réputation sur le web, car de toutes leurs dérives, mais on doit tenir compte de bons usages. Dans ce cas, ils servent exactement les mêmes fins que confiance des boîtes de dialogue dans d'autres types de systèmes (pensez UAC Windows, fd.o polkit, etc). Ces interfaces de tout faire eux-mêmes reconnaissable et l'utilisation de leur plateforme sous-jacente de fonctions pour s'assurer qu'ils ne peuvent pas être falsifiés et que d'entrée, ni d'affichage ne peut pas être intercepté par les non-privilégiés d'application. Le parallèle exact, c'est que le navigateur chrome et en particulier le certificat de cadenas ne peut pas être falsifié, et que l'origine unique de la politique empêche l'accès de l'application de la popup DOM. L'Interaction entre la boîte de dialogue (popup) et l'application peut se produire à l'aide de la croix-document de messagerie ou d'autres techniques.

C'est probablement la meilleure façon, au moins jusqu'à ce que les navigateurs en quelque sorte, de normaliser le privilège d'autorisation, si jamais ils le font. Même alors, le processus d'autorisation pour certains fournisseurs de ressources peut ne pas s'adapter pratiques normalisées, de sorte souple personnalisé des boîtes de dialogue, comme nous le voyons aujourd'hui, peut-être juste nécessaire.

Même fenêtre transitions

Avec cela à l'esprit, c'est vrai que l'esthétique derrière une fenêtre sont subjectives. Dans l'avenir, les navigateurs peuvent fournir des Api pour permettre à un document qui doit être chargé sur une fenêtre existante sans décharger le document existant, puis laissez le nouveau document afin de décharger et de restaurer le document précédent. Si le "caché" de l'application continue de fonctionner ou est gelé (similaire à la façon dont les technologies de virtualisation peut geler processus) est un autre débat. Cela permettrait à la même procédure que ce que vous obtenez avec des popups. Il n'y a pas de proposition à faire ce que je sache.

Remarque: Vous pouvez simuler cela en quelque sorte de faire tout votre état de l'application facilement serializable, et d'avoir une procédure qui stocke et restitue dans/de stockage local ou sur un serveur distant). Vous pouvez ensuite utiliser la vieille école des redirections. Implicite dans le début, mais, c'est potentiellement très intrusive pour le code de l'application.

Onglets

Encore une autre solution est bien sûr d'ouvrir un nouvel onglet au lieu, de communiquer avec elle, exactement comme vous le feriez pour une fenêtre, puis près de la même manière.

Sur la prise d'identification de l'utilisateur de la non-privilégié d'application

Bien sûr, il ne peut fonctionner que si vos utilisateurs confiance en vous assez de ne pas envoyer les informations d'identification de votre serveur (ou n'importe où ils ne veulent pas à finir). Si vous open-source votre code et ne déterministe builds/réduction, il est théoriquement possible pour les utilisateurs de vérification ou d'avoir quelqu'un audit du code, puis vérifier automatiquement que vous n'avez pas de sabotage avec la version d'exécution -- ainsi de gagner leur confiance. Outillage pour ce faire sur le web est inexistant autant que je sache.

Cela étant dit, il arrive que vous souhaitez utiliser OAuth avec un fournisseur d'identité sous contrôle/autorisation/de la marque. Dans ce cas, toute cette discussion est sans objet -- l'utilisateur fait confiance que vous avez déjà.

Conclusion

En fin de compte, il s'agit de (1) quelle est l'épaisseur de votre client, et (2) ce que vous voulez, les UX d'être comme.