Comment intégrer OAuth à une application d'une seule page?



utiliser le mode strict pour les uri de redirection (3)

Ce que José F. Romaniello a said est correct. Cependant, votre question est large et j’estime donc que toutes les conclusions proposées ne sont que des généralités à ce stade.

État de l'application

Par exemple, sans connaître la complexité de l'état de votre application au moment où vous souhaitez laisser vos utilisateurs se connecter, personne ne peut savoir avec certitude si l'utilisation d'une redirection est même pratique. Considérez que vous êtes prêt à laisser l'utilisateur se connecter très tard dans l'utilisation de son flux de travail / de l'application, à un moment où votre application conserve l'état que vous ne voulez vraiment pas sérialiser et enregistrer sans raison valable. Laissez seul écrire du code pour le reconstruire.

Remarque: vous verrez de nombreux conseils pour simplement ignorer ceci sur le Web. En effet, de nombreuses personnes stockent la plupart de l'état de leur application dans une session de stockage côté serveur et très peu sur leur client (léger). Parfois par erreur, parfois cela a vraiment du sens - assurez-vous que ça le fait pour vous si vous choisissez de l'ignorer. Si vous développez un client lourd, ce 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 à cause de tous leurs abus, mais il faut considérer les bons usages. Dans ce cas, ils servent exactement aux mêmes objectifs que les dialogues sécurisés dans d'autres types de systèmes (pensez à Windows UAC, fd.o polkit, etc.). Ces interfaces se rendent toutes reconnaissables et utilisent les fonctionnalités de leur plate-forme sous-jacente pour s'assurer qu'elles ne peuvent pas être falsifiées et que l'entrée et l'affichage ne peuvent pas être interceptés par l'application non privilégiée. Le parallèle est que le chrome du navigateur, et en particulier le cadenas de certificat, ne peut pas être usurpé, et que la stratégie d'origine unique empêche l'application d'accéder au DOM de la popup. L'interaction entre la boîte de dialogue (popup) et l'application peut avoir lieu à l'aide de la messagerie documentaire ou d' autres techniques .

C'est probablement le moyen optimal, du moins jusqu'à ce que les navigateurs normalisent d'une manière ou d'une autre l'autorisation de privilège, le cas échéant. Même dans ce cas, les processus d'autorisation pour certains fournisseurs de ressources peuvent ne pas correspondre à des pratiques standardisées. Par conséquent, des dialogues personnalisés flexibles, comme nous le voyons aujourd'hui, pourraient être nécessaires.

Transitions de même fenêtre

Dans cet esprit, il est vrai que l’esthétique derrière un popup est subjective. À l'avenir, les navigateurs pourraient fournir des API pour permettre le chargement d'un document sur une fenêtre existante sans décharger le document existant, puis permettre au nouveau document de se décharger et de restaurer le document précédent. La question de savoir si l'application "cachée" continue de fonctionner ou est figée (ce qui revient à penser que les technologies de virtualisation peuvent geler les processus) est un autre débat. Cela permettrait la même procédure que ce que vous obtenez avec les popups. À ma connaissance, il n'y a aucune proposition de faire cela.

Remarque: Vous pouvez simuler ceci en rendant en quelque sorte tout l'état de votre application facilement sérialisable et en ayant une procédure qui le stocke et le restaure dans / à partir du stockage local (ou d'un serveur distant). Vous pouvez ensuite utiliser les redirections old-school. Comme implicitement au début, ceci est potentiellement très intrusif pour le code de l'application.

Onglets

Une autre solution consiste évidemment à ouvrir un nouvel onglet, à communiquer avec lui exactement comme vous le feriez avec une fenêtre contextuelle, puis à le fermer de la même manière.

Sur la prise des informations d'identification de l'utilisateur de l'application sans privilège

Bien entendu, cela ne peut fonctionner que si vos utilisateurs vous font suffisamment confiance pour ne pas envoyer les informations d'identification à votre serveur (ou à tout autre endroit où ils ne souhaitent pas qu'ils se retrouvent). Si vous ouvrez votre code et que vous effectuez des constructions / minimisations déterministes, il est théoriquement possible aux utilisateurs de procéder à un audit ou à un audit du code, puis de vérifier automatiquement que vous n'avez pas altéré la version d'exécution - pour gagner leur confiance. Les outils nécessaires pour le faire sur le Web n’existent pas, autant que je sache.

