在OAUTH中保护REST API的一般想法是使用授权承载＆lt; access token＆gt;标题，通常是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。
答案 0 :(得分：2)
IMO您的REST API应该是独立的授权框架。
虽然在您的情况下，用户u1无法访问来自用户u2的汽车或船只，但这可能不适用于所有用户。
您可以轻松想象一个管理员用户或其他可以访问任何（或特定子集）用户的汽车和船只的角色。
所以，我会说那个
GET /users/:u1/cars/
HTTP 200 OK的汽车，应以u1回复并返回用户u1的所有汽车。否则，它应以HTTP 403 Forbidden回复。
因此，换句话说，使用JWT令牌中的信息来授权操作。不要将您的API设计更改为从中隐式推断用户上下文。