我正在设计一个授权服务，该服务将在请求中收到Authorization标头的其他公共服务内部查询。
此服务处理授权（一对公钥（user_id）和私钥），其任务是重新生成签名（HMAC） - 唯一知道私钥的服务 - 所以对我来说似乎是对的将此标识为服务器资源。然后我认为没有用户就没有授权资源，所以我最终得到了这个基本URI：
/user/:user_id/authorization
然后我设计了CRUD操作来处理授权，在创建新用户时创建，在请求时更新，在删除用户时读取和删除。
注意：User实体由另一个服务处理，我只使用此URI以逻辑方式传递公钥（因为它与用户严格相关）。
我不确定如何从其他服务中查询此服务说：“嘿，这个关键是对的吗？”将此请求传递给重新生成签名所需的所有数据。
所以我需要的是一种以宁静的方式检查授权的方法
我做过类似的事情：
GET /user/:user_id/authorization?signature=SOMETHING&data=JSON-DATA-TO-REGENERATE-KEY
但也许，我们也可以看到它创建一个新的授权资源（如果没有返回任何内容，它也不是令牌系统），从而使PUT或POST更适合此目的。
你的观点是什么？处理这种情况的正确方法是什么？
答案 0 :(得分：1)
GET / user /：user_id / authorization？signature = SOMETHING＆amp; data = JSON-DATA-TO-REGENERATE-KEY
永远不要忘记GET方法应该是'safe'。它不应“具有采取除检索以外的行动的意义”。换句话说，客户“不应该要求副作用”。
答案 1 :(得分：1)
就我个人而言，我认为获得会话/用户/初始授权（登录）应该是一个POST，因为它（假设）确实会创建一些新东西：一些授权令牌。
后续授权验证请求应为GET。它们不会创建任何新内容，并且基本上返回一个布尔值（尽管通过响应代码）来指示授权标头是否有效。
答案 2 :(得分：0)
此服务处理授权（一对公钥（user_id）和私钥）
您是否存储私钥服务器端？您是否在同一服务上处理授权和身份验证？
我个人更喜欢像WebID这样的架构。参见：