HTTP 基本身份验证和 OAuth 2.0 相同吗？

Posted 2023-02-24

【中文标题】HTTP 基本身份验证和 OAuth 2.0 相同吗？

【英文标题】：Is HTTP Basic Authentication and OAuth 2.0 same?

【发布时间】：2017-07-31 09:07:44

【问题描述】：

供应商 API 文档之一提到他们的 API 调用需要使用 HTTP 基本身份验证方案，即用户：密码 Base64 编码，但是，他们的令牌 API（登录等效）文档提到“..this服务实现 OAuth 2.0 - 资源所有者密码和凭据授予"

HTTP 基本身份验证与 OAuth 不同吗？

【参考方案1】：

是的，HTTP 基本身份验证不同于 OAuth 2.0。但是，Resource Owner Password Credentials Grant 在客户端凭据的授权请求中使用基本身份验证方案，如section 4.3.1. Authorization Request and Response 所述

资源所有者密码凭据授予通常用于将旧系统转换为 OAuth 2.0，并且不比 Basic Authentication Scheme 更安全。

资源所有者密码凭据授权旨在在没有其他授权类型可用时使用，并且仅在资源所有者和 OAuth 客户端之间存在高度信任时使用。

【讨论】：

>高度信任

和 HTTP 基本身份验证技术（使用授权标头和 base64 编码凭据）由受信任的第 3 方应用程序用于将用户凭据发送到授权服务器。我的理解正确吗？

资源所有者密码凭据授予不使用基本身份验证方案。它宁可使用自己的方案将用户名和密码作为 POST 参数传递。

@HansZ。是正确的，但客户端确实使用 HTTP 基本身份验证。 （为澄清而编辑的答案）

@yathirigan - 是的，这是因为，最终用户（资源所有者）将他/她的用户 ID 和密码提供给这个受信任的第 3 方客户端

【参考方案2】：

是的，它们都是不同的。 Http Basic ：这是用于身份验证和用户凭据被编码，然后在 HTTP 标头中传递给客户端服务器。 HTTP Basic 的基本示例：就像传统的 Web 应用程序要求用户提供凭据并将这些凭据发送到 HTTP 标头中的服务器一样。稍后服务器会利用这些凭据对用户进行身份验证。

OAuth 2 ：这是为了授权，这里客户端服务器需要授权服务器对用户数据（资源所有者）的授权。 OAuth 2 的基本示例：假设有一个在线游戏应用程序在服务器上运行，用户访问了该应用程序，该应用程序开始加载到用户的浏览器中。现在，该应用程序要求用户授予在他的 Facebook 帐户上发布有关游戏的数据。在这里，用户授权他的那个应用程序通过 OAuth 标准访问他的 Facebook 帖子。参考内部机制https://www.rfc-editor.org/rfc/rfc6749

【参考方案3】：

Basic access authentication 的使用情况与 OAuth 2.0 Client Credentials Grant Type 相当。

可以使用Basic Authentication 创建会话，并且可以在有状态环境中使用sessionid 访问服务。

但如果由于会话限制或无状态服务而不想使用会话，则可以改用OAuth 2.0 Client Credentials Grant Type，它会创建令牌而不是会话和sessionid。此令牌提供对服务的访问。

【参考方案4】：

HTTP基本访问认证： 这是满足访问 Web 服务要求的更简单的方法。它很简单，因为它不需要凭证系统中的任何常用流程：cookie、会话 ID 或访问页面。整个 HTTP 基本身份验证过程基于 HTTP 标头中的标准字段。因此，它避免了握手：两个实体在通过已建立的通道开始正常通信之前建立经过身份验证的通信的自动化过程。这意味着设备只有在认证成功的情况下才能与外部设备通信；否则，不创建通信通道。例如，通过调制解调器的连接会失败。基本 HTTP 访问认证方法的安全开发是 HTTPs。 为了防止基本的 HTTP 访问身份验证方法导致浏览器为每次访问发起用户名和密码请求，浏览器必须将此信息存储在缓存中一段谨慎的时间，而不会过度降低安全性。这些安全凭证通常存储 15 分钟。

这种基本的 HTTP 访问身份验证方法在现实世界中是什么样的？

向想要连接到移动 API 的第三方开发者提供的访问凭证是一个完全保密的字母数字 ID。

此字母数字 API 密钥存储在服务器上的安全空间中。

对此 API 中包含的特定服务提出请求的开发人员应将此秘密 ID 连同单词 Basic 一起放在 HTTP 授权标头中。这两个元素一起允许服务器识别字母数字凭据并提供访问权限。

GET /private/index.php HTTP/1.1

主机：example.com

授权：基本字母数字 ID

OAuth 2.0： OAuth 代表了在使用凭据对 API 服务用户进行身份验证方面向前迈出了一步。这是对基本 HTTP 访问身份验证方法的重大改进。今天，它实际上是唯一几乎 100% 可靠的安全方法，其可靠性基于为每个用户创建唯一的身份验证令牌。如果此访问令牌遭到破坏，则会将其删除并发布一个新令牌。这意味着 API 自己的凭据受到保护。 认证过程如下：

用户启动本机应用程序，并被要求提供用户名或电子邮件地址和密码以将自己标识为用户。

用于将此凭据发送到 API 的请求类型是 POST 请求，可确保秘密数据的私密传送。此请求通过 SSL（安全套接字层）协议发送，旨在使应用程序能够安全地传输出站数据。 SSL 有助于在应用程序之间提供和接收加密密钥。

此请求允许验证用户凭据并创建临时身份验证或访问令牌，该令牌将在一段时间后过期，或者如果负责 API 的用户或开发人员认为它已被破坏。

此身份验证令牌存储在设备中，以便于访问支持应用程序本身的 API 服务。

如果我们比较这两种方法，OAuth 2.0 提供了更好的安全标准，因为对凭据的任何初始请求都是在 SSL 协议下发出的，并且保证访问对象是一个临时令牌。在基本的 HTTP 访问身份验证过程中，对 API 服务的访问始终依赖于通过 Web 发送凭据，特别是在 HTTP 标头中，这使得它很容易受到第三方的攻击。