认证授权：OAuth2简介及四种授权模型详解

文章目录

• • @[toc]
  • 简介
  • 一、OAuth2 授权总体流程
  • • 1.认证流程
    • 2.四种角色：
    • 3.四种授权模式
  • 二、授权码模式（Authorization Code Grant）
  • • 1.Client Side
    • 2.Server Side
    • 3.Check Access Token
  • 三、隐式授权模式（Implicit Grant）
  • • Client Side
    • Check Access Token
  • 四、密码模式（Resource Owner Password Credentials Grant）
  • • Client Side
    • Check Access Token
  • 五、客户端模式（Client Credentials Grant）
  • • 1.Server Side
    • 2. Check Access Token
  • 六、授权模式的选型
  • 其他

简介

如今很多互联网应用中，OAuth2 是一个非常重要的认证协议，很多场景下都会用到它，Spring Security 对 OAuth2 协议提供了相应的支持。开发者非常方便的使用 OAuth2 协议

OAuth 是一个开放标准，该标准允许用户让第三方应用访问该用户在某一网站上存储的私密资源 （如头像、照片、视频等），并且在这个过程中无须将用户名和密码提供给第三方应用。通过令牌 （token） 可以实现这一功能。每一个令牌授权一个特定的网站在特定的时间段内允许可访问特定的资源。OAuth 让用户可以授权第三方网站灵活访问它们存储在另外一些资源服务器上的特定信息，而非所有的内容。对于用户而言，我们在互联网应用中最常见的 OAuth 应用就是各种第三方登录，例如 QQ授权登录、微信授权登录、微博授权登录、GitHub 授权登录等。

例如用户想登录 Ruby China ，传统方式是使用用户名和密码但是这样并不安全，因为网站会存储你的用户名密码，这样可能会导致密码泄露。这种授权方式安全隐患很大如果使用 OAuth 协议就能很好地解决这一问题。

oAuth2协议解决了多个网站登录问题，账号密码不安全的问题，比如一些小众的网站就可以不用注册登录，使用 oAuth2，也就是通过第三方向要访问的网站发送请求获取Token，第三方网站每次请求写到Token就可以访问到内容。

注意：OAuth2 是 OAuth 协议的下一个版本，但不兼容 OAth 1.0 ，OAth2 关注客户端开发者的简易性，同时为 Web 应用、桌面应用、移动设备、 IOT 设备提供专门的认证流程。

oAuth2就是对用户的信息进步的保护**，如很多喜欢将所有密码设置为同样的，就可能会泄露，但是通过已经注册过的网站用户信息，来进行授权给第三方网站信息进行登录则免去了注册，oAuth主要做的就是****认证保护用户隐私安全**

一、OAuth2 授权总体流程

角色梳理 ：第三方应用 <--------> 存储用户私密信息应用 ----------> 授权服务器 ------> 资源服务器

整体流程如下

1.认证流程

官网流程 :

• (A) 用户打开客户端以后，客户端要求用户给予授权。

• (B) 用户同意给予客户端授权。

• © 客户端使用上一步获得的授权，向认证服务器申请令牌。

• (D) 认证服务器对用户端进行认证以后，确认无误，同意发放令牌。

• (E) 客户端使用令牌，向资源服务器申请资源。

• (F) 资源服务器确认令牌无误,同意向客户端开放资源。

例子流程:

• 1.用户打开第三方网站如 (京东),用户点击了微信授权登录，此时 就会跳转到 微信的授权页面。
• 2.用户点击授权给京东后，进行授权认证，授权成功会进行回调到京东回调页面。
• 3.授权页面会发起请求向授权服务器索要授权令牌。
• 4.授权服务器将授权令牌进行返回,用户此时可以在第三方网站（京东）向 微信服务器携带令牌获取部分用户信息 。
• 5.用户此时可以在第三方网站（京东）向 微信服务器携带令牌获取部分用户信息 。
• 6.资源服务器将资源返回给第三方网站

2.四种角色：

从上图中我们可以看出六个步骤之中，B是关键，即用户怎么才能给于客户端授权。同时会发现 OAuth2 中包含四种不同角色：

• Client ：第三方应用。

• Resource Owner：资源所有者。

• Authorizetion Server ：授权服务器。

• Resource Server ：资源服务器。

授权服务器和资源服务器可以放一起，但是在如今的互联网和分布的推动下，都是分别存储。

3.四种授权模式

OAuth2 协议一种支持四种不同的授权模式：

• 授权码模式：常见的第三方平台登录功能基本都是使用这种模式。（安全性高）
• 简化模式：简化模式是不需要第三方服务端（客户端）参与，直接在浏览器中向授权服务器申请令牌（token），如果网站是纯静态页面，则可以采用这种方式。
• 密码模式：密码模式是用户把用户名/密码直接告诉客户端，客户端使用在这些信息项授权服务器申请令牌（token）。这需要用户对客户端高度信任，例如客户端应用和服务器提供商就是同一家公司。
• 客户端模式：客户端模式是指客户端使用自己的名义而不是用户的名义向授权服务器提供申请授权。严格来说，客户端模式并不能算作 OAuth 协议解决问题的一种解决方案，但是对于开发者而言，在一些为移动端提供的授权服务器上使用这种模式还是非常方便的。

用的最多的就是 最多的就是授权码模式，无论那种授权模式，其授权流程都是相似的，只不过在个别步骤上有差异而已。如上图所示。

