隐藏来自JWT令牌的内部用户ID

Question

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

当用户从客户端应用程序登录时，他获得JWT令牌，该令牌包含具有用户ID值的“子”部分。 然后，当用户调用API方法之一时，他仅提供JWT令牌，因此API从“子”获取用户ID，并向适当的表发出搜索请求。 因为每个表都有user_id列，所以在SQL查询中不需要在User表上进行联接（如果响应中不需要用户信息）。

问题在于，公开内部用户ID是一种不好的做法，可能会导致安全/业务问题。 因此，我正在寻找隐藏它的方法。 现在，我看到以下选项：

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

• 具有附加ext_user_id列（GUID）的现存用户表，并在JWT令牌中使用此值。 不利之处在于，每个SQL查询都将“联接”到User表以获得用户ID值。

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

也许还有其他选择？ 还是其中一种方法比其他方法（实际上除了第一种方法）更具优势？

Answer 1

基本上，我认为这些是您的选择。

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

JWE解密时间将始终基本相同，使用对称密钥可能需要几毫秒的处理器时间。 但是，数据库查询对象需要磁盘访问，并且取决于其他因素：记录数，联接数，磁盘访问时间等。如果不详细了解问题，就不可能给出绝对的衡量标准。 我建议您凭经验衡量每个案例的开销，并评估这是否对您有问题

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

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

例如，如果您有使用该ID的资源，例如

/user/{userId}/getSomeData

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

您是否需要客户端解码JWT？

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

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

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