举个例子：

场景：我要玩游戏，游戏可以获取到我的微信好友是否也在玩这个游戏。那么我需要同意授权给游戏获取到我的微信好友。

角色：

我本人 - 资源拥有者；
游戏 - 客户应用；
微信 - 资源服务器；
授权服务器 - 管理和颁发Access Token

流程：

游戏向授权服务器请求要Access Token，就是要拿到相关的权限去拿到微信好友
授权服务器询问我是否同意授权给游戏拿到微信好友信息
我选择同意赋予权限
授权服务器得知我同意后，生成Access Token并颁发给游戏
游戏拿到Access Token后，带上Access Token去请求微信要我的微信好友信息
微信校验Access Token，校验通过之后，则把我的微信好友信息返回给游戏。

从上面的流程来看，最关键的一步就是授权和Access Token，那再怎么样授权才能拿到Access Token呢？从这点切入就会了解到OAuth2的四种授权方式。

6 OAuth2的授权方式（Flows）

6.1 授权码模式（Authorization Code）

四种模式中最复杂的一种，也是最安全的，也是目前应用最多的模式。

(A) 浏览器把客户应用的客户标识等信息发送到授权服务器，并且把重定向的url也一起发送到授权服务器。
(B) 浏览器得到资源拥有者的同意认证请求后（这个例子我假设资源拥有者是同意授权的），把用户认证信息发送到授权服务器。
(C) 授权服务器校验用户认证信息，校验正确之后颁发授权码给浏览器，浏览器接受后再返回给客户应用。
(D) 客户应用拿着授权码以及重定向的url给授权服务器。
(E) 授权服务器校验授权码等信息无误之后，颁发Access Token和Refresh Token（可选）给客户应用。

特点

客户通过前端获取授权码
客户通过后端使用授权码去交换Access Token和Refresh Token（可选）
最安全的是Access Token不会经过用户代理（浏览器）

此流程图是自己理解过后画的，如要官方流程图，请参考
RFC 6749 - The OAuth 2.0 Authorization Frameworkhttps://datatracker.ietf.org/doc/html/rfc6749#section-4.1

重定向的url是客户应用自己定义的，比如要登录https:web.com ，中途需要认证授权，那么重定向url就是https:web.com。是认证成功之后重定向的url。

6.2 简化模式（Implicit）

比授权码模式简单一点，没有中间的授权码交换，适用于单页应用，没有后台的应用场景。

(A) 浏览器把客户应用的客户标识等信息发送到授权服务器，并且把重定向的url也一起发送到授权服务器。
(B) 浏览器得到资源拥有者的同意认证请求后（这个例子我假设资源拥有者是同意授权的），把用户认证信息发送到授权服务器。
(C) 授权服务器校验认证信息无误后，颁发Access Token和返回重定向url
(D) 浏览器接受到Access Token后，并返回到客户应用。

特点

适用于公开的浏览器单页应用。
前端可以直接拿到Access Token，因此也容易受到安全攻击。
不支持Refresh Token

起码画的流程图我没有照着官网画，我省略了一个Web托管资源服务器，我觉得如果加上这个对于刚接触的人来说有点难理解。有兴趣的可在官网上查看

https://datatracker.ietf.org/doc/html/rfc6749#section-4.2https://datatracker.ietf.org/doc/html/rfc6749#section-4.2

6.3 密码模式（Resource Owner Credentials）

(A) 资源拥有者向客户应用提供用户名密码。
(B) 客户应用把用户名密码发送到授权服务器。
(C)授权服务器校验用户信息通过后，直接颁发Access Token和Refresh Token（可选）。

特点

使用账号密码登录的应用，比如桌面APP，一般适用于企业内部，是可以高度信任的。
使用账号密码作为授权方式从授权服务器上获取Access Token。
可以支持Refresh Token但是不推荐使用。

6.4 客户端模式（Client Credentials）

这种也比较简单，甚至都没有资源拥有者的参与，直接由客户应用将客户的认证信息发送到授权服务器，授权服务器校验通过之后返回Access Token给客户应用。这种适用于机器对机器（后端）的场景。

