不记名令牌变得太大

Posted 2023-02-19

【中文标题】不记名令牌变得太大

【英文标题】：Bearer token getting too big

【发布时间】：2017-01-20 19:42:24

【问题描述】：

在我正在构建的应用程序中，我们使用 JWT 令牌作为 OAuth Bearer 令牌。

假设我们有一个名为things 的资源集合，可通过thing ID 寻址，例如。 things/1、things/44等

目前，每当有人请求范围为things 的访问令牌时，我们都会列出用户对每个things 拥有的所有权利列表：

   "sub": "Romeo",
   "scope": [ "things" ],
   "things": 
     "1": [ "read", "write", "delete" ],
     "44": [ "read", "write"],
   
  // ...

这很好用，但是当用户有很多 things 时，事情就会变糟。因为所有权限都编码在 JWT 令牌中，所以对于用户拥有的每个thing，令牌都会变得更大。

这是不可扩展的，我需要为此找到解决方案。我可以一次将令牌范围限定为属于单个thing，但随后管理的客户端的令牌管理就变成了地狱（我需要一个可以列出令牌并需要保留的令牌每个thing 一个令牌）。

我无法摆脱 Bearer 令牌，因为我们的某些组件由于多种原因无法与令牌发行者通信。

有解决这个问题的标准方法吗？我正在考虑使具有things 范围的令牌可互换，因此我可以将其中仅包含things 一部分的受限令牌交换为其中包含things 其他部分的其他令牌。

【问题讨论】：

您找到解决此问题的方法了吗？

【参考方案1】：

该信息不一定需要在令牌中。只要令牌包含对用户的引用，资源服务器就可以查找某些后端服务/数据库以检索与当时正在请求的资源准确关联的相应权限。

该服务不需要是授权服务器本身；它也可以是数据库或任何类型的后端系统（可能与授权服务器通信的系统相同）。

【讨论】：

是的，但这会破坏不记名令牌的使用，不是吗？这个想法是客户端根本不需要与我们的资源服务器对话。

您正在将承载与 JWT 和 RS 与 AS 混合

你能解释一下RS和AS是什么意思吗？您是说包含令牌本身具有的访问权限的 accessTokens 没有用例？

我实际上仍然遇到这个问题。我们使用 Bearer 令牌的原因是我们不想在验证令牌时与我们的授权服务器（或其数据库）对话，因为这会在 AS 上造成单点故障。

承载！= JWT。不记名令牌并不意味着它是独立的，它只是意味着任何出示该令牌的人都可以访问。您可能的意思是您不想摆脱 JWT 令牌。然后你必须处理大小限制。

【参考方案2】：

我认为@hans-z 是正确的。 oAuth 不会为您解决这个问题。

当您遇到困难时，我建议您实现一个 User-Service，其中可以使用 JWT 令牌请求“things”。

为了推迟痛苦障碍，您可以考虑更改为 JSON Web Tokens 或其他支持令牌压缩的实现，或者在通过网络发送时使用 protobuf 重新编码令牌。