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

Question

使用授权：持有者 [令牌] 的请求可用于身份验证吗？

或者

我们应该使用另一种方法来验证客户端并颁发令牌，然后像OAuth2一样将令牌用作不记名令牌吗？为什么流行的Web服务（例如Github、AWS、Google…）使用其他方法（如AWS所做的：授权：AWS4-HMAC-SHA256凭据=…）来验证客户端。问题的重点是：以下流程中是否存在任何可值或违反标准的行为。

我想使用以下流程：

客户端：类似于Twitter客户端。
服务器：类似于Twitter API。

< li >客户端生成令牌(加密的用户ID、密码等)。 < li >客户端使用< code > Authorization:bearer[token]向服务器请求资源。 < li >服务器解密令牌并验证客户端。 < li >服务器响应资源。

我阅读了下面的RFC，但我没有找到任何理由不应该或应该使用上面的流程。

https://www.rfc-editor.org/rfc/rfc7235
https://www.rfc-editor.org/rfc/rfc6750

谢谢

Answer 1

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

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

他们有一个可用于实现服务器的认证库列表。或者，您可以利用众多预先确定的IODC提供商之一

Answer 2

为什么流行的Web服务（例如Github、AWS、Google…）使用其他方法（如AWS所做的：授权：AWS4-HMAC-SHA256凭据=…）来对客户端进行身份验证。

AWS签名头不仅基于客户端凭据，它还包括从请求本身派生的比特以及当前时间。净效果是，不仅验证了客户端身份，还验证了请求内容，因此即使有人设法获得了签名，也无法在另一个请求上使用签名（或在飞行中修改请求）。包括当前时间使签名仅在有限的时间内有效，从而减轻重放攻击。

Answer 3

我建议坚持OAuth2规范。如果要使用用户名和密码获取令牌，则应使用“客户端凭据”流。这意味着您需要一个“https”endpoint，用户可以在其中通过以下 POST 请求获取访问令牌：

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

grant_type=client_credentials

如果客户端凭证有效，endpoint应该在服务器上创建访问令牌。除了令牌之外，您还应该存储谁获得了令牌以及令牌过期时的时间戳。因此，令牌不应该是像您的示例中那样加密的用户名和密码，而应该是分配给用户的随机字符串。

然后，客户端可以使用访问令牌来访问API的受保护部分。如果您的API收到不记名令牌，您可以在令牌表中查找分配的用户。

也就是说，在OAuth2中，您通常通过API提供者先前获得的应用程序密钥和机密来获得访问令牌。这样做的好处是，用户不需要与第三方应用程序共享任何凭据。但这是否需要取决于您的用例。