(A) 客户应用把客户凭证发送到授权服务器
(B) 授权服务器校验通过之后颁发Access Token

特点

只有后端渠道
该模式支持共享密码或者证书，因为客户凭证可以使用对称或非对称加密。

7 刷新令牌（Refresh Token）

上文的几种模式中都提到了一个刷新令牌，也就是Refresh Token，那么Refresh Token是什么时候可以用到呢，以及目的是什么呢？

(A) 一般选择授权码模式
(B) 校验信息通过之后颁发Access Token和Refresh Token
(C) 客户应用把拿到的Access Token给到资源服务器
(D) 资源服务器校验Access Token，验证其有效后把资源返回给客户应用
(E) 过了一段时间，客户应用又拿着Access Token去请求资源
(F) 资源服务器校验Access Token发现已经过期，把报错信息返回给客户应用
(G) 客户应用拿Refresh Token给授权服务器，请求一个新的Access Token
(H) 授权服务器校验Refresh Token之后，重新生成了新的Access Token和新的Refresh Token（可选）

目的：简化获取Access Token流程，不需要每次都走完成的获取Access Token的流程，快速的获取新的Token。

8 授权流程渠道（Channels）

根据角色之间的交互可以划分渠道。

资源拥有者，客户应用，授权服务器参与的称为前端渠道。
资源服务器，客户应用，授权服务器参与的称为后端渠道。

9 客户应用类型

我们可以把应用大致分为两类，一个是公开应用，一个是私密应用。

公开应用：主要是指单页应用和原生APP。特点是都是在客户端，用户可以直接接触到这些应用。针对这种应用就不能把一些凭证信息（密码之类的）存在这里，不然可能会泄露凭证信息，所以一般只保存用户的标识。
私密应用：主要是Web服务器端的应用，还有机器对机器。这种是比较安全和私密的，不仅可以存储用户标识，还可以存储用户凭证，把密码等私密信息存放到后端服务器上。

10 令牌类型

授权码(Authorization Code Token)：在授权码模型中使用，用于交换获取Access Token和Refresh Token。
访问令牌(Access Token)：代表资源拥有者直接去访问资源。
刷新令牌(Refresh Token)：用于去授权服务器获取一个新的Access Token
Bearer Token：通用型Token，不管是谁拿到该Token都能访问资源。
PoP Token(Proof of Possession)：可以校验客户用户应用是否对Token有明确的拥有权。(因为Bearer Token有时候会存在问题，毕竟谁拿到Token都能用，所以衍生出了PoP Token，可以校验用户是不是有权限使用这个Token）

11 如何选择授权类型

如果是机器需要访问资源，可以选择客户端模式；
如果是用户需要访问资源
如果客户类型是Web服务器端应用，可以选择授权码模式；
如果是原生App
第一方原生APP（可以理解为同一个公司旗下）
选择用户密码模式
第三方原生App
选择客户端模式
如果是单页应用SPA
第一方单页应用SPA
选择用户密码模式
第三方单页应用SPA
选择简化模式

12 授权服务器的组成

典型的授权服务的组成，是有四个主要端点组成，也就是四大功能。

授权端点：客户端授权时，访问授权端点
Token端点：通过授权以后，生成Token
校验端点：校验Token是否合法
吊销端点：对非法客户应用进行吊销

13 对OAuth2的误解

OAuth没有支持HTTP以外的协议。
OAuth不是一个认证协议（管授权不管认证，但是可以扩充支持认证）。
OAuth没有定义授权代理机制（授权是应用开发方和资源服务器去管理的）。
OAuth没有定义Token格式。
OAuth2没有定义加密方法。
OAuth2不是单个协议。
OAuth2只是一个授权框架，仅用于授权代理。

文档链接

OAuth2 官网https://oauth.net/2/

阮一峰的网络日志 - 理解OAuth 2.0https://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html The OAuth 2.0 Authorization Frameworkhttps://datatracker.ietf.org/doc/html/rfc6749#section-1.3.1

声明：本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：【wpsshop博客】