使用承载令牌进行身份验证（≠授权）

Question

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

还是

我们应该使用另一种方法来验证客户端并发出令牌，然后像OAuth2一样使用令牌作为承载令牌吗？为什么流行的Web服务（例如Github、AWS、Google等）使用其他方法（例如AWS：Authorization: AWS4-HMAC-SHA256 Credential = ...）来验证客户端。问题的关键是：以下流程中是否存在任何漏洞或违反标准。

我想使用以下流程：

客户端：类似Twitter客户端。 服务器：类似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

谢谢

- sndyuk

---

1. 不确定你打算如何在客户端“生成”令牌？
2. 每个请求中是否会发送加密的用户名和密码？

- Vivek Athalye

1. 是的，每个客户端都会生成令牌。
2. 是的，就像基本身份验证一样。

- sndyuk

我只想说，我很佩服有人使用了不等于符号。赞！ - Jhecht

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提供者事先获取的应用程序密钥和密钥来获取访问令牌。这有一个优点，即用户不需要与第三方应用程序共享任何凭据。但是，是否需要这样取决于您的用例。

- Christoph Kappestein

---

谢谢，如果我想将身份验证方法与资源服务器分开，我会使用OAuth2。但我觉得OAuth2过度规范化了。 - sndyuk

如果您拥有一个典型的公司，那么服务器上的身份验证通常会被委派给LDAP服务器。因此，在这种情况下，您已经有了3个参与方（客户端、服务器、身份验证服务器LDAP）。从这一点出发，转向OAuth并不会增加额外的开销。它甚至可以使服务器摆脱必须连接到LDAP的需要。 - Christian Schneider

Answer 2

为什么流行的网络服务（如Github、AWS、Google等）使用其他方法（例如AWS使用：Authorization: AWS4-HMAC-SHA256 Credential=...）来验证客户端身份？

AWS签名头不仅基于客户端凭据，还包括从请求本身派生的位以及当前时间。其净效应是不仅验证客户端身份，还验证请求内容，因此即使某人设法获取签名，也不能将其用于另一个请求（或在传输过程中修改请求）。包含当前时间使签名仅在有限期间内有效，从而减轻了重放攻击的影响。

- weirdan

Answer 3

来自OAuth2服务器的令牌不应作为直接身份验证手段使用。它们不代表最终用户，而是代表客户端代表该用户执行操作的授权。他们的文章清楚地解释了原因。

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

他们有一个认证库列表，您可以使用它来实现自己的服务器。或者您可以利用众多现有的IODC提供商之一。

- ZeroUltimax