在OAuth2隐式授权中处理过期的访问令牌

Question

OAuth2的规范规定授权服务器在使用隐式授权时不得发出刷新令牌.在我们的用例中,我们使用OAuth2保护RESTful API,并使用单页Javascript应用程序作为此API的客户端.由于在访问令牌过期后重定向到授权服务器非常困难,我们正在寻找更好的方法来获取新的有效令牌.我可以考虑两种不同的方法,并想知道哪一种可能更好:

1. 使用隐藏的iframe重新请求有效的访问令牌.为此,必须包含一个参数,例如"prompt = none",它告诉OAuth提供者既不挑战认证,也不显示授权页面.如果用户已通过身份验证并已授权应用程序,则服务器将在URL#parameters中发回访问令牌.如果未满足上述条件之一,它将重定向,并出现错误,如#error = authentication%20lost.通过这种行为,我们可以使用具有隐式流的短期访问令牌.

2. 我们可以使用一个额外的范围(例如离线)来告诉服务器分发刷新令牌.即使原始规范说隐式流不会发出刷新令牌(如果客户端仅将OAuth用于第一次授权,这是正确的),您可以自由地为您的特定应用程序定义自己的作用域.您应该考虑仅允许来自知名客户端的此范围.

这两种方法都与OpenID Connect非常相似.不幸的是,目前OpenID Connect的实现并不多.因此,第一步是扩展OAuth2服务器,直到OIC更受欢迎.

那么哪种方法应该首选？

编辑:令牌端点需要客户端身份验证,这仅适用于机密客户端,如服务器端应用程序.使用第二种方法,只有在我们的情况下,RESTful API才能使资源提供者刷新令牌并将其发送回客户端.我认为这会带来安全风险.所以我们可能只有一种有效的方法.

Answer 1

我现在正在努力实现完全相同的目标。

我实际上已经实现了隐藏 iframe方法，然后意识到您必须非常小心使用 iframe。如果您不指定X-Frame-Options ，任何恶意网站都可以包含您的 iframe 并轻松获取访问令牌。

刷新令牌的最佳方法应该是按照规范指定的密码授予。（我希望我的用户使用他们的 Facebook 帐户登录，并且隐式流程更容易开发。我还没有完全弄清楚如何通过密码授予来做到这一点。）

我也想到了第二种方法，对我来说似乎比第一种方法安全得多，因为您通常可以信任https和浏览器存储来保密您的令牌。

编辑

我意识到，即使X-Frame-Options大多数浏览器也无法阻止重定向，因为此标头附加到响应正文，并且重定向的 URL 将被公开，因此访问令牌会被公开。

更新 看起来当从不同域中的父页面访问时，哈希片段受到浏览器的保护。所以我认为#access_token是安全的。我的错。正如提醒回调页面必须自行存储访问令牌一样，而不是（我的初衷）将其委托给父页面，window.parent.storeAccessToken(hash);这显然是一件愚蠢的事情。