二、授权码模式（Authorization Code Grant）

授权码模式是OAuth2目前最安全最复杂的授权流程，先放一张图，稍做解释

如上图，我们可以看到此流程可大致分为三大部分

• Client Side：用户+客户端与授权服务器的交互
• Server Side：客户端与授权服务器之间的交互
• Check Access Token：客户端与资源服务器之间的交互 + 资源服务器与授权服务器之间的交互

整体上来说，可以用一句话概括授权码模式授权流程，客户端换取授权码，客户端使用授权码换token，客户端使用token访问资源

接下来对这三部分进行一些说明 ：

前提条件：

• 第三方客户端需要提前与资源拥有方（同时也是授权所有方）协商客户端id（client_id），客户端密钥（client_secret）
• 文中暂时未将scope、state等依赖具体框架的内容写进来，这里可以参考Spring Security OAuth2的实现

1.Client Side

客户端换取授权码，这个客户端可以是浏览器，

1.客户端将client_id + 授权模式标识(grant_type) + 回调地址(redirect_uri)拼成url访问授权服务器授权端点

2.授权服务器返回登录界面，要求用户登录（此时用户提交的密码等直接发到授权服务器，进行校验）

3.授权服务器返回授权审批界面，用户授权完成

4.授权服务器返回授权码到回调地址

2.Server Side

客户端使用授权码换token

1. 客户端接收到授权码，并使用授权码 + client_id + client_secret访问授权服务器颁发token端点
2. 授权服务器校验通过，颁发token返回给客户端
3. 客户端保存token到存储器（推荐cookie）

3.Check Access Token

客户端使用token访问资源

1. 客户端在请求头中添加token，访问资源服务器
2. 资源服务器收到请求，先调用校验token的方法（可以是远程调用授权服务器校验端点，也可以直接访问授权存储器手动校对）
3. 资源服务器校验成功，返回资源

这里的说明省去了一些参数，如scope(请求token的作用域)、state(用于保证请求不被CSRF)、redirect_uri(授权服务器回调uri)，先理解概念，实现的时候再去要求

三、隐式授权模式（Implicit Grant）

隐式授权模式大致可分为两部分：

• Client Side：用户+客户端与授权服务器的交互
• Check Access Token：客户端与资源服务器之间的交互 + 资源服务器与授权服务器之间的交互

用一句话概括隐式授权模式授权流程

客户端让用户登录授权服务器换token，客户端使用token访问资源

Client Side

客户端让用户登录授权服务器换token

1. 客户端（浏览器或单页应用）将client_id + 授权模式标识(grant_type)+ 回调地址(redirect_uri)拼成url访问授权服务器授权端点
2. 授权服务器跳转用户登录界面，用户登录
3. 用户授权
4. 授权服务器访问回调地址返回token给客户端

Check Access Token

客户端使用token访问资源

1. 客户端在请求头中添加token，访问资源服务器
2. 资源服务器收到请求，先调用校验token的方法（可以是远程调用授权服务器校验端点，也可以直接访问授权存储器手动校对）
3. 资源服务器校验成功，返回资源

四、密码模式（Resource Owner Password Credentials Grant）

密码模式大体上也分为两部分：

• Client Side: 用户与客户端交互，客户端与授权服务器交互
• Check Access Token:客户端与资源服务器之间的交互 + 资源服务器与授权服务器之间的交互

一句话概括用户名密码模式流程：

用户在客户端提交账号密码换token，客户端使用token访问资源

Client Side

用户在客户端提交账号密码换token

1. 客户端要求用户登录
2. 用户输入密码，客户端将表单中添加客户端的client_id + client_secret发送给授权服务器颁发token端点
3. 授权服务器校验用户名、用户密码、client_id、client_secret，均通过返回token到客户端
4. 客户端保存token

Check Access Token

客户端使用token访问资源

1. 客户端在请求头中添加token，访问资源服务器
2. 资源服务器收到请求，先调用校验token的方法（可以是远程调用授权服务器校验端点，也可以直接访问授权存储器手动校对）
3. 资源服务器校验成功，返回资源

五、客户端模式（Client Credentials Grant）

客户端模式大体上分为两部分：

• Server Side: 客户端与授权服务器之间的交互
• Check Access Token: 客户端与资源服务器，资源服务器与授权服务器之间的交互

一句话概括客户端模式授权流程：客户端使用自己的标识换token，客户端使用token访问资源

1.Server Side

客户端使用自己的标识换token

1. 客户端使用client_id + client_secret + 授权模式标识访问授权服务器的颁发token端点
2. 授权服务器校验通过返回token给客户端
3. 客户端保存token

2. Check Access Token

客户端使用token访问资源

1. 客户端在请求头中添加token，访问资源服务器
2. 资源服务器收到请求，先调用校验token的方法（可以是远程调用授权服务器校验端点，也可以直接访问授权存储器手动校对）
3. 资源服务器校验成功，返回资源

六、授权模式的选型

考虑到授权场景的多样性，可以参考以下两种选型方式

• 按授权需要的多端情况

• 按客户端类型与所有者

其他

参考：https://blog.csdn.net/weixin_52834606/article/details/126995138

https://www.cnblogs.com/hellxz/p/oauth2_process.html

https://tools.ietf.org/html/rfc6749