0

我在我的 API 上使用 Vertx 框架来授权 JWT 令牌。在用户获得授权并解密令牌后，我想访问令牌的内容，特别是令牌中的“userId”字段。

最初我使用reqas访问它RoutingContext：

req.user().principal().getString("userId");

这会按预期工作，直到它在不同的机器上编译。当在不同的机器上编译时，req.user().principal()只包含字段access_token，包含仍然加密的 JWT。

解决方案是通过以下方式访问用户 ID

req.user().attributes().getJsonObject("accessToken").getString("userId");

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

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

访问解码令牌中的值的正确方法是什么？为什么它似乎会根据编译机而改变？

4

1 回答 1

1

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

  • principal包含允许创建此User对象的“源”属性。
  • attributes包含在 auth n/z 过程中解码/生成的属性。

因此，如果您使用 vert.x 4，您应该期望解码后的令牌始终处于打开attributes状态。最近的提交将这些属性添加回了principalfor JWT 身份验证，以使其向后兼容。

详细信息：令牌现在没有解码为 的principal原因是因为User对象与身份验证提供程序分离。所以即使 aUser是从它创建的，JWTAuth它也可以被OAuth2Auth. 所以内部结构需要保持一致。其次，带有 OpenID Connect 的 Oauth2 也使用令牌，但令牌有以下几种：

  1. access_token
  2. id_token

将这些令牌解码为主体意味着，在某些情况下，属性可能会重叠。这些重叠之一是与令牌的到期/有效性相关的属性。在某些情况下使整个User验证处于错误状态。

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

于 2020-11-10T10:41:45.277 回答