为什么缓存访问令牌在oauth2中被认为是坏的?

时间:2017-11-21 12:18:29

标签: c# asp.net-web-api oauth-2.0 token owin

我正在关注此文章以撤消用户访问权限:

http://bitoftech.net/2014/07/16/enable-oauth-refresh-tokens-angularjs-app-using-asp-net-web-api-2-owin/

现在考虑验证用户后我已经发出了一个30分钟的生命周期的accessstoken,如上文所示,并且刷新令牌为1天,但是如果管理员在10分钟内删除该用户,但仍有20分钟的时间,那么现在就是这种情况我需要撤销该用户的访问权限。

为了做到这一点,我需要从刷新令牌表中删除该用户条目以禁止进一步的访问令牌请求,但由于accessstoken到期时间仍然是20分钟,因此用户将能够访问完全错误的受保护资源。 / p>

所以我想实现缓存机制缓存服务器上的访问令牌并保存在数据库中。因此,当该用户被撤销时,我可以简单地从缓存和数据库中删除该用户条目,以阻止该用户访问访问受保护资源。

但是下面的两个答案说这不是oauth2的设计方式:

Revoke access token of OAuthBearerAuthentication

OAuth2 - unnecessary complexity with refresh token

所以我的问题是:

1)为什么缓存访问令牌不被认为比刷新令牌机制更好,也是一种糟糕的方法?

我的第二个问题是基于 @Hans Z。给出的以下答案:

  

这必然会涉及资源服务器(RS)咨询   授权服务器(AS),这是一个巨大的开销。

2)如果撤消用户的访问权限,为什么RS会咨询AS,因为AS仅用于验证用户并按照此Article生成访问令牌?

3)在文章中只有2个项目:

  • Authentication.api - 验证用户并生成访问令牌
  • 资源服务器 - 借助[Authorize]属性

    验证accessstoken

    在上述情况下,授权服务器呢?

更新:我决定使用刷新令牌撤消用户访问以防用户被删除,并且当用户注销时我将刷新令牌来刷新令牌表,因为您要求我们注销用户点击退出后立即立即使用。

但是这里的问题是我有250个与用户相关的角色,所以如果我把角色放在accesstoken中那么accessstoken的大小将是如此巨大而我们无法从头文件中传递如此巨大的accessstoken 但是我无法查询每次调用该端点时验证端点用户访问权限的角色。

所以这是我面临的另一个问题。

3 个答案:

答案 0 :(得分:0)

我希望我的问题是正确的,可以提供一些答案:

1)如果您开发AS需要在每次用户登录时进行验证,您都可以兑现。

2)我认为@Hans Z.意味着由AS撤销用户。当RS撤销用户时,它不会改变它们仍然是AS标识的事实。但是当AS撤销用户时,它会阻止他们使用他们的身份。

3)文章可能假设授权由RS完成,AS只负责告诉您谁是用户,RS将根据该决定授权。

答案 1 :(得分:0)

刷新令牌方法的主要优点是减少数据库查询的数量,访问令牌具有声明并签名,因此可以信任令牌而无需查询数据库。

缓存访问令牌将起作用,但您必须在每个请求上查询缓存。

这是一个权衡,您必须在访问权限更改延迟n分钟与检查访问令牌有效性的查询数量之间做出选择

由于增加了复杂性,您几乎可以实现这两种情况,在这种情况下,您必须将缓存存储在服务器RAM中,并且仅存储已撤销的令牌以使列表保持较小。如果您有多个服务器实例,则必须保持撤销令牌的缓存在RS和AS之间保持同步。

基本上,当撤销访问令牌时,AS必须通知所有RS将该访问令牌添加到撤销的令牌缓存。

每当有资源请求时,RS将检查令牌是否被撤销,如果没有撤销,则RS服务器资源。这样,每个请求都会产生开销,但随着缓存在内存中,它会大大减少,并且与有效令牌的数量相比,撤销令牌的数量将会非常少。

答案 2 :(得分:0)

“授权服务器可以与资源服务器是同一服务器,也可以是单独的实体。” [RFC 6749,第6]

话虽如此,您可以缓存这种情况,但是令牌应该是资源服务器可以理解的,不需要缓存。如果那是实现的细节,那么可以进行缓存,但不是必需的。