协定官网

在传统的客户端 - 服务器身份验证模型中，客户端通过应用资源所有者的凭据向服务器进行身份验证来申请服务器上的拜访受限资源（受爱护资源）。为了向第三方应用程序提供对受限资源的拜访，资源所有者与第三方共享其凭证。这产生了若干问题和限度。

1. 第三方应用程序须要存储资源所有者的凭据以备未来应用，通常是明文明码。
2. 要求服务器反对明码认证，只管明码存在固有的平安弱点。
3. 第三方应用程序取得对资源所有者受爱护资源的过于宽泛的拜访权限，使资源所有者无奈限度持续时间或拜访无限的资源子集。
4. 资源所有者不能在不撤销对所有第三方的拜访权限的状况下撤销对单个第三方的拜访权限，必须通过更改第三方的明码来实现。
5. 任何第三方应用程序的泄露都会导致最终用户的明码和受该密码保护的所有数据泄露。

OAuth 通过引入受权层 (authorization layer) 并将客户端的角色与资源所有者的角色离开来解决这些问题。在 OAuth 中，客户端申请拜访由资源所有者管制并由资源服务器托管的资源，并取得一组与资源所有者不同的凭据(credentials)。

客户端不是应用资源所有者的凭据来拜访受爱护的资源，而是获取拜访令牌——一个示意特定范畴 (scope)、生命周期和其余拜访属性的字符串。拜访令牌由受权服务器(authorization server) 在资源所有者的批准下颁发给第三方客户端。客户端应用拜访令牌拜访由资源服务器托管的受爱护资源。

例如，最终用户（资源所有者）能够授予打印服务（客户端）拜访其存储在照片共享服务（资源服务器）中的受爱护照片的权限，而无需与打印服务共享其用户名和明码。相同，她间接向照片共享服务（受权服务器）信赖的服务器进行身份验证，该服务器颁发打印服务委托特定的凭据（拜访令牌）。

该标准设计用于 HTTP ([RFC2616])。

OAuth 1.0 协定 ([RFC5849]) 作为信息文档公布，是小型长期社区致力的后果。此规范跟踪标准建设在 OAuth 1.0 部署教训以及从更宽泛的 IETF 社区收集的其余用例和可扩展性要求的根底上。

OAuth 2.0 协定不向后兼容 OAuth 1.0。这两个版本能够在网络上共存，并且实现能够抉择同时反对这两个版本。然而，本标准的用意是新实现反对本文档中指定的 OAuth 2.0，并且 OAuth 1.0 仅用于反对现有部署。OAuth 2.0 协定与 OAuth 1.0 协定共享很少的实现细节。相熟 OAuth 1.0 的实施者应该靠近本文档，不要对其构造和细节做任何假如。

Oauth 里的四个角色

资源所有者

可能授予对受爱护资源的拜访权限的实体。

当资源所有者是集体时，它被称为最终用户。

资源服务器

托管受爱护资源的服务器，可能应用拜访令牌承受和响应受爱护资源申请。

# 客户 – client

代表资源所有者并经其受权收回受爱护资源申请的应用程序。术语“客户端”并不意味着任何特定的实现特色（例如，应用程序是否在服务器、桌面或其余设施上执行）。

受权服务器(authorization server)

服务器在胜利验证资源所有者并取得受权后向客户端颁发拜访令牌。

受权服务器和资源服务器之间的交互超出了本标准的范畴。

受权服务器能够是与资源服务器雷同的服务器，也能够是独自的实体。

单个受权服务器能够公布多个资源服务器承受的拜访令牌。

形象的 OAuth 2.0 流程形容了四个角色之间的交互，包含以下步骤：

(A) 客户端向资源所有者申请受权。受权申请能够间接发送给资源所有者，或者最好通过受权服务器作为中介间接发送。

(B) 客户端收到受权确认，这是代表资源所有者受权的凭证，应用本标准中定义的四种受权类型之一或应用扩大受权类型示意。受权受权类型取决于客户端申请受权的办法和受权服务器反对的类型。

