可以将访问令牌缓存到资源服务器上(短时间内),即使它可能会过期。

huangapple go评论110阅读模式
英文:

Is it generally possible to cache an access token on a resource server (for a short time), even if it may expire?

问题

在资源服务器上缓存访问令牌通常是可能的,即使它可能会过期。在这种情况下,没有其他资源服务器参与,令牌仅用于本地操作(在服务器上),例如数据库持久化。

根据我的IP,我必须至少缓存访问令牌5分钟。同时,它只有效期30分钟。如果用户在访问令牌即将过期时(例如在第29分钟59秒之前)访问后端,那么无效的令牌会被缓存,可能会在另外5分钟内使用。对我来说,这没问题,因为只是几分钟,我只需要用户上下文。但从技术角度来看,这会有什么问题吗?

IP:OAuth 2.0

前端:Angular应用将访问令牌发送到后端

后端:.Net Core解决方案,使用令牌检查来验证令牌并获取用户上下文

英文:

Is it generally possible to cache an access token on a resource server, even if it may expire? There are no other resource servers involved and the token is only used for local operations (on the server) such as database persistence.

I have to cache the Access Token for at least 5 minutes (according to my IP). At the same time, it is only valid for 30 minutes. If a user goes to the backend just before the access token expires (e.g. in minute 29:59), the invalid token is cached and potentially used for another 5 minutes. For me it's okay because it's only some minutes and I just need the user context. But is this any problem from a technical point of view?

IP: OAuth 2.0

Frontend: Angular app sends the access token to the backend

Backend: .Net Core solution, uses token introspection to validate the token and get the user context

答案1

得分: 1

当使用内省时,通常会缓存内省结果,以避免在每个 API 请求时调用授权服务器。

内省通常与引用令牌一起使用,这些令牌不像 JWT 那样可读,也不向互联网客户端透露任何敏感数据。通常,API 网关可以执行内省并维护缓存。

大多数缓存支持为每个项设置生存时间。此时间不应超过内省响应中的 exp 声明的值。然后,将内省结果存储在访问令牌的哈希值(例如 SHA256)下。

Angular 应用程序应在每个 API 请求上发送令牌。如果 Angular 应用程序未发送哈希与缓存中的令牌匹配的令牌,或者内省失败,将拒绝该调用并返回 401 错误。

JWT 响应

在支持时,更完整的安全选项是让网关使用不同的接受标头进行内省,以接收 JWT 响应。然后可以将 JWT 访问令牌转发给 API。然后,API 在每个请求上验证 JWT。有关内省差异的详细信息,请参阅JWT 响应模式规范。

此方法确保在每个请求上进行安全验证,特别是在微服务将访问令牌相互转发的用例中。然后,每个 API 中的 JWT 验证有助于防止网络内的恶意请求。

过期

当访问令牌过期或由于其他原因未通过内省(例如,令牌已被吊销)时,API 应返回 401 错误。然后,Angular 客户端必须尝试刷新令牌并重试 API 请求。如果刷新失败,客户端应将用户重定向以重新进行身份验证。

英文:

INTROSPECTION AND RESULT CACHING

When introspection is used, it is standard to cache the introspection results, to avoid calling the authorization server on every API request.

Introspection is often used with reference tokens, which are not readable like JWTs, and do not reveal any sensitive data to internet clients. Often an API gateway can do the introspection and maintain the cache.

Most caches support a time to live for each item. This should be set to a value that does not exceed the exp claim of the introspection response. The introspection results are then stored against a hash (eg SHA256) of the access token.

The Angular app should send the token on every API request. If the Angular app does not send a token whose hash matches one in the cache, or if introspection fails, the call is rejected with a 401 error.

JWT RESPONSE

A more complete security option, when supported, is for a gateway to do introspection with a different accept header, to receive a JWT response. The JWT access token can then be forwarded to the API. The API then validates the JWT on every request. Introspection differences are described in the JWT Response Mode specification.

This method ensures secure verification on every request, especially in use cases where microservices forward the access token to each other. The JWT validation in each API then helps to protect against malicious requests inside the network.

EXPIRY

When the access token expires, or fails introspection for other reasons, eg the token has been revoked, a 401 error should be returned from the API. The Angular client must then try to refresh the token and retry the API request. If this fails, the client should redirect the user to re-authenticate.

huangapple
  • 本文由 发表于 2023年5月17日 17:38:38
  • 转载请务必保留本文链接:https://go.coder-hub.com/76270653.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定