Cela étant dit, vous souhaitez parfois utiliser OAuth avec un fournisseur d'identité sous votre contrôle / autorité / marque. Dans ce cas, toute la discussion est discutable - l'utilisateur vous fait déjà confiance.

Conclusion

En fin de compte, il s’agit de (1) quelle est l’épaisseur de votre client et (2) à quoi vous voulez que l’UX ressemble.

Lors de l'utilisation de OAuth (2), j'ai besoin d'un point de terminaison de redirection dans mon application vers lequel le service offrant OAuth peut se rediriger, une fois que j'ai été authentifié.

Comment gérer cela dans une application d'une seule page? Bien entendu, une redirection vers le service d'offre OAuth n'est pas agréable ici et il peut même ne pas être possible de la rediriger.

Je sais qu'OAuth prend également en charge la génération de jetons basée sur un nom d'utilisateur / mot de passe. Cela fonctionne parfaitement avec un appel AJAX, mais nécessite que mon application de page unique demande un nom d'utilisateur et un mot de passe.

Comment gérez-vous habituellement cela?


OAuth2 a 4 flux ou types de subventions, chacun servant un objectif spécifique:

  • Code d'autorisation (celui auquel vous avez fait allusion, qui nécessite une redirection)
  • Implicite
  • Identifiant du client
  • Identifiant du mot de passe du propriétaire de la ressource

La réponse courte est: utilisez le flux implicite.

Pourquoi? Le choix d'un type de flux ou d'octroi dépend du fait qu'une partie de votre code peut rester privée. Elle est donc capable de stocker une clé secrète. Si tel est le cas, vous pouvez choisir le flux OAuth2 le plus sécurisé - Authorization Code , sinon vous devrez faire des compromis sur un flux OAuth2 moins sécurisé. par exemple, pour une application à page unique (SPA) qui sera un flux Implicit .

Client Credential flux d' Client Credential ne fonctionne que si le service Web et l'utilisateur sont la même entité. En d'autres termes, le service Web ne sert que cet utilisateur spécifique. identifiants de connexion sociale au service.

Pour bien comprendre la différence entre le flux Implicit recommandé et le flux de Authorization Code (celui auquel vous avez fait allusion et qui nécessite une redirection), examinez le flux côte à côte:

Ce diagramme a été tiré de: https://blog.oauth.io/introduction-oauth2-flow-diagrams/


La plupart du temps, une redirection est acceptable même pour SPA car les utilisateurs n'aiment pas mettre leurs informations d'identification de service X sur un site Web autre que X. Une alternative consiste à utiliser une petite fenêtre contextuelle. Vous pouvez vérifier ce que fait Discourse . IMHO une redirection vaut mieux qu'un popup.

Google Certains fournisseurs prennent en charge le flux de propriétaires de ressources, qui correspond à ce que vous avez décrit comme l'envoi d'un nom d'utilisateur et d'un mot de passe, mais ce n'est pas agréable. Ce sont les problèmes que je vois:

  1. Demander des informations d’identification Google aux utilisateurs de votre site ne sera pas une tâche facile pour certains utilisateurs.
  2. Les flux de propriétaires de ressources ont également besoin de client_secret, ce que vous ne devez PAS mettre dans votre javascript côté client. Si vous instanciez le flux de propriétaires de ressources à partir de votre application côté serveur et que votre application ne se trouve pas dans la même région géographique que l'utilisateur, l'utilisateur recevra un avertissement "hé quelqu'un essaie d'accéder avec vos informations d'identification de l'Inde".

OAuth décrit un flux côté client appelé flux implicite . En utilisant ce flux, vous n'avez besoin d'aucune interaction de votre côté serveur ni du secret client_secret. Le fournisseur OAuth redirige vers votre application avec un "# access_token = xx". Cela s'appelle implicite, car vous n'avez pas besoin d'échanger le code d'autorisation par jeton d'accès , vous obtenez directement un access_token.

Google implémente le flux implicite, cochez: Utilisation de OAuth2 pour les applications côté client .

Si vous souhaitez utiliser le flux implicite avec un fournisseur qui ne le prend pas en charge, tel que Github, vous pouvez utiliser un courtier d'authentification tel que Auth0 .

disclaimer: Je travaille pour Auth0.