问题描述
我正在API上使用Vertx框架进行JWT令牌授权。在授权用户并解密令牌后，我想访问令牌的内容，尤其是令牌内的“ userId”字段。
最初，我使用req作为RoutingContext来访问此文件：
req.user().principal().getString("userId");
这可以按预期工作，直到在其他计算机上编译为止。在另一台机器上编译时，req.user().principal()仅包含字段access_token，其中包含仍加密的JWT。
req.user().attributes().getJsonObject("accesstoken").getString("userId");
我已经在4台不同的计算机上对此进行了测试。其中2个使用主体，而另2个需要属性。看来，仅在编译所在的计算机上运行，而不是在什么计算机上运行。机器之间的代码未更改。 Java，Maven和Vertx版本每次都相同。
我在网上找到的一些解决方案只是检查所需字段是否为主体，以及是否不使用属性。但是，这似乎是一个错误的解决方法。必须有一种适当的方法来访问它。
访问已解码令牌中的值的正确方法是什么？为什么它似乎根据编译器而改变？
解决方法
在vert.x 3.x中，令牌始终被解码为JSON对象，而该对象将为principal。在vert.x 4中，在auth n / z区域上已经完成了很多工作，因此经验法则是：
-
principal包含允许创建此User对象的“源”属性。 -
attributes包含auth n / z过程中的解码/生成的属性。
因此，如果您使用的是vert.x 4，则应该期望解码的令牌始终位于attributes上。最近的一次提交将这些属性重新添加到principal中以进行JWT身份验证，以保持向后兼容。
详细信息：令牌现在未解码到principal的原因是因为User对象与auth提供程序分离。因此，即使从User创建了JWTAuth，OAuth2Auth也可以使用它。因此内部结构需要保持一致。其次，带有OpenID Connect的Oauth2也使用令牌，但是令牌有几种：
-
access_token -
id_token
将这些令牌解码为委托人意味着在某些情况下属性可能重叠。这些重叠之一将是与令牌的到期/有效性相关的属性。在某些情况下，使整个User验证处于错误状态。
最后，我们现在可以将vertx auth用于服务器端auth n / z，也可以用于客户端auth。这意味着我们需要保留原始的原始令牌（这是主体），以便我们可以快速添加它，而不会篡改客户端请求，以便“代表”执行身份验证。