从 JWT 令牌中隐藏内部用户 ID

Question

有一个正在开发的 REST API 服务，它为发出请求的用户提供通过内部 SQL 数据库的不同搜索方法。数据库包含多个表，每个表都有一个 user_id 列，该列是 User 表中 id 列的引用键（唯一整数，主键）。这个很重要。

当用户从客户端应用程序登录时，他会获取 JWT 令牌，其中包含带有用户 ID 值的“sub”部分。然后，当用户调用其中一种 API 方法时，他只需提供 JWT 令牌，因此 API 从“sub”获取用户 ID 并向相应的表发出搜索请求。由于每个表都有一个 user_id 列，因此不需要在 SQL 查询中对 User 表进行联接（如果我们在响应中不需要用户信息）。

问题是暴露内部用户 ID 是一种不好的做法，可能会导致安全/业务问题。所以我正在考虑隐藏它。现在我看到以下选项：

• 将用户 ID 更改为字符串列（使用顺序 GUID），但这对我们的系统来说是一个巨大的突破性更改

• 具有附加 ext_user_id 列 (GUID) 的现有用户表，并在 JWT 令牌中使用该值。缺点是之后每个 SQL 查询都会“连接”到 User 表以获取用户 id 值。

• 保留数据库不变，但使用 JWE 令牌而不是 JWT。缺点是每个API请求都会做token解密，这可能会影响性能。

也许还有另一种选择？或者这些方法中的一种是否比其他方法更有优势（实际上除了第一种方法）？

Answer 1

基本上我认为这些就是你的选择。

\n\n

您专注于性能。对于解决方案 2 和 3，您必须将获取用户 ID的 SQL 查询/连接的开销与JWE令牌的解密进行比较。

\n\n

JWE 解密时间始终基本相同，对称密钥可能需要几毫秒的处理器时间。然而，数据库查询需要磁盘访问并取决于其他因素：记录数、连接数、磁盘访问时间等。在不详细了解问题的情况下，不可能为您提供绝对的衡量标准。我建议您凭经验测量每个案例的开销并评估这对您来说是否是一个问题

\n\n

除了性能之外，我建议通过隐藏 ID 来评估附带问题：

\n\n

您是否需要客户端知道您的 REST API 中的 ID？

\n\n

例如，如果您有一个使用如下 ID 的资源\n\xc2\xa0\xc2\xa0

\n\n

/user/{userId}/getSomeData\n

\n\n

JWE 不会有用，因为您需要以任何方式提供标识符

\n\n

您需要客户端解码 JWT 吗？

\n\n

如果使用JWE，客户端无法解码，因为它没有解密密钥

\n\n

您需要在服务器中的多少个位置将 GUID 转换为 ID？

\n\n

您将需要对每个查询进行查询，或者在入口点的过滤器中进行一般转换查询

\n