在 OAuth2 隐式授权中处理过期的访问令牌 [英] Dealing with expired access tokens in OAuth2 implicit grant

问题描述

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

The specification of OAuth2 states that an authorization server must not issue a refresh token when using implicit grant. In our use case we protect a RESTful API with OAuth2 and use a Single Page Javascript application as a client for this API. As it would be very difficult to redirect to the authorization server after an access token has expired, we are searching for a better way to get a new valid token. I could think about two different approaches and wonder which one could be better:

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

1. Use a hidden iframe to Rerequest a valid access token. For this it is necessary to include a parameter like "prompt=none" which tells the OAuth provider neither to challenge authentication, nor to display an authorization page. If the user is authenticated and has authorized the application the server will send back an access token in the urls # parameters. If one of the previous conditions is not fulfilled, it will redirect with an error like #error=authentication%20lost. With this behaviour we can use short lived access tokens also with an implicit flow.

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

We could use an additional scope (e.g. offline) which tells the server to hand out a refresh token. Even if the original spec says that implicit flow does not issue refresh tokens (which is correct if the client only uses OAuth it for a first authorization) you are free to define your own scopes for your particular application. You should consider to only allow this scope from well-known clients.

这两种方法都与 OpenID Connect 的方法非常相似.不幸的是，目前 OpenID Connect 的实现并不多.所以第一步是扩展 OAuth2 服务器，直到 OIC 变得更流行.

Both approaches are very similar to those of OpenID Connect. Unfortunately there are not many implementations of OpenID Connect at the moment. So first step would be to extend the OAuth2 server until OIC will be more popular.

那么应该首选哪种方法?

So which approach should be preferred?

EDIT:令牌端点需要客户端身份验证，这仅适用于服务器端应用程序等机密客户端.使用第二种方法，在我们的例子中，只能让 RESTful API 资源提供者刷新令牌并将其发送回客户端.我认为这将是一个安全风险.所以可能我们只有一种有效的方法.

EDIT: The token endpoint needs client authentication, which is only possible for confidential clients like server-side applications. With the second approach it would only be possible to let the RESTful API in our case the resource provider to refresh the token and send it back to the client. I think this would be a security risk. So probably we have only one valid approach.

推荐答案

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

I'm trying to achieve the exact same thing at the moment.

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

I've actually implemented hidden iframe approach and then realized you have to be very careful with iframes. Any malicious website can contain your iframe and get access token easily if you don't specify X-Frame-Options.

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

Best approach for refreshing token should be password grant as specified by the spec. (I wanted my users to login with their facebook account & implicit flow was easier to develop this. I have not quite figured out how to do this with password grant.)

第二种方法也出现在我的脑海中，对我来说似乎比第一种更安全，因为您通常可以信任 https &浏览器存储，让您的令牌保密.

2nd approach also came accross my mind and seems much safer than the 1st to me, since you can usually trust the https & browser storage to keep your tokens secret.

编辑

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

I realized, even with X-Frame-Options most browsers can't prevent redirects, because this header is attached to the response body and redirected URL will be exposed, therefore access tokens exposed.

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

Update Looks like hash fragment is protected by the browser when accessed from the parent page within different domain. So I assume #access_token is safe. My bad. Just as a reminder callback page has to store the access token in its own right, instead of (my original intention) delegating it to the parent page like window.parent.storeAccessToken(hash); which obviously is a dumb thing to do.

这篇关于在 OAuth2 隐式授权中处理过期的访问令牌的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！