使用不记名令牌进行身份验证（≠ 授权）

Question

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

或

我们是否应该使用另一种方法来验证客户端并颁发令牌，然后像 OAuth2 那样将令牌用作不记名令牌？ 为什么流行的网络服务（例如 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://www.rfc-editor.org/rfc/rfc7235
https://www.rfc-editor.org/rfc/rfc6750

谢谢

Answer 1

不应将来自 OAuth2 服务器的不记名令牌用作直接身份验证方式。它们不代表最终用户，而是代表客户端必须代表该用户行事的授权。 Their article 解释清楚原因。

如果你想实现自己的认证服务器，你可以使用 OpenID Connect。它是建立在 OAuth 2.0 之上的标准。 OIDC 以确保身份验证的方式利用不记名令牌。

他们有一个list of certified libraries，您可以使用它来实现您的服务器。或者您可以利用许多 prexsiting IODC providers

之一

Answer 2

为什么流行的网络服务（例如 Github、AWS、Google..）使用其他方法（如 AWS 所做的：授权：AWS4-HMAC-SHA256 Credential=...) 来验证客户端。

AWS 签名标头不仅基于客户端凭据，还包括从请求本身派生的位以及当前时间。最终效果是不仅验证了客户端身份，还验证了请求内容，因此有人将无法在 another 请求上使用签名（或在运行中修改请求），即使他们设法以某种方式获得了签名。包括当前时间使签名仅在有限的时间内有效，减轻replay attacks。

Answer 3

我会建议坚持 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 提供者之前获得的应用程序密钥和秘密获得访问令牌。这样做的好处是用户不需要与第 3 方应用程序共享任何凭据。但是否需要这取决于您的用例。