撤销OAuthBearerAuthentication的访问令牌 [英] Revoke access token of OAuthBearerAuthentication

问题描述

我已经设置了Web API的身份验证，该身份验证与此处的本博客几乎相同

I've set up the authentication for Web API which is almost identical to this blog here oauth-refresh-tokens from Taiseer Joudeh.

在我遇到一个问题之前，它工作得很好:

It worked perfectly until I met an issue:

• 我们有用户A和用户B当前登录到系统.
• 用户A作为管理员，将用户B从系统中删除.
• 用户B仍然有权访问网络，直到 令牌 已过期.

我已经做过一些研究，他们都说，撤销访问令牌非常困难(或者在OAuth中是不可能的).我唯一能做的就是将超时时间设置得更短.它仍然在我的脑海中出现故障，我不喜欢访问令牌在之后的一段时间内仍然有效(尽管是有限的)的想法.

I've done some research and they all said that revoking an access token is quite difficult (or not possible in OAuth). The only thing I could do is to set the timeout shorter. It's still glitching in my mind and I do not like the idea that access token is still valid to (although a limited) frame of time after.

因此，有没有更好的方法或任何建议，将不胜感激.

So, is there any better approach or any advice would be much appreciated.

推荐答案

使用设计时已使用的 refresh_token 和 access_token 并将访问令牌的寿命缩短至持续时间对您来说是可以接受的，并且可以根据需要降低.由于您既是资源服务器又是授权服务器，因此渐进线意味着您将无论如何都要检查每个呼叫的用户，如其他答案中所建议的那样，但是:

Use the refresh_token and access_token as they were designed and shorten the lifetime of the access token to a duration that is acceptable for you and go as low as you need to go. Since you're both the Resource Server and Authorization Server, the asymptote means that you'll end up checking the user on every call anyhow, as suggested in the other answers, but:

使用数据库存储访问令牌很可能会导致缓存令牌以优化性能，在这种情况下，您最终会遇到与刷新令牌相同的情况，其中刷新过期时间等于访问令牌的生存期.

using a DB to store access tokens will most probably lead to caching tokens to optimize performance, in which case you end up in the same situation as with refresh token where the cache staleness timeout is equivalent of the access token lifetime.

最后，您不能再吃蛋糕了，所以我建议按照OAuth的设计去做.

In the end you can't have your cake and eat it too, so I would recommend to do it as OAuth was designed to do.

这篇关于撤销OAuthBearerAuthentication的访问令牌的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！