Question

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

或

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

我想使用以下流程：

the client：就像Twitter客户端一样 the server：就像Twitter API一样。

客户端发出令牌（加密的用户ID，密码等）。
客户端使用Authorization: bearer [token]向服务器请求资源。
服务器解密令牌并验证客户端。
服务器响应资源。

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

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

由于

Answer 1

我建议坚持使用OAuth2规范。如果您想使用用户名和密码来获取令牌，您应该使用＆＃34;客户端凭据＆＃34;流。这意味着你需要一个＆＃34; https＆＃34;用户可以通过以下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提供商先前获得的应用密钥和密钥获取访问令牌。这具有以下优点：用户不需要与第三方应用共享任何凭证。但是否需要这取决于您的用例。

Answer 2

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

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

Answer 3

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

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

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

中的一个

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

3 个答案: