认什么是 OAuth2
目录：
参考链接：https://www.cnblogs.com/crazymakercircle/p/14488160.html (opens new window)
# 什么是OAuth2 ？
OAuth2 是一个授权（Authorization）协议，是一个关于授权的开放标准。核心思路是通过各类认证手段认证用户身份，并颁发令牌（token），使得第三方应用可以使用该令牌在限定时间、限定范围访问指定资源。获取令牌的方式主要有四种，分别是**授权码模式、简单模式、密码模式、客户端模式**，
OAuth2 主要涉及的RFC规范有【RFC6749（整体授权框架）】、【RFC6750（令牌使用）】、【RFC6819（威胁模型）】这几个，一般我们需要了解的就是**RFC6749**。
下面这张图来源于 OAuth 2.0 authorization framework RFC Document (opens new window)，是OAuth2的一个抽象流程。
+--------+ +---------------+
| |--(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 ---| |
+--------+ +---------------+
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
名词理解：
- Resource Owner：资源所有者，即用户
- Client：客户端应用程序（Application）
- Authorization Server：授权服务器
- Resource Server：资源服务器
流程理解：
（A） 用户连接客户端应用程序以后，客户端应用程序要求用户给予授权；
（B） 用户同意给予客户端应用程序授权（Grant）；
（C） 客户端应用程序使用上一步获得的授权（Grant），向授权服务器申请令牌（Token）；
（D） 授权服务器对客户端应用程序的授权（Grant）进行验证后，确认无误，发放令牌（Token）；
（E） 客户端应用程序使用令牌（Token），向资源服务器申请获取资源；
（F） 资源服务器确认令牌（Token）无误，同意向客户端应用程序开放资源。
关键：获取授权（Grant）
# OAuth2 的授权类型
- Authorization Code（授权码模式）：
功能最完整、流程最严密的授权模式。通过第三方应用程序服务器与认证服务器进行互动。广泛用于各种第三方认证。
- Implicit（简化模式）：
不通过第三方应用程序服务器，直接在浏览器中向认证服务器申请令牌，更加适用于移动端的App及没有服务器端的第三方单页面应用。
- Resource Owner Password（密码模式）：
用户向客户端服务器提供自己的用户名和密码，用户对客户端高度信任的情况下使用，比如公司、组织的内部系统，SSO。
- Client Credentials（客户端模式）：
客户端服务器以自己的名义，而不是以用户的名义，向认证服务器进行认证。
最常用的 Resource Owner Password（密码模式）和 Authorization Code（授权码模式）。此外，还有一个模式叫 Refresh Token，以下介绍：
# Resource Owner Password（密码模式）
+----------+
| Resource |
| Owner |
| |
+----------+
v
| Resource Owner
(A) Password Credentials
|
v
+---------+ +---------------+
| |>--(B)---- Resource Owner ------->| |
| | Password Credentials | Authorization |
| Client | | Server |
| |<--(C)---- Access Token ---------<| |
| | (w/ Optional Refresh Token) | |
+---------+ +---------------+
Figure : Resource Owner Password Credentials Flow
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
步骤如下：
（A） 用户（Resource Owner）向客户端（Client）提供用户名和密码。
（B） 客户端将用户名和密码发给认证服务器（Authorization Server），向后者请求令牌（Token）。
（C） 认证服务器确认无误后，向客户端提供访问令牌（Token）。
# Authorization Code（授权码模式）
+----------+
| 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)
Note: The lines illustrating steps (A), (B), and (C) are broken into
two parts as they pass through the user-agent.
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
步骤如下：
（A） 用户（Resource Owner）通过用户代理（User-Agent）访问客户端（Client），客户端索要授权，并将用户导向认证服务器（Authorization Server）。
（B） 用户选择是否给予客户端授权。
（C） 假设用户给予授权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个授权码。
（D） 客户端收到授权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。
（E） 认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。这一步也对用户不可见。
# Refresh Token（令牌刷新模式）
+--------+ +---------------+
| |--(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 +---------------+
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
当我们申请token后，Authorization Server 不仅给了我们 Access Token，还有 Refresh Token。
当 Access Token 过期后，我们用 Refresh Token 访问 /refresh 端点就可以拿到新的 Access Token 了。