更友好的阅读体验，请转至 OAuth 深入介绍 。

• 1. 前言
• 2. OAuth2 角色
  • 2.1 资源所有者（Resource Owner）
  • 2.2 资源/授权服务器（Resource/Authorization Server）
  • 2.3 客户端（Client）
• 3. OAuth 2 的授权流程
• 4. 客户端应用注册
  • 4.1 Client ID 和 Client Secret
• 5. 授权许可（Authorization Grant）
  • 5.1 Authorization Code Flow
    • 1. User Authorization Request
    • 2. User Authorizes Applcation
    • 3. Authorization Code Grant
    • 4. Access Token Request
    • 5. Access Token Grant
  • 5.2 Implicit Flow
    • 1. User Authorization Request
    • 2. User Authorizes Application（略）
    • 3. Redirect URI With Access Token In Fragment
    • 4. User-agent Follows the Redirect URI
    • 5. Application Sends Access Token Extraction Script
    • 6. Access Token Passed to Application
  • 5.3 Resource Owner Password Credentials Flow
    • 1. Resource Owner Password Credentials From User Input
    • 2. Resource Owner Password Credentials From Client To Server
    • 3. Access Token Passed to Application
  • 5.4 Client Credentials Flow
• 6. 总结
• 参考资料及文献
• 名词中英文对照

1. 前言

OAuth 2 是一个授权框架，或称授权标准，它可以使第三方应用程序或客户端获得对HTTP服务上（例如 Google，GitHub ）用户帐户信息的有限访问权限。OAuth 2 通过将用户身份验证委派给托管用户帐户的服务以及授权客户端访问用户帐户进行工作。综上，OAuth 2 可以为 Web 应用 和桌面应用以及移动应用提供授权流程。

本文将从OAuth 2 角色，授权许可类型，授权流程等几方面进行讲解。

在正式讲解之前，这里先引入一段应用场景，用以与后文的角色讲解对应。

开发者A注册某IT论坛后，发现可以在信息栏中填写自己的 Github 个人信息和仓库项目，但是他又觉得手工填写十分麻烦，直接提供 Github 账户和密码给论坛管理员帮忙处理更是十分智障。
不过该论坛似乎和 Github 有不可告人的秘密，开发者A可以点击“导入”按钮，授权该论坛访问自己的 Github 账户并限制其只具备读权限。这样一来， Github 中的所有仓库和相关信息就可以很方便地被导入到信息栏中，账户隐私信息也不会泄露。
这背后，便是 OAuth 2 在大显神威。

2. OAuth2 角色

OAuth 2 标准中定义了以下几种角色：

• 资源所有者（Resource Owner）
• 资源服务器（Resource Server）
• 授权服务器（Authorization Server）
• 客户端（Client）

2.1 资源所有者（Resource Owner）

资源所有者是 OAuth 2 四大基本角色之一，在 OAuth 2 标准中，资源所有者即代表授权客户端访问本身资源信息的用户（User），也就是应用场景中的“开发者A”。客户端访问用户帐户的权限仅限于用户授权的“范围”（aka. scope，例如读取或写入权限）。

如果没有特别说明，下文中出现的"用户"将统一代表资源所有者。

2.2 资源/授权服务器（Resource/Authorization Server）

资源服务器托管了受保护的用户账号信息，而授权服务器验证用户身份然后为客户端派发资源访问令牌。

在上述应用场景中，Github 既是授权服务器也是资源服务器，个人信息和仓库信息即为资源（Resource）。而在实际工程中，不同的服务器应用往往独立部署，协同保护用户账户信息资源。

2.3 客户端（Client）

在 OAuth 2 中，客户端即代表意图访问受限资源的第三方应用。在访问实现之前，它必须先经过用户者授权，并且获得的授权凭证将进一步由授权服务器进行验证。

如果没有特别说明，下文中将不对"应用"，“第三方应用”，“客户端”做出区分。

3. OAuth 2 的授权流程

目前为止你应该对 OAuth 2 的角色有了些概念，接下来让我们来看看这几个角色之间的抽象授权流程图和相关解释。

请注意，实际的授权流程图会因为用户返回授权许可类型的不同而不同。但是下图大体上能反映一次完整抽象的授权流程。

1. Authrization Request
   客户端向用户请求对资源服务器的authorization grant。
2. Authorization Grant（Get）
   如果用户授权该次请求，客户端将收到一个authorization grant。
3. Authorization Grant（Post）
   客户端向授权服务器发送它自己的客户端身份标识和上一步中的authorization grant，请求访问令牌。
4. Access Token（Get）
   如果客户端身份被认证，并且authorization grant也被验证通过，授权服务器将为客户端派发access token。授权阶段至此全部结束。
5. Access Token（Post && Validate）
   客户端向资源服务器发送access token用于验证并请求资源信息。
6. Protected Resource（Get）
   如果access token验证通过，资源服务器将向客户端返回资源信息。

4. 客户端应用注册

在应用 OAuth 2 之前，你必须在授权方服务中注册你的应用。如 Google Identity Platform 或者 Github OAuth Setting，诸如此类 OAuth 实现平台中一般都要求开发者提供如下所示的授权设置项。

• 应用名称
• 应用网站
• 重定向URI或回调URL

重定向URI是授权方服务在用户授权（或拒绝）应用程序之后重定向供用户访问的地址，因此也是用于处理授权码或访问令牌的应用程序的一部分。

4.1 Client ID 和 Client Secret

一旦你的应用注册成功，授权方服务将以client id和client secret的形式为应用发布client credentials（客户端凭证）。client id是公开透明的字符串，授权方服务使用该字符串来标识应用程序，并且还用于构建呈现给用户的授权 url 。当应用请求访问用户的帐户时，client secret用于验证应用身份，并且必须在客户端和服务之间保持私有性。

5. 授权许可（Authorization Grant）

如上文的抽象授权流程图所示，前四个阶段包含了获取authorization grant和access token的动作。授权许可类型取决于应用请求授权的方式和授权方服务支持的 Grant Type。OAuth 2 定义了四种 Grant Type，每一种都