1. OAuth是什么？
OAuth是Open Authorization的简写，它是一个开放授权标准。它允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。
OAuth允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的网站（例如，视频编辑网站)在特定的时段（例如，接下来的2小时内）内访问特定的资源（例如仅仅是某一相册中的视频）。这样，OAuth让用户可以授权第三方网站访问他们存储在另外服务提供者的某些特定信息，而非所有内容。因此，OAuth是安全的。
OAuth2.0是OAuth协议的延续版本，但不向前兼容(即完全废止了OAuth1.0)。
通俗来讲，OAuth是一种授权机制，授权第三方应用来获取特定的用户数据。
2. 它的成员
- Resource Owner：资源拥有者
- Resource Server：资源服务器，保管资源拥有者的（受保护的）资源的应用
- Client：客户端，即需要访问资源拥有者在资源服务器上的资源的应用
- Authorization Server：授权服务器，即资源服务器所在系统上，负责对该系统资源访问授权的服务器
- User-agent:用户代理对象，即帮你去访问资源的对象，一般是PC端浏览器或者是移动端的App、小程序
3. OAuth2.0能做什么？
- 第三方登录（微信登录、QQ登录等，这也算是获取用户在某一应用上的特定资源）
- 获取用户保存在某一应用上的特定资源
**解决的痛点：**第三方不可信的情况下，如何允许其访问用户托管的资源，并且不会造成破坏。
4. 那么，OAuth2.0如何授权呢？
总体上来说，OAuth2.0它有四种授权方式：
-
授权码模式（authorization code）
-
简化模式（implicit）
-
密码模式（resource owner password credentials）
-
客户端模式（client credentials）
一个大体的流程：
通俗的描述：
（老李让老赵去拿一下他藏在二营长的仓库里的那二两老白干）
**步骤1：**老赵说你让我去拿酒，但是二营长那小兔崽子不信任我呀，你给我开个条吧（客户端向资源拥有者索要授权）
**步骤2：**老李说这好办，于是便让卫兵写了个条子，并签上了大字（这里的授权是在资源拥有者允许的情况下，认证服务器给出的）
**步骤3：**老赵便拿着条子找二营长领酒（客户端带着用户给予的授权凭证，向认证服务器发起请求，获取资源访问权限）
**步骤4：**二营长看了看老赵手里的条子，心里有点嘀咕，说，行吧，酒在我们营的酒窖里，你等着，我给你个临时通行证，你去酒窖领酒去吧（认证服务器对凭证进行校验通过并授予对应资源的临时访问令牌）
**步骤5：**老赵便拿着临时通行证去酒窖拿酒（客户端带着访问令牌去请求资源服务器获取资源）
**步骤6：**酒窖的卫兵核查了老赵手里的令牌后，确认无误，便把酒给了老赵。（资源服务器校验客户端发来的访问令牌，通过则返回对应资源）
**题外话：**老李在等老赵去拿酒的过程中，寻思着还差两下酒菜，便穿上了上次袭击鬼子车队缴获的伪军的衣服去平安县城顺回来了半只烧鸡。。。（针对OAuth的csrf攻击，感兴趣的读者可以去了解一下）
4.1 授权码模式（authorizatiion code）
4.1.1 基本流程
**说明：**A服务的客户端需要获取B服务上的资源
基本流程：
（用户已经具备了应用A和应用B的相关权限）
第一步：用户（资源拥有者Resource Owner）通过用户代理对象（User-agent）请求应用A访问应用B上的资源
第二步：应用A将用户请求重定向到应用B的认证服务页面（这一步需要应用A提供一个回调地址，以便应用B的认证服务返回授权码）
第三步：用户登录，并点击授权按钮，表示允许应用A访问用户在应用B上的资源。
第四步：应用B的授权服务器（Authorization Server）生成授权码，并通过应用A提供的回调地址返回给应用A
第五步：应用A的认证服务器（Client）拿着授权码去请求应用B的授权服务器，获取对应资源访问的权限
第六步：应用B的授权服务器对授权码进行校验，通过则向客户端发放资源访问令牌
第七步：客户端带着访问令牌去资源服务器（Resource Server）请求对应资源
**特点：**令牌发放给第三方应用的认证服务器（Client），而不是暴露在浏览器中。
4.1.2 使用场景：
授权码模式是OAuth2中最安全最完善的一种模式，应用场景最广泛，可以实现服务之间的调用，常见的微信，QQ等第三方登录也可采用这种方式实现.
4.2 简化模式（implicit）
简化模式便是对授权码模式的一种简化，它去掉了第三方应用的认证服务器，并将token直接发到到浏览器（用户代理对象）
4.2.1 基本流程
第一步：用户（资源拥有者Resource Owner）通过用户代理对象（User-agent）请求应用A访问应用B上的资源
第二步：应用A将用户请求重定向到应用B的认证服务页面（这一步需要应用A提供一个回调地址，以便应用B的认证服务返回授权码）
第三步：用户登录，并点击授权按钮，表示允许应用A访问用户在应用B上的资源。
第四步：应用B的授权服务器（Authorization Server）生成授权码，并通过应用A提供的回调地址返回给用户代理对象（也相当于客户端）
第五步：客户端拿着授权码去请求应用B的授权服务器，获取对应资源访问的权限
第六步：应用B的授权服务器对授权码进行校验，通过则向客户端发放资源访问令牌和更新令牌
第七步：客户端带着访问令牌去资源服务器（Resource Server）请求对应资源，如果访问令牌已经过时，那么，客户端就要拿着更新令牌去找授权服务器重新发放访问令牌。
4.2.1 使用场景
适用于没有服务器的第三方应用，比如小程序
*个人建议：*能不把令牌暴露在浏览器，就不要暴露。
4.3 密码模式（resource owner password credentials ）
4.3.1 基本流程
资源拥有者直接将账号密码告诉第三方应用，第三方应用拿着资源拥有者的账号密码去访问对应资源。
4.3.2 使用场景
客户端非常可信的情况下（第三方永远不可信。可以这样说，OAuth协议的产生就是为了解决第三方不可信背景下的保护资源访问的问题）。
4.4 客户端凭证模式（client credentials ）
这种模式其实已经脱离了OAuth协议的范畴了，纯粹是客户端和资源服务器所在应用在交互。
4.4.1 基本流程
第一步：客户端向授权服务器索取token。 第二步：授权服务器返回token给客户端。
4.4.2 使用场景
客户端所在服务A本身需要服务B的资源，而与用户无关。