(C) 客户端申请拜访令牌，这是通过与受权服务器进行身份验证来实现。

(D) 受权服务器对客户端进行身份验证并验证受权许可，如果无效，则颁发拜访令牌。

(E) 客户端向资源服务器申请受爱护的资源，并通过提供拜访令牌进行身份验证。

(F) 资源服务器验证拜访令牌，如果无效，则为申请提供服务。

Authorization Grant

受权许可是一种凭证，示意客户端用于获取拜访令牌的资源所有者受权（拜访其受爱护的资源）。该标准定义了四种受权类型——受权代码、隐式、资源所有者明码凭据和客户端凭据——以及用于定义其余类型的可扩展性机制。

Authorization Code

受权码是通过受权服务器作为客户端和资源所有者之间的中介取得的。客户端不是间接从资源所有者申请受权，而是将资源所有者疏导到受权服务器（通过其在 [RFC2616] 中定义的用户代理），后者又将资源所有者疏导回带有受权代码的客户端。

在应用受权码将资源所有者疏导回客户端之前，受权服务器对资源所有者进行身份验证并取得受权。因为资源所有者仅通过受权服务器进行身份验证，因而永远不会与客户端共享资源所有者的凭据。

受权代码提供了一些重要的平安劣势，例如可能对客户端进行身份验证，以及将拜访令牌间接传输到客户端，而无需通过资源所有者的用户代理并可能将其裸露给其他人，包含资源所有者。

Implicit

隐式受权是针对应用 JavaScript 等脚本语言在浏览器中实现的客户端进行了优化的简化受权代码流。在隐式流程中，不是向客户端公布受权代码，而是间接向客户端公布拜访令牌（作为资源所有者受权的后果）。
受权类型是隐式的，因为没有颁发两头凭证（例如受权代码）（稍后用于获取拜访令牌）。

在隐式受权流程期间公布拜访令牌时，受权服务器不会对客户端进行身份验证。在某些状况下，能够通过用于将拜访令牌传递给客户端的重定向 URI 来验证客户端身份。拜访令牌可能会裸露给资源所有者或其余有权拜访资源所有者的用户代理的应用程序。

隐式受权进步了某些客户端（例如作为浏览器内应用程序实现的客户端）的响应能力和效率，因为它缩小了获取拜访令牌所需的往返次数。然而，这种便当应该与应用隐式受权的安全隐患进行衡量，尤其是当受权代码受权类型可用时。

Resource Owner Password Credentials

资源所有者明码凭据（即用户名和明码）能够间接用作受权许可来获取拜访令牌。仅当资源所有者和客户端之间存在高度信赖（例如，客户端是设施操作系统或高特权应用程序的一部分）并且其余受权授予类型不可用时，才应应用凭据（例如受权码）。

只管此受权类型须要客户端间接拜访资源所有者凭据，但资源所有者凭据仍用于单个申请并替换拜访令牌。通过将凭据与长期拜访令牌或刷新令牌替换，此受权类型能够打消客户端存储资源所有者凭据以备未来应用的须要。

Client Credentials

当受权范畴仅限于客户端管制下的受爱护资源，或先前与受权服务器安顿的受爱护资源时，客户端凭据（或其余模式的客户端身份验证）可用作受权许可。客户端凭据通常用作受权受权，当客户端代表本人行事（客户端也是资源所有者）或依据先前与受权服务器安顿的受权申请拜访受爱护资源时。

Access Token

拜访令牌是用于拜访受爱护资源的凭据。拜访令牌是一个字符串，示意颁发给客户端的受权。该字符串通常对客户端不通明。令牌代表特定的拜访范畴和持续时间，由资源所有者授予，并由资源服务器和受权强制执行
服务器。

令牌能够示意用于检索受权信息的标识符，或者能够以可验证的形式自蕴含受权信息（即，由一些数据和签名组成的令牌字符串）。为了让客户端应用令牌，可能须要额定的身份验证凭据，这超出了本标准的范畴。

