6

我正在设计一个授权服务，其他公共服务将在内部查询该服务，这些公共服务正在接收Authorization请求中的标头。

该服务处理授权（一对公钥（user_id）和私钥），它的任务是重新生成签名（HMAC）-它是唯一知道私钥的服务-，所以我认为识别这个是正确的作为服务器资源。然后我认为没有用户就没有授权资源，所以我最终得到了这个基本 URI：

/user/:user_id/authorization

然后我设计了 CRUD 操作来处理授权，在创建新用户时创建，在请求时更新，在删除用户时读取和删除。

注意：用户实体由另一个服务处理，我仅使用此 URI 以逻辑方式传递公钥（因为它与用户严格相关）。

我不确定我应该如何从其他服务中查询此服务以说：“嘿，这个键对吗？” 与此请求一起传递重新生成签名所需的所有数据。

所以我需要的是一种以宁静的方式检查授权的方法

我已经坚持了这样的事情：

GET /user/:user_id/authorization?signature=SOMETHING&data=JSON-DATA-TO-REGENERATE-KEY

但也许，我们也可以看到它正在创建一个新的授权资源（如果没有返回，它不是令牌系统），从而使 PUT 或 POST 更适合此目的。

你的观点是什么？处理这种情况的正确方法是什么？

4

3 回答 3

1

GET /user/:user_id/authorization?signature=SOMETHING&data=JSON-DATA-TO-REGENERATE-KEY

永远不要忘记 GET 方法应该是“安全的”。它不应该“具有采取检索以外的行动的意义”。换句话说，客户“不应该请求副作用”。

于 2012-11-03T06:51:17.760 回答
1

就我个人而言，我认为获取会话/用户/任何内容的初始授权（登录）应该是一个 POST，因为它（大概）确实创建了一些新的东西：一些授权令牌。

后续的授权验证请求应该是 GET。它们不会创建任何新内容，并且基本上返回一个布尔值（尽管通过响应代码）来指示授权标头是否有效。

于 2012-11-03T10:37:53.520 回答
0

This service handles the authorization (a pair of public key (user_id) and private key)

Are you storing the private key server-side? And are you handling authorization and authentication on the same service?

I would personally prefer an architecture like WebID. See:

于 2012-11-03T06:44:04.190 回答