使用Authorization: bearer [token] 的请求可以用于身份验证吗？
或
我们是否应该使用另一种方法来验证客户端并颁发 token ，然后像 OAuth2 一样将 token 用作不记名 token ？
为什么流行的网络服务(例如 Github、AWS、Google..)使用其他方法(如 AWS 所做的:Authorization: AWS4-HMAC-SHA256 Credential=...)来验证客户端。问题的重点是:下面的流程是否有任何有值(value)或违反标准的地方。
我想使用以下流程:
客户端:类似于 Twitter 客户端。
服务器:类似于 Twitter API。
- 客户端生成 token (加密的用户 ID、密码等)。
- 客户端使用
Authorization: bearer [token]向服务器请求资源。 - 服务器解密 token 并对客户端进行身份验证。
- 服务器响应资源。
我阅读了以下 RFC，但没有找到我不应该或应该使用上述流程的任何理由。
https://www.rfc-editor.org/rfc/rfc7235
https://www.rfc-editor.org/rfc/rfc6750
谢谢
最佳答案
我建议坚持 OAuth2 规范。如果您想使用用户名和密码来获取 token ，您应该使用“客户端凭据”流程。这意味着您需要一个“https”端点，用户可以在其中通过以下 POST 请求获取访问 token :
POST /token HTTP/1.1
Authorization: Basic base64_encode("username:password")
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
如果客户端凭据有效，端点应在服务器上创建一个访问 token 。在 token 旁边，您应该存储谁获得了 token 以及 token 过期时的时间戳。因此 token 不应像您的示例中那样是加密的用户名和密码，而应该是分配给用户的随机字符串。
然后客户端可以使用访问 token 来访问 API 的 protected 部分。如果您的 API 收到不记名 token ，您可以在 token 表中查找分配的用户。
在 OAuth2 中，您通常会通过 API 提供商之前获得的应用 key 和 secret 获得访问 token 。这样做的好处是用户不需要与第三方应用程序共享任何凭据。但是否需要这取决于您的用例。
关于api - 使用不记名 token 进行身份验证(≠授权)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/42617000/