OAuth2.0 是什么？

本文内容如有错误、不足之处，欢迎技术爱好者们一同探讨，在本文下面讨论区留言，感谢。

简述

OAuth2.0 是 OAuth 协议的延续版本，但不向前兼容 OAuth 1.0 (即完全废止了 OAuth1.0 )。 OAuth 2.0 关注客户端开发者的简易性。要么通过组织在资源拥有者和 HTTP 服务商之间的被批准的交互动作代表用户，要么允许第三方应用代表用户获得访问的权限。同时为 Web 应用，桌面应用和手机，和起居室设备提供专门的认证流程。2012年10月，OAuth 2.0 协议正式发布为 RFC 6749 。
--------------------------------------- 百度百科

授权

OAuth 框架设计的核心是授权这一概念，授权是指领导者授予下属一定的权力和责任，使下属在一定的监督下，有一定的自主权，去完成被授予的任务。实质是让别人去做原本属于自己的事情，自身仍有监督和最终的责任。OAuth 框架所设计的授权概念也是这么一回事，主要是被授权者（第三方），拿到授权者（客户）给与的权利（访问数据的权限）通过认证机制得到资源所有者的认可后，得到资源的过程。

框架图

时序图

协议角色和流程

• Client 第三方客户端
• Resource Owner 资源所有者
• Authorization Server 认证服务器
• Resource Server 资源服务器

    +--------+                               +---------------+
    |        |--(A)- Authorization Request ->|   Resource    |
    |        |                               |     Owner     |
    |        |<-(B)-- Authorization Grant ---|               |
    |        |                               +---------------+
    |        |
    |        |                               +---------------+
    |        |--(C)-- Authorization Grant -->| Authorization |
    | Client |                               |     Server    |
    |        |<-(D)----- Access Token -------|               |
    |        |                               +---------------+
    |        |
    |        |                               +---------------+
    |        |--(E)----- Access Token ------>|    Resource   |
    |        |                               |     Server    |
    |        |<-(F)--- Protected Resource ---|               | 
    +--------+                               +---------------+

               Figure 1: Abstract Protocol Flow

1. Authorization Request 认证请求，第三方向用户发送一个认证请求，例如：用户想要登录 A 软件，用户想使用经常使用的交友软件登录 B 软件，那么 A 软件会向用户的 B 软件发送一个认证请求，用户点击通过了认证请求。
2. Authorization Grant 认证授权，B软件向A软件发送一个认证授权，这时候 A 软件就可以利用这个认证授权去 B 软件的认证服务获取一个有时间限制和访问权限限制的令牌。
3. Access Token 通行令牌，A 软件拿着认证服务发的通行令牌跑到资源服务器获取资源（头像和昵称）
4. Protected Resource 受保护的资源，资源服务器根据通行令牌的权限返回权限内的资源给客户端。

密码和授权

为什么要使用授权而不是直接使用密码呢！

授权 令牌（token）与密码（password）的作用是一样的，都可以进入系统，但是差异见下表。

令牌	密码
令牌有时间到期会自动失效，用户自己无法修改	密码一般长期有效，用户不修改，就不会发生变化
令牌可以被数据所有者撤销，会立即失效	密码不允许被他人撤销
令牌有权限范围	密码是完整权限

为了防止密码存储到第三方应用服务器中，导致密码泄密和信息泄密，因此，使用授权模式可以很放心的使用授权第三方应用而不用担心第三方应用对我们的信息进行采集。

授权信息

名称	字段
应用名称	app_name
应用网站	app_uri
重定向 URI 或回调 URL	redirect_uri
客户端标识	client_id
客户端密钥	client_secret

授权方式

OAuth 2.0 规定了四种获得令牌的流程。根据应用需要选择一种，向第三方应用颁发令牌。下面就是这四种授权方式。

• 授权码（authorization-code）
• 隐藏式（implicit）
• 密码式（password）：
• 客户端凭证（client credentials）

注意，不管哪一种授权方式，第三方应用申请令牌之前，须到认证系统备案，说明自身应用的身份，将会拿到两个身份识别码：客户端 ID（client_id）和客户端密钥（client_secret）。服务提供商不能信任每一个前来索要授权的第三方平台，因此需要第三方平台注册客户端ID 和客户端密钥同时进行备案。

其中，重点介绍授权码模式，安全性高，泄密性低。
剩下的三种模式简单介绍下应用场景：

