使用承载令牌进行身份验证（≠授权） [英] Using a bearer token for authentication(≠ authorization)

问题描述

使用授权：bearer [token] 的请求可以用于身份验证吗？

A request using the Authorization: bearer [token] can be used for authentication?

或

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

Should we use another method to authenticate a client and issue a token then use the token as a bearer token like OAuth2 does? Why popular web services(e.g. Github, AWS, Google..) uses other method(like AWS does: Authorization: AWS4-HMAC-SHA256 Credential=...) to authenticate a client. The point of the question is: is there any valunerables or violation of standards in the following flow or not.

我想使用以下流程：

客户：这就像Twitter客户端。

服务器：这就像Twitter API。

the client: which is like Twitter client.
the server: which is like Twitter API.

1. 客户端发出令牌（加密的用户ID，密码等）。


2. 客户端使用授权：bearer [token] 向服务器请求资源。


3. 服务器解密令牌并验证客户端。


4. 服务器响应资源。

1. the client makes the token(encrypted user ID, password, and etc).
2. the client requests a resource to the server with Authorization: bearer [token].
3. the server decrypts the token and authenticates the client.
4. the server response the resource.

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

I read the following RFC but I haven't found any reason why I shouldn't or should use the flow above.

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

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

谢谢

推荐答案

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

I would recommend to stick to the OAuth2 spec. If you want to use a username and password to obtain a token you should use the "Client Credentials" flow. That means you need an "https" endpoint where the user can obtain an access token through the following POST request:

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

grant_type=client_credentials

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

If the client credentials are valid the endpoint should create an access token on the server. Beside the token you should store who has obtained the token and a timestamp when the token expires. So the token should not be the username and password encrypted like in your example instead it should be a random string which is assigned to the user.

访问令牌可以是客户端用于访问API的受保护部分。如果您的API收到了持有人令牌，您可以在令牌表中查找已分配的用户。

The access token can then be used by the client to access protected parts of your API. If your API receives an bearer token you can look up the assigned user in your token table.

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

That being said in OAuth2 you typically get an access token though an app key and secret which you have obtained previously by the API provider. This has the advantage that the user does not need to share any credentials with an 3rd party app. But whether this is needed depends on your use case.

这篇关于使用承载令牌进行身份验证（≠授权）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！