Traitement des jetons d'accès expirés dans la subvention implicite OAuth2
La spécification de OAuth2 indique qu'un serveur d'autorisation ne doit pas émettre de jeton d'actualisation lors de l'utilisation d'une autorisation implicite. Dans notre cas d'utilisation, nous protégeons une API RESTful avec OAuth2 et utilisons une application Javascript Single Page en tant que client pour cette API. Comme il serait très difficile de rediriger vers le serveur d'autorisations après l'expiration d'un jeton d'accès, nous recherchons un meilleur moyen d'obtenir un nouveau jeton valide. Je pourrais penser à deux approches différentes et me demander laquelle pourrait être meilleure:
Utilisez une iframe masquée pour demander à nouveau un jeton d'accès valide. Pour cela, il est nécessaire d'inclure un paramètre tel que «Prompt = none», qui indique au fournisseur OAuth de ne pas contester l'authentification ni d'afficher une page d'autorisation. Si l'utilisateur est authentifié et a autorisé l'application, le serveur renvoie un jeton d'accès dans les paramètres # urls. Si l'une des conditions précédentes n'est pas remplie, il sera redirigé avec une erreur telle que # error = authentication% 20lost. Avec ce comportement, nous pouvons utiliser des jetons d'accès de courte durée également avec un flux implicite.
Nous pourrions utiliser une portée supplémentaire (par exemple, hors connexion) qui indique au serveur de distribuer un jeton d'actualisation. Même si la spécification d'origine indique que le flux implicite n'émet pas de jetons d'actualisation (ce qui est correct si le client utilise uniquement OAuth pour une première autorisation), vous êtes libre de définir vos propres portées pour votre application particulière. Vous devez envisager de n'autoriser cette portée que pour des clients connus.
Les deux approches sont très similaires à celles d'OpenID Connect. Malheureusement, il n'y a pas beaucoup d'implémentations d'OpenID Connect pour le moment. La première étape consiste donc à étendre le serveur OAuth2 jusqu'à ce que OIC soit plus populaire.
Alors, quelle approche faut-il préférer?
EDIT: Le noeud final du jeton a besoin de l'authentification du client, ce qui n'est possible que pour les clients confidentiels tels que les applications côté serveur. Avec la seconde approche, il serait uniquement possible de laisser l'API RESTful dans notre cas, le fournisseur de ressources, pour actualiser le jeton et le renvoyer au client. Je pense que ce serait un risque de sécurité. Nous n’avons donc probablement qu’une approche valable.
J'essaie de faire exactement la même chose pour le moment.
J'ai en fait implémenté l'approche hidden iframe et ensuite réalisé que vous devez faire très attention aux iframes. Tout site Web malveillant peut contenir votre iframe et obtenir facilement un jeton d'accès si vous ne spécifiez pas X-Frame-Options.
La meilleure approche pour jeton d'actualisation devrait être attribution du mot de passe comme spécifié par la spéc. (Je voulais que mes utilisateurs se connectent avec leur compte facebook et le flux implicite était plus facile à développer. Je n'ai pas encore compris comment procéder avec l'attribution d'un mot de passe.)
La deuxième approche m’a aussi traversé l’esprit et me semble bien plus sûre que la première, puisqu’on peut généralement faire confiance à la https & stockage sur le navigateur pour garder ses jetons secrets.
Modifier
J'ai réalisé que, même avec X-Frame-Options, la plupart des navigateurs ne peuvent pas empêcher les redirections, car cet en-tête est attaché au corps de la réponse et que l'URL redirigée sera exposée. Les jetons d'accès sont donc exposés.
Update On dirait que fragment de hachage est protégé par le navigateur lorsqu'il est accédé depuis la page parent dans un domaine différent. Donc, je suppose que #access_token est sans danger. Ma faute. Tout comme une page de rappel, la page de rappel doit stocker le jeton d'accès de son propre chef, au lieu de (mon intention initiale) de le déléguer à la page parent comme window.parent.storeAccessToken(hash);, ce qui est évidemment une chose stupide à faire.
À partir du site Web OAuth0 :
Si vous devez authentifier vos utilisateurs sans page de connexion (par exemple, lorsque l'utilisateur est déjà connecté via un scénario SSO) ou obtenir un nouveau code d'accès (ainsi simuler l'actualisation d'un jeton expiré), vous pouvez utiliser l'authentification silencieuse.
Quant à la Authentification silencieuse :
Cependant, rediriger les utilisateurs hors de votre application est généralement considéré comme perturbateur et doit être évité du point de vue de l'expérience utilisateur. L'authentification silencieuse vous permet d'effectuer un flux d'authentification où Auth0 ne répondra qu'avec des redirections et jamais avec une page de connexion.
Cela vous permettra de reconnecter l'utilisateur à l'aide d'un jeton SSO, sans avoir à lui demander à nouveau ses informations d'identification.