使用承载令牌进行身份验证(≠授权)

Question

使用该请求的请求Authorization: bearer [token]可用于身份验证吗？

要么

我们应该使用另一种方法来验证客户端并发出令牌,然后将令牌用作OAuth2的持票令牌吗？为什么流行的Web服务(例如Github,AWS,Google ..)使用其他方法(如AWS所做的:) Authorization: AWS4-HMAC-SHA256 Credential=...来验证客户端.问题的关键是:在以下流程中是否存在任何可贬值或违反标准的情况.

我想使用以下流程:

the client:这就像Twitter客户端.
the server:这就像Twitter API.

1. 客户端生成令牌(加密的用户ID,密码等).
2. 客户端向服务器请求资源Authorization: bearer [token].
3. 服务器解密令牌并验证客户端.
4. 服务器响应资源.

我阅读了以下RFC,但我没有找到任何理由,为什么我不应该或应该使用上面的流程.

https://tools.ietf.org/html/rfc7235
https://tools.ietf.org/html/rfc6750

谢谢

Answer 1

我建议坚持使用OAuth2规范.如果要使用用户名和密码来获取令牌,则应使用"客户端凭据"流.这意味着您需要一个"https"端点,用户可以通过以下POST请求获取访问令牌:

POST /token HTTP/1.1
Authorization: Basic base64_encode("username:password")
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials

如果客户端凭据有效,则端点应在服务器上创建访问令牌.除了令牌,你应该存储获得令牌的人和令牌到期时的时间戳.因此,令牌不应该像您的示例中那样加密用户名和密码,而应该是分配给用户的随机字符串.

然后,客户端可以使用访问令牌来访问API的受保护部分.如果您的API收到了持有人令牌,您可以在令牌表中查找已分配的用户.

在OAuth2中,您通常会通过API提供商先前获得的应用密钥和密钥获得访问令牌.这具有以下优点:用户不需要与第三方应用共享任何凭证.但是否需要这取决于您的用例.