浅谈OAuth2.0授权模式理解（理论+图解）

前言

1，假设我住在一个大型的居民小区。小区有门禁系统。
2，我呢比较喜欢网购，每天都有快递员来送货。
3，快递员想通过门禁系统，进入小区，
4，如果我把自己的密码，告诉快递员，他就拥有了与我同样的权限，这样好像不太合适，安全风险不可控。然后我想取消他进入小区的权力，也很麻烦，我自己的密码也得跟着改了，还得通知其他的快递员。
5，有没有一种办法让快递员自由进入小区，又不把自己的密码告诉快递员，并且他唯一的权限就是送货。

授权机制的设计

1，在门禁卡中增加一个按钮，快递员按这个按钮，去申请授权。
2，我的手机就会显示这个快递员的基本信息，我确认请求属实，告诉门禁系统，我同意给予他进入小区的授权。
3，门禁系统得到我的确认以后，向快递员显示一个进入小区的令牌（access_token）。令牌就是类似密码的一串数字，只在短期内（比如七天）有效。
4，快递员向门禁系统输入令牌，进入小区。

OAuth2.0

把上面的例子搬到互联网中就是OAuth2.0的设计了。

什么是OAuth2.0

在OAuth2.0中“O”是Open的简称，表示“开放”的意思。Auth表示“授权”的意思，所以连起来OAuth表示“开放授权”的意思，简单理解就是，数据的所有者告诉系统，同意授权第三方应用进入系统，获取这些数据。系统从而产生一个短期的进入令牌（access_token），用来代替密码，供第三方应用使用。

三方指的是哪三方？

1. 第三方应用：要获取用户（资源拥有者）存储在服务提供商里的资源的实例，通常是客户端，这里我们用的思否就是第三方应用；
2. 服务提供者：存储用户（资源拥有者）的资源信息的地方，向第三方应用提供用户相关信息的服务方，例如我们登录时的微信、QQ;
3. 用户/资源拥有者：拿三方登录来说，指的是在微信或QQ中注册的用户；

交互流程

1. 用户打第三方开客户端后，第三方客户端要访问服务提供方，要求用户给予授权；
2. 用户同意给予第三方客户端访问服务提供方的授权，并返回一个授权凭证Code；
3. 第三方应用使用第2步获取的授权凭证Code和身份认证信息（appid、appsecret）,向授权认证服务器申请授权令牌（token）；
4. 授权认证服务器验证三方客户端的授权凭证Code码和身份通过后，确认无误，同意授权，并返回一个资源访问的令牌（Access Token）；
5. 第三方客户端使用第4步获取的访问令牌Access Token）向资源服务器请求相关资源；
6. 资源服务器验证访问令牌（Access Token）通过后，将第三方客户端请求的资源返回，同意向客户端开放资源；
7. 下面是时序图：

OAuth2.0的授权模式

授权码模式（authorization code）
简化模式（implicit）
密码模式（resource owner password credentials）
客户端模式（client credentials）

1、授权码模式

步骤如下：
使用微信登录京东，会跳到微信的授权页面。
微信认证验证通过后，回调京东网站提供的回调地址，并带上认证access_token。
京东接收到access_token后，在拿取在微信上注册的client_id 和client_secret，去请求access_token。

简陋的时序图

2、简化模式（隐藏式）

在授权码模式上减去了，获取授权码的步骤，直接返回access_token

步骤如下：
使用微信登录京东，会跳到微信的授权页面。
微信认证验证通过后，回调京东网站提供的回调地址，access_token。

简陋的时序图

3、密码模式

在京东的登录页面上输入微信的用户名和密码进行登录

步骤如下：
在京东的登录页面上输入微信的用户名和密码。
京东携带账号和密码去，微信上认证。
微信认证通过返回access_token给京东。

简陋的时序图

4、客户端模式

客户端以自己的名义，而不是以用户的名义，向"服务提供商"进行认证；在这种模式中，用户直接向客户端注册，客户端以自己的名义要求"服务提供商"提供服务。这里就不适合在叫做京东和微信了，这样不适合理解。

简陋的时序图

总结

四种授权中：
授权码模式：最为复杂，但也是安全系数最高的。
简化模式：不需要获取授权码，适用于静态网页应用。
密码模式：必须信任，不然会寄。
客户端模式：适用于仅由应用本身使用的机密、非用户相关的资源访问。

参考

https://www.ruanyifeng.com/
https://juejin.cn/post/7010636081305485319
聊编程
哪有不对地方，还请指正。