vertx用户授权主体或属性

Question

我在API上使用Vertx框架对JWT令牌进行授权。在用户被授权并且令牌被解密之后，我想要访问令牌的内容，尤其是令牌中的“userId”字段。

最初，我是用req作为RoutingContext作为以下内容来访问它的：

req。user（）。主体（）。getString（“用户ID”）

在另一台机器上编译之前，它一直按预期工作。在另一台机器上编译时req。user（）。principal（）仅包含字段access_token，其中包含仍然加密的JWT。

解决方法是通过

req。user（）。属性（）。getJsonObject（“accessToken”）。getString（“用户ID”）

我已经在4台不同的机器上测试过了。其中两个使用principal，另外两个需要属性。它似乎只是在哪台机器上编译，而不是在什么机器上运行。代码没有在机器之间更改。Java、Maven和Vertx版本每次都是相同的。

我在网上找到的一些解决方案只是检查所需的字段是否在主体中，以及是否不使用属性。不过，这似乎是一个糟糕的变通方法。必须有一个合适的方法来访问它。

访问解码令牌中的值的正确方式是什么？为什么它似乎会随着编译机器的不同而变化？




Answer 1

在vert. x3. x中，令牌总是被解码为JSON对象，该对象将是主体。在vert. x 4中，已经在auth n/z区域做了很多工作，所以经验法则是：

• 主体包含允许创建此用户对象的“源”属性
• 属性包含身份验证n/z过程中解码/生成的属性

因此，如果您使用vert，您应该期望解码的令牌始终处于attributes状态。x4。最近的一次提交将这些属性添加回JWT auth的主体，以保持向后兼容。

细节：令牌现在没有解码到主体的原因是用户对象与身份验证提供程序分离。因此，即使用户是从JWTAuth创建的，它也可以被OAuth2Auth使用。因此，内部结构需要保持一致。其次，带有OpenID Connect的Oauth2也使用令牌，但有几种令牌：

1. 访问\u令牌
2. id\u令牌

将这些标记解码给委托人意味着，在某些情况下，属性可能会重叠。这些重叠之一是与令牌的到期/有效性相关的属性。在某些情况下，使整个用户验证处于错误状态。

最后，我们现在可以将vertx auth用于服务器端auth n/z，也可以用于客户端auth。这意味着我们需要保留原始令牌（它是主体），以便在不篡改客户端请求的情况下快速添加它，以便“代表”执行身份验证。