让我们考虑一下这个用例：
1）我使用用户名和密码调用我的API登录端点，并获取我添加到标题Authorization: Bearer <token>的每个连续请求的Auth令牌。
2）我调用/current-user端点没有参数，只有Authorization标头。服务器使用令牌授权用户并从该令牌获取用户的ID。然后他通过数据库中的id找到用户并返回它的数据。
我的问题是，这种方法是否不安全。我想知道，如果我是攻击者并使用随机生成的令牌调用/current-user端点该怎么办？ 。一旦我偶尔匹配真实令牌，服务器就会返回其他用户的数据。
是否有必要在客户端上存储用户ID以及使用两者的令牌和呼叫请求？例如。 /user?id=<stored user id>使用Authorization标头并删除/current-user端点？之后，服务器上的某种ACL将确定，使用的令牌是否允许访问具有传递的用户ID的用户。
（我也发现有JWT令牌，但我在那里看到同样的问题。作为攻击者，我会以某种方式设法猜测其他用户的令牌和服务器会将我的数据返回给我）
答案 0 :(得分：1)
出于安全考虑，通常假设攻击者无论如何都知道用户ID。例如，如果攻击者已拥有或知道合法帐户，则她可能会猜测其他用户ID的分配方式。
此外，如果您的令牌足够长并且完全随机，那么它并没有什么不同。
以这种方式看待：假设您的令牌长度为n，您的用户ID的长度为m。如果没有用户ID，攻击者必须猜测n个字符，其中包括她必须猜测n+m个字符。如果您的n足够高，则不需要这些额外的字符。请注意，如果您的用户ID不是完全随机的，那么用户ID的有效长度可能比其表观长度短得多，因此添加的m实际上可能确实是小。
答案 1 :(得分：1)
您是否可以使用数字签名的令牌？您基本上可以使用客户端（或用户）的私钥加密令牌，然后使用服务器的公钥再次使用明文用户ID加密包。这样只有服务器可以解密包，一旦解密，它就知道用户是谁。然后，它可以使用与该用户标识关联的公钥来解密到包并获取令牌。
由于您没有提供有关应用程序和所需身份验证速度或您正在使用的技术的大量信息，因此很难再提供更多信息。