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

Question

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

HTTP基本认证不是与OAuth不同吗？

- yathirigan

Answer 1

是的，HTTP基本身份验证与OAuth 2.0不同。然而，《资源拥有者密码证书授权》在客户端凭据的授权请求中使用基本身份验证方案，如第4.3.1节.授权请求和响应所述。

资源拥有者密码证书授权通常用于将旧系统转换为OAuth 2.0，但比基本身份验证方案更加安全。

只有在资源所有者和OAuth客户端之间存在高度信任时，才应使用资源拥有者密码授权类型，并且在没有其他授权类型可用的情况下才使用它。

- jwilleke

---

“高度信任”是因为最终用户（资源所有者）向可信的第三方客户端提供其用户名和密码（而不是在其他授权流程中向授权服务器提供），并且该第三方客户端调用授权服务器吗？ - yathirigan

使用HTTP基本身份验证技术（即使用Authorization头和base64编码的凭据），可由受信任的第三方应用将用户凭据发送到授权服务器。我的理解正确吗？ - yathirigan

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

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

我同意Hanz的观点。在OAuth2的背景下，基本身份验证用于验证机密客户端，而不是用户。用户凭据通过POST请求体发送。 - Spomky-Labs

Answer 2

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

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

- Ankit

Answer 3

基本身份验证 的使用方式类似于 OAuth 2.0 客户端凭据授权类型。

可以使用 基本身份验证 创建会话，并在有状态的环境中使用 sessionid 访问服务。

但是，如果由于会话限制或无状态服务而不想使用会话，则可以使用 OAuth 2.0 客户端凭据授权类型，它将创建一个令牌而不是会话和sessionid。该令牌提供对服务的访问权限。

- Ali

Answer 4

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

在现实世界中，基本HTTP访问认证方法是什么样子？

1. 提供给想要连接到移动API的第三方开发者的访问凭据是完全保密的字母数字ID。

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

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

GET /private/index.php HTTP/1.1

Host: example.com

Authorization: Basic 字母数字ID

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

1. 用户启动原生应用程序，并被要求提供用户名或电子邮件地址和密码以作为用户进行身份验证。

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

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

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

如果我们比较这两种方法，OAuth 2.0 提供了更好的安全标准，因为任何对凭证的初始请求都是在 SSL 协议下进行的，并且保证访问对象是一次性令牌。在基本的 HTTP 访问认证过程中，API 服务的访问总是依赖于通过网络发送凭证，特别是在 HTTP 标头中发送，这使其更容易受到第三方攻击。

- Gehan Mallikarachchi