OAuth2的规范规定授权服务器在使用隐式授权时不得发出刷新令牌。在我们的用例中，我们使用OAuth2保护RESTful API，并使用单页Javascript应用程序作为此API的客户端。由于在访问令牌过期后重定向到授权服务器非常困难，我们正在寻找更好的方法来获取新的有效令牌。我可以考虑两种不同的方法，并想知道哪一方可能更好：
使用隐藏的iframe重新请求有效的访问令牌。为此，必须包含一个参数，例如“prompt = none”，它告诉OAuth提供者既不挑战认证，也不显示授权页面。如果用户已通过身份验证并已授权应用程序，则服务器将在URL＃parameters中发回访问令牌。如果未满足上述条件之一，它将重定向，并显示错误，如＃error = authentication％20lost。通过这种行为，我们可以使用短期访问令牌和隐式流程。
我们可以使用一个额外的范围（例如离线）来告诉服务器分发刷新令牌。即使原始规范说隐式流不会发出刷新令牌（如果客户端仅将OAuth用于第一次授权，这是正确的），您可以自由地为您的特定应用程序定义自己的作用域。您应该考虑仅允许来自知名客户的此范围。
这两种方法都与OpenID Connect非常相似。不幸的是，目前OpenID Connect的实现并不多。因此，第一步是扩展OAuth2服务器，直到OIC更受欢迎。
那么哪种方法应该首选？
编辑：令牌端点需要客户端身份验证，这仅适用于服务器端应用程序等机密客户端。使用第二种方法，只有在我们的情况下，RESTful API才能使资源提供者刷新令牌并将其发送回客户端。我认为这会带来安全风险。所以我们可能只有一种有效的方法。
答案 0 :(得分：3)
我正试图在目前完成同样的事情。
我实际上实现了隐藏的iframe 方法，然后意识到你必须非常小心iframe。如果您未指定 X-Frame-Options ，任何恶意网站都可以包含您的iframe并轻松获取访问令牌。
刷新令牌的最佳方法应该是规范指定的密码授予。 （我希望我的用户使用他们的Facebook帐户登录＆amp;隐式流程更容易开发这个。我还没有弄清楚如何使用密码授予来执行此操作。）
第二种方法也出现在我脑海中，看起来比第一种方法更安全，因为你通常可以信任 https ＆amp; 浏览器存储以保持您的令牌秘密。
修改
我意识到，即使使用X-Frame-Options，大多数浏览器也无法阻止重定向，因为此标头会附加到响应正文，并且会重定向重定向的URL，因此会暴露访问令牌。
<强>更新
当从不同域中的父页面访问时，看起来哈希片段受浏览器保护。所以我认为#access_token是安全的。我的错。正如提醒一样，回调页面必须以自己的方式存储访问令牌，而不是（我的初衷）将其委托给父页面，如window.parent.storeAccessToken(hash);，这显然是一件愚蠢的事情。
答案 1 :(得分：1)
如果您需要在没有登录页面的情况下对用户进行身份验证（例如，当用户已通过SSO方案登录时）或获取新的access_token（从而模拟刷新过期的令牌），则可以使用无提示身份验证。 / p>
但是，从用户体验的角度来看，将用户从应用程序中重定向通常被认为是破坏性的，应该避免使用。通过静默身份验证，您可以执行身份验证流程，其中Auth0仅使用重定向进行回复，而不会使用登录页面进行回复。
这将允许您使用SSO令牌注销用户，而无需再次提示他提供凭据。