拜访令牌提供了一个形象层，用资源服务器了解的单个令牌替换了不同的受权构造（例如，用户名和明码）。这种形象使得颁发拜访令牌比用于获取它们的受权授予更严格，并且打消了资源服务器理解各种身份验证办法的须要。

依据资源服务器的平安要求，拜访令牌能够具备不同的格局、构造和应用办法（例如，加密属性）。拜访令牌属性和用于拜访受爱护资源的办法超出了本标准的范畴，并由诸如 [RFC6750] 的配套标准定义。

Refresh Token

刷新令牌是用于获取拜访令牌的凭据。刷新令牌由受权服务器颁发给客户端，用于在以后拜访令牌生效或过期时获取新的拜访令牌，或者获取具备雷同或更窄范畴的附加拜访令牌（拜访令牌可能具备较短的生命周期和 比资源所有者受权的权限少）。
颁发刷新令牌是可选的，由受权服务器决定。如果受权服务器公布刷新令牌，它会在公布拜访令牌时蕴含在内。

刷新令牌是一个字符串，示意资源所有者授予客户端的受权。该字符串通常对客户端不通明。令牌示意用于检索受权信息的标识符。与拜访令牌不同，刷新令牌仅用于受权服务器，永远不会发送到资源服务器。

(A) 客户端通过与受权服务器进行身份验证并提供受权许可来申请拜访令牌。

(B) 受权服务器对客户端进行身份验证并验证受权许可，如果无效，则颁发拜访令牌和刷新令牌。

(C) 客户端通过提供拜访令牌向资源服务器收回受爱护的资源申请。

(D) 资源服务器验证拜访令牌，如果无效，则为申请提供服务。

(E) 反复步骤 (C) 和 (D)，直到拜访令牌过期。如果客户端晓得拜访令牌已过期，则跳到步骤（G）；否则，它会收回另一个受爱护的资源申请。

(F) 因为拜访令牌有效，资源服务器返回有效令牌谬误。

(G) 客户端通过与受权服务器进行身份验证并提供刷新令牌来申请新的拜访令牌。客户端身份验证要求基于客户端类型和受权服务器策略。

(H) 受权服务器对客户端进行身份验证并验证刷新令牌，如果无效，则颁发新的拜访令牌（以及可选的新刷新令牌）。

Refreshing an Access Token

如果受权服务器向客户端收回刷新令牌，则客户端通过应用“application/x-www-form-urlencoded”格局增加以下参数向令牌端点收回刷新申请，其中字符编码为 UTF-8 HTTP 申请实体主体：

• 授予类型：必须。值必须设置为“refresh_token”。
• refresh_token：须要。发给客户端的刷新令牌。

因为刷新令牌通常是用于申请其余拜访令牌的长久凭据，因而刷新令牌绑定到其颁发给的客户端。如果客户端类型是秘密的，或者客户端取得了客户端凭据（或调配了其余身份验证要求），则客户端必须向受权服务器进行身份验证。

例如，客户端应用传输层安全性收回以下 HTTP 申请（额定的换行符仅用于显示目标）：

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

受权服务器必须：

1. 要求对秘密客户端或任何已颁发客户端凭据（或具备其余身份验证要求）的客户端进行客户端身份验证
2. 如果蕴含客户端身份验证，则对客户端进行身份验证，并确保将刷新令牌颁发给通过身份验证的客户端，以及
3. 验证刷新令牌。

如果无效并取得受权，受权服务器会收回拜访令牌。如果申请验证失败或有效，受权服务器返回谬误响应。

受权服务器可能会收回一个新的刷新令牌，在这种状况下，客户端必须抛弃旧的刷新令牌并用新的刷新令牌替换它。受权服务器能够在向客户端收回新的刷新令牌后撤销旧的刷新令牌。如果公布了新的刷新令牌，则刷新令牌的范畴必须与客户端在申请中蕴含的刷新令牌的范畴雷同。

Security Considerations

Client Authentication

