在OAUTH中保护REST API的一般想法是使用Authorization Bearer <access token>标头，通常是JWT，它具有关于主题的信息，即。带有u1的sub: u1是数据库中的userId。
使用此类访问令牌，客户端应用程序可以访问不同的资源。让我们说一个用户有很多车，有很多船等...所以，在RESTful方式，/users返回所有用户，/users/:u1返回用户u1的数据，/users/:u1/cars/:c1返回用户c1的汽车u1的数据，/users/:u1/boats/:b1返回的数据用户b1的船u1等
我的问题是关于u1。不应该从JWT访问令牌中提取u1，因为我们知道我们可以信任JWT吗？从理论上讲，应用程序可以使用为用户u1发布的JWT，但是请求访问应该被禁止的/users/:u2。
可以使/users/:u1不可用，并强制客户端应用程序调用/users而从JWT中提取sub。但是，调用/users返回u1的数据会破坏RESTful模式及其好处（即http缓存）。
什么是正确的方法？
这可能是关于REST api问题的authorization框架。 JWT只能解决authentication问题。
IMO您的REST API应独立于您的授权框架。
虽然在您的情况下用户u1无法从用户u2访问汽车或船只是有道理的，但这可能不适用于所有用户。
您可以轻松地想象一个管理员用户或其他可以访问任何（或特定子集）用户的汽车和船只的角色。
所以，我会说
GET /users/:u1/cars/
如果用户有权为用户HTTP 200 OK检索车辆，则应使用u1回复并返回所有车辆用户u1。否则它应该回应HTTP 403 Forbidden。
换句话说，使用JWT令牌中的信息来授权操作。不要更改您的API设计以隐式地从中推断用户上下文。