协议概述
OAuth（开放授权）是一个开放标准，允许用户授权第三方移动应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方移动应用或分享他们数据的所有内容，OAuth 2.0 是 OAuth 协议的延续版本，但不向后兼容 OAuth 1.0 即完全废止了 OAuth1.0。
应用场景
第三方应用授权登录：在 App 或者网页接入一些第三方应用时，时常会需要用户登录另一个合作平台，如 QQ，微博，微信的授权登录。
Native App 授权：App 登录请求后台接口，为了安全认证，所有请求都带 token 信息，如登录验证、请求后台数据。
前后端分离单页面应用（SPA）：前后端分离框架，前端请求后台数据，需要进行 OAuth2 安全认证，如使用 vue、react 后者 h5 开发的 App。
名词说明
Third-party application：第三方应用程序，本文中又称“客户端”（client），如打开知乎，使用第三方登录，选择 QQ 登录，这时知乎就是客户端。
HTTP service：HTTP 服务提供商，本文中简称“服务提供商”，即上例的 QQ。
Resource Owner：资源所有者，又称“用户”（user），即登录用户。
User Agent：用户代理，本文中指浏览器。
Authorization server：认证服务器，即服务提供商专门用来处理认证的服务器。
Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。
运行流程
授权码模式（Authorization Code）
功能最完整、流程最严密的授权模式。
1. 用户打开客户端以后，客户端要求用户给予授权。
2. 用户同意给予客户端授权。
3. 客户端使用上一步获得的授权，向认证服务器申请令牌。
4. 认证服务器对客户端进行认证以后，确认无误，同意发放令牌。
5. 客户端使用令牌，向资源服务器申请获取资源。
6. 资源服务器确认令牌无误，同意向客户端开放资源。
简化模式（Implicit Grant Type）
不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了“授权码”这个步骤。所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。
1. 客户端将用户导向认证服务器。
2. 用户决定是否给予客户端授权。
3. 假设用户给予授权，认证服务器将用户导向客户端指定的“重定向URI”，并在 URI 的 Hash 部分包含了访问令牌。
4. 浏览器向资源服务器发出请求，其中不包括上一步收到的 Hash 值。
5. 资源服务器返回一个网页，其中包含的代码可以获取 Hash 值中的令牌。
6. 浏览器执行上一步获得的脚本，提取出令牌。
7. 浏览器将令牌发给客户端。
密码模式（Resource Owner Password Credentials Grant）
用户向客户端提供自己的用户名和密码。客户端使用这些信息，向“服务商提供商”索要授权。在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下。一般不支持 refresh token。
1. 用户向客户端提供用户名和密码。
2. 客户端将用户名和密码发给认证服务器，向后者请求令牌。
3. 认证服务器确认无误后，向客户端提供访问令牌。
客户端模式（Client Credentials Grant）
指客户端以自己的名义，而不是以用户的名义，向“服务提供商”进行认证。严格地说，客户端模式并不属于 OAuth 框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以自己的名义要求“服务提供商”提供服务，其实不存在授权问题。
1. 客户端向认证服务器进行身份认证，并要求一个访问令牌。
2. 认证服务器确认无误后，向客户端提供访问令牌。
数字身份管控平台（员工版）功能概述
完整地实现 OAuth2 的四种模式
创建 OAuth2 应用时指定的 grantType，只针对从数字身份管控平台（员工版）门户发起登录的场景，grantType 设置为 authorization_code 时，授权成功后返回 code；grantType 设置为 implicit 时，授权成功后返回 access_token。
对于从应用系统发起登录的场景，四种模式都可以支持，应用发起登录重定向或接口调用时，根据实际情况传入各模式对应的 response_type 参数或 grant_type 参数即可。
支持令牌刷新
提供令牌刷新接口，应用使用 refresh_token 换取新的 access_token。
支持PKCE模式
授权码模式下，支持 PKCE 校验码验证。PKCE 模式适用于功能逻辑主要在客户端完成的 Native App。因为 Native App 没有浏览器那样的 cookie 支持，CP 服务器没有 session 这样的东西来保存 state 参数从而防止 CSRF，所以使用 PKCE 的 code_verifier 和 code_challenge 来防止 CSRF。
步骤如下：
这里主要考虑到的是，Native App 必须经过浏览器才能进行 redirect 操作，在下图的第③步中，由于使用了 App 的 custom schemer，如果有恶意 App 注册了同一个 schemer，则不能保证第③步的重定向会回到您的 App。