受权服务器与 Web 应用程序客户端建设客户端凭据以进行客户端身份验证。激励受权服务器思考比客户端明码更强的客户端身份验证办法。Web 应用程序客户端必须确保客户端明码和其余客户端凭据的机密性。

受权服务器不得出于客户端身份验证的目标向本机应用程序或基于用户代理的应用程序客户端收回客户端明码或其余客户端凭据。受权服务器能够为特定设施上本地应用程序客户端的特定装置公布客户端明码或其余凭据。

当客户端身份验证不可能时，受权服务器应该采纳其余形式来验证客户端的身份——例如，通过要求注册客户端重定向 URI 或征集资源所有者来确认身份。在申请资源所有者受权时，无效的重定向 URI 不足以验证客户端的身份，但可用于避免在取得资源所有者受权后将凭据传递给伪造的客户端。

受权服务器必须思考与未经身份验证的客户端交互的安全隐患，并采取措施限度向此类客户端颁发的其余凭据（例如刷新令牌）的潜在裸露。

Client Impersonation

如果被模仿的客户端未能或无奈将其客户端凭据窃密，则歹意客户端能够模仿另一个客户端并取得对受爱护资源的拜访权限。

受权服务器必须尽可能对客户端进行身份验证。如果因为客户端的性质受权服务器无奈对客户端进行身份验证，则受权服务器必须要求注册任何用于接管受权响应的重定向 URI，并且应该应用其余办法来爱护资源所有者免受此类潜在歹意客户端的侵害。例如，受权服务器能够让资源所有者帮助辨认客户端及其起源。

受权服务器应该强制执行明确的资源所有者身份验证并向资源所有者提供无关客户端和申请的受权范畴和生命周期的信息。资源所有者能够在以后客户端的上下文中查看信息并受权或拒绝请求。

受权服务器不应该在没有验证客户端或依赖其余措施的状况下主动解决反复的受权申请（没有被动的资源所有者交互），以确保反复的申请来自原始客户端而不是模仿者。

Access Tokens

拜访令牌凭证（以及任何秘密的拜访令牌属性）必须在传输和存储过程中窃密，并且只能在受权服务器、拜访令牌对其无效的资源服务器以及拜访令牌颁发给的客户端之间共享. 拜访令牌凭证必须仅应用 TLS 传输，并应用 [RFC2818] 定义的服务器身份验证。

应用隐式受权类型时，拜访令牌在 URI 片段中传输，这可能会将其裸露给未受权方。

受权服务器必须确保未受权方无奈生成、批改或猜想拜访令牌以生成无效的拜访令牌。

客户端应该申请具备最小必要范畴的拜访令牌。受权服务器应该在抉择如何承受申请的范畴时思考客户端身份，并且能够公布权限少于申请的拜访令牌。

本标准没有为资源服务器提供任何办法来确保受权服务器向该客户端颁发给定客户端提供给它的拜访令牌。

Refresh Tokens

受权服务器能够向 Web 应用程序客户端和本机应用程序客户端收回刷新令牌。

刷新令牌在传输和存储过程中必须窃密，并且只能在受权服务器和刷新令牌发给的客户端之间共享。

受权服务器必须保护刷新令牌和它被颁发给的客户端之间的绑定。刷新令牌必须仅应用 TLS 传输，并具备 [RFC2818] 定义的服务器身份验证。

每当能够验证客户端身份时，受权服务器必须验证刷新令牌和客户端身份之间的绑定。当无奈进行客户端身份验证时，受权服务器应该部署其余办法来检测刷新令牌滥用。

例如，受权服务器能够应用刷新令牌轮换，其中每个拜访令牌刷新响应都会收回一个新的刷新令牌。先前的刷新令牌已生效但由受权服务器保留。如果刷新令牌被毁坏并随后被攻击者和非法客户端应用，其中之一将提供有效的刷新令牌，这将告诉受权服务器该破绽。

受权服务器必须确保未受权方无奈生成、批改或猜想刷新令牌以生成无效的刷新令牌。