模式	场景
隐藏式	WEB浏览器设计
密码式	遗留项目
客户端凭证	后台API服务消费者

这里说下密码式的应用场景：遗留项目，对于之前使用第三方登录，通过的是用户名和密码的模式，这些项目由于维护问题，可以使用密码模式来使用 OAuth2.0 框架。

授权码模式

授权码模式（authorization code）参数

字段	是否必填	描述
response_type	必须	固定为 code，表示这是一个授权码请求。
client_id	必须	在授权服务器注册应用后得到的唯一标识
redirect_uri	可选	通过客户端注册的重定向 URI（一般要求且与注册时一致）。
scope	可选	请求资源范围，多个空格隔开。
state	可选	（推荐），如果存在，原样返回给客户端。

授权码模式示意图：

     +----------+
     | Resource |
     |   Owner  |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier      +---------------+
     |         -+----(A)-- & Redirection URI ---->|               |
     |  User-   |                                 | Authorization |
     |  Agent  -+----(B)-- User authenticates --->|     Server    |
     |          |                                 |               |
     |         -+----(C)-- Authorization Code ---<|               |
     +-|----|---+                                 +---------------+
       |    |                                         ^      v
      (A)  (C)                                        |      |
       |    |                                         |      |
       ^    v                                         |      |
     +---------+                                      |      |
     |         |>---(D)-- Authorization Code ---------'      |
     |  Client |          & Redirection URI                  |
     |         |                                             |
     |         |<---(E)----- Access Token -------------------'
     +---------+       (w/ Optional Refresh Token)

使用 Refresh 令牌，对 Access 令牌进行更新，下面是使用过程示意图：

 +--------+                                           +---------------+
 |        |--(A)------- Authorization Grant --------->|               |
 |        |                                           |               |
 |        |<-(B)----------- Access Token -------------|               |
 |        |               & Refresh Token             |               |
 |        |                                           |               |
 |        |                            +----------+   |               |
 |        |--(C)---- Access Token ---->|          |   |               |
 |        |                            |          |   |               |
 |        |<-(D)- Protected Resource --| Resource |   | Authorization |
 | Client |                            |  Server  |   |     Server    |
 |        |--(E)---- Access Token ---->|          |   |               |
 |        |                            |          |   |               |
 |        |<-(F)- Invalid Token Error -|          |   |               |
 |        |                            +----------+   |               |
 |        |                                           |               |
 |        |--(G)----------- Refresh Token ----------->|               |
 |        |                                           |               |
 |        |<-(H)----------- Access Token -------------|               |
 +--------+           & Optional Refresh Token        +---------------+

              Figure 2: Refreshing an Expired Access Token

重点在 D 和 F 的区别，D 是正常获得受保护资源， F 访问资源失败，原因是授权时间过期，因此使用 Refresh Token到授权服务器获取一个新的 Access Token 。

2.0 与 1.0

OAuth2.0 框架与 OAuth1.0 框架的区别：

	1.0	2.0
授权过程	1.客户端到授权服务器请求一个授权令牌(requesttoken&secret) 2.引导用户到授权服务器请求授权 3.用访问令牌到授权服务器换取访问令牌(accesstoken&secret) 4.用访问令牌去访问得到授权的资源	1.用户到授权服务器，请求授权，然后返回授权码(AuthorizationCode) 2.客户端由授权码到授权服务器换取访问令牌(access token) 3.用访问令牌去访问得到授权的资源
安全性	每个token都有一个加密	要求使用https协议
过程是否简单	只有一个用户授权流程	分考虑了客户端的各种子态，因而提供了多种途径获取访问令牌，有： 授权码、客户端私有证书、资源拥有者密码证书、刷新令牌等方式， 而且验证过程更为简洁。

总结

本文简单介绍 OAuth2.0 框架的设计理念和思想，以及具体实现的四种模式，重点介绍了授权码模式，通过示意图可以更方便的理解。

参考资料

OAuth 2.0 的四种方式

• https://www.jianshu.com/p/0d61b23f41cf

OAuth2.0 协议

• http://slides.com/biezhi/oauth2/fullscreen

OAuth 2.0 的一个简单解释

• http://www.ruanyifeng.com/blog/2019/04/oauth_design.html

关于 OAuth 以及 OAuth1.0 与 OAuth2.0 的区别

• https://blog.csdn.net/u013436121/article/details/23631885