周一發(fā)了Spring Security 系列第一篇文章，有妹子留言說看了很多文章，始終沒明白OAuth2.0，這次陳某花了兩天時(shí)間，整理了OAuth2.0相關(guān)的知識，結(jié)合認(rèn)證授權(quán)服務(wù)+資源服務(wù)，一次性給大家嘮明白！

這是《Spring Security 進(jìn)階》第2篇文章，往期文章如下：

• 實(shí)戰(zhàn)！Spring Boot Security+JWT前后端分離架構(gòu)登錄認(rèn)證！

本篇文章介紹一下OAuth2.0相關(guān)的知識點(diǎn)，并且手把手帶大家搭建一個(gè)認(rèn)證授權(quán)中心、資源服務(wù)進(jìn)行OAuth2.0四種授權(quán)模式的驗(yàn)證，案例源碼詳細(xì)，一梭子帶大家了解清楚。

本篇文章的案例源碼項(xiàng)目架構(gòu)為：Spring Boot + Spring Cloud Alibaba + Spring Security ，Spring Cloud Alibaba有不了解可以看下陳某的往期《Spring Cloud 進(jìn)階》文章：

• 五十五張圖告訴你微服務(wù)的靈魂擺渡者Nacos究竟有多強(qiáng)？
• openFeign奪命連環(huán)9問，這誰受得了？
• 阿里面試這樣問：Nacos、Apollo、Config配置中心如何選型？這10個(gè)維度告訴你！
• 阿里面試敗北：5種微服務(wù)注冊中心如何選型？這幾個(gè)維度告訴你！
• 阿里限流神器Sentinel奪命連環(huán) 17 問？
• 對比7種分布式事務(wù)方案，還是偏愛阿里開源的Seata，真香！(原理+實(shí)戰(zhàn))
• Spring Cloud Gateway奪命連環(huán)10問？
• Spring Cloud Gateway 整合阿里 Sentinel網(wǎng)關(guān)限流實(shí)戰(zhàn)！
• 分布式鏈路追蹤之Spring Cloud Sleuth奪命連環(huán)9問？
• 3本書了，7萬+字，10篇文章，《Spring Cloud 進(jìn)階》基礎(chǔ)版 PDF

文章目錄如下：

為什么需要OAuth2.0？

編碼永遠(yuǎn)都是為了解決生產(chǎn)中的問題，想要理解為什么需要OAuth2，當(dāng)然要從實(shí)際生活出發(fā)。

舉個(gè)例子：小區(qū)的業(yè)主點(diǎn)了一份外賣，但是小區(qū)的門禁系統(tǒng)不給外賣人員進(jìn)入，此時(shí)想要外賣員進(jìn)入只能業(yè)主下來開門或者告知門禁的密碼。

密碼告知外賣員豈不是每次都能憑密碼進(jìn)入小區(qū)了，這明顯造成了安全隱患。

那么有沒有一種方案：既能不泄露密碼，也能讓外賣小哥進(jìn)入呢？

于是此時(shí)就想到了一個(gè)授權(quán)機(jī)制，分為以下幾個(gè)步驟：

1. 門禁系統(tǒng)中新增一個(gè)授權(quán)按鈕，外賣小哥只需要點(diǎn)擊授權(quán)按鈕呼叫對應(yīng)業(yè)主
2. 業(yè)主收到小哥的呼叫，知道小哥正在要求授權(quán)，于是做出了應(yīng)答授權(quán)
3. 此時(shí)門禁系統(tǒng)彈出一個(gè)密碼（類似于access_token），有效期30分鐘，在30分鐘內(nèi)，小哥可以憑借這個(gè)密碼進(jìn)入小區(qū)。
4. 小哥輸入密碼進(jìn)入小區(qū)

另外這個(gè)授權(quán)的密碼不僅可以通過門禁，還可以通過樓下的門禁，這就非常類似于網(wǎng)關(guān)和微服務(wù)了。

令牌和密碼的區(qū)別？

上述例子中令牌和密碼的作用是一樣的，都可以進(jìn)入小區(qū)，但是存在以下幾點(diǎn)差異：

1. 時(shí)效不同：令牌一般都是存在過期時(shí)間的，比如30分鐘后失效，這個(gè)是無法修改的，除非重新申請授權(quán)；而密碼一般都是永久的，除非主人去修改
2. 權(quán)限不同：令牌的權(quán)限是有限的，比如上述例子中，小哥獲取了令牌，能夠打開小區(qū)的門禁、業(yè)主所在的樓下門禁，但是可能無法打開其它幢的門禁；
3. 令牌可以撤銷：業(yè)主可以撤銷這個(gè)令牌的授權(quán)，一旦撤銷了，這個(gè)令牌也就失效了，無法使用；但是密碼一般不允許撤銷。

什么是OAuth2？

OAuth 是一個(gè)開放標(biāo)準(zhǔn)，該標(biāo)準(zhǔn)允許用戶讓第三方應(yīng)用訪問該用戶在某一網(wǎng)站上存儲的私密資源（如頭像、照片、視頻等），而在這個(gè)過程中無需將用戶名和密碼提供給第三方應(yīng)用。實(shí)現(xiàn)這一功能是通過提供一個(gè)令牌（token），而不是用戶名和密碼來訪問他們存放在特定服務(wù)提供者的數(shù)據(jù)。

采用令牌（token）的方式可以讓用戶靈活的對第三方應(yīng)用授權(quán)或者收回權(quán)限。

OAuth2 是 OAuth 協(xié)議的下一版本，但不向下兼容 OAuth 1.0。

傳統(tǒng)的 Web 開發(fā)登錄認(rèn)證一般都是基于 session 的，但是在前后端分離的架構(gòu)中繼續(xù)使用 session 就會有許多不便，因?yàn)橐苿佣耍ˋndroid、iOS、微信小程序等）要么不支持 cookie（微信小程序），要么使用非常不便，對于這些問題，使用 OAuth2 認(rèn)證都能解決。

對于大家而言，我們在互聯(lián)網(wǎng)應(yīng)用中最常見的 OAuth2 應(yīng)該就是各種第三方登錄了，例如 QQ 授權(quán)登錄、微信授權(quán)登錄、微博授權(quán)登錄、GitHub 授權(quán)登錄等等。

OAuth2.0的四種模式？

OAuth2.0協(xié)議一共支持 4 種不同的授權(quán)模式：

1. 授權(quán)碼模式：常見的第三方平臺登錄功能基本都是使用這種模式。
2. 簡化模式：簡化模式是不需要客戶端服務(wù)器參與，直接在瀏覽器中向授權(quán)服務(wù)器申請令牌（token），一般如果網(wǎng)站是純靜態(tài)頁面則可以采用這種方式。
3. 密碼模式：密碼模式是用戶把用戶名密碼直接告訴客戶端，客戶端使用說這些信息向授權(quán)服務(wù)器申請令牌（token）。這需要用戶對客戶端高度信任，例如客戶端應(yīng)用和服務(wù)提供商就是同一家公司，自己做前后端分離登錄就可以采用這種模式。
4. 客戶端模式：客戶端模式是指客戶端使用自己的名義而不是用戶的名義向服務(wù)提供者申請授權(quán)，嚴(yán)格來說，客戶端模式并不能算作 OAuth 協(xié)議要解決的問題的一種解決方案，但是，對于開發(fā)者而言，在一些前后端分離應(yīng)用或者為移動端提供的認(rèn)證授權(quán)服務(wù)器上使用這種模式還是非常方便的。

1、授權(quán)碼模式

這種方式是最常用的流程，安全性也最高，它適用于那些有后端的 Web 應(yīng)用。授權(quán)碼通過前端傳送，令牌則是儲存在后端，而且所有與資源服務(wù)器的通信都在后端完成。這樣的前后端分離，可以避免令牌泄漏。

令牌獲取的流程如下：

上圖中涉及到兩個(gè)角色，分別是客戶端、認(rèn)證中心，客戶端負(fù)責(zé)拿令牌，認(rèn)證中心負(fù)責(zé)發(fā)放令牌。

但是不是所有客戶端都有權(quán)限請求令牌的，需要事先在認(rèn)證中心申請，比如微信并不是所有網(wǎng)站都能直接接入，而是要去微信后臺開通這個(gè)權(quán)限。

至少要提前向認(rèn)證中心申請的幾個(gè)參數(shù)如下：

1. client_id：客戶端唯一id，認(rèn)證中心頒發(fā)的唯一標(biāo)識
2. client_secret：客戶端的秘鑰，相當(dāng)于密碼
3. scope：客戶端的權(quán)限
4. redirect_uri：授權(quán)碼模式使用的跳轉(zhuǎn)uri，需要事先告知認(rèn)證中心。

1、請求授權(quán)碼

客戶端需要向認(rèn)證中心拿到授權(quán)碼，比如第三方登錄使用微信，掃一掃登錄那一步就是向微信的認(rèn)證中心獲取授權(quán)碼。

請求的url如下：

/oauth/authorize?client_id=&response_type=code&scope=&redirect_uri=

上述這個(gè)url中攜帶的幾個(gè)參數(shù)如下：

• client_id：客戶端的id，這個(gè)由認(rèn)證中心分配，并不是所有的客戶端都能隨意接入認(rèn)證中心
• response_type：固定值為code，表示要求返回授權(quán)碼。
• scope：表示要求的授權(quán)范圍，客戶端的權(quán)限
• redirect_uri：跳轉(zhuǎn)的uri，認(rèn)證中心同意或者拒絕授權(quán)跳轉(zhuǎn)的地址，如果同意會在uri后面攜帶一個(gè)code=xxx，這就是授權(quán)碼

2、返回授權(quán)碼

第1步請求之后，認(rèn)證中心會要求登錄、是否同意授權(quán)，用戶同意授權(quán)之后直接跳轉(zhuǎn)到redirect_uri（這個(gè)需要事先在認(rèn)證中心申請配置），授權(quán)碼會攜帶在這個(gè)地址后面，如下：

http://xxxx?code=NMoj5y

上述鏈接中的NMoj5y就是授權(quán)碼了。

3、請求令牌

客戶端拿到授權(quán)碼之后，直接攜帶授權(quán)碼發(fā)送請求給認(rèn)證中心獲取令牌，請求的url如下：

/oauth/token?
client_id=&
client_secret=&
grant_type=authorization_code&
code=NMoj5y&
redirect_uri=

相同的參數(shù)同上，不同參數(shù)解析如下：

• grant_type：授權(quán)類型，授權(quán)碼固定的值為authorization_code
• code：這個(gè)就是上一步獲取的授權(quán)碼

4、返回令牌

認(rèn)證中心收到令牌請求之后，通過之后，會返回一段JSON數(shù)據(jù)，其中包含了令牌access_token，如下：

{    
"access_token":"ACCESS_TOKEN",
"token_type":"bearer",
"expires_in":2592000,
"refresh_token":"REFRESH_TOKEN",
"scope":"read",
"uid":100101
}

access_token則是頒發(fā)的令牌，refresh_token是刷新令牌，一旦令牌失效則攜帶這個(gè)令牌進(jìn)行刷新。

2、簡化模式

這種模式不常用，主要針對那些無后臺的系統(tǒng)，直接通過web跳轉(zhuǎn)授權(quán)，流程如下圖：

這種方式把令牌直接傳給前端，是很不安全的。因此，只能用于一些安全要求不高的場景，并且令牌的有效期必須非常短，通常就是會話期間（session）有效，瀏覽器關(guān)掉，令牌就失效了。

1、請求令牌

客戶端直接請求令牌，請求的url如下：

/oauth/authorize?
response_type=token&
client_id=CLIENT_ID&
redirect_uri=CALLBACK_URL&
scope=

這個(gè)url正是授權(quán)碼模式中獲取授權(quán)碼的url，各個(gè)參數(shù)解析如下：

• client_id：客戶端的唯一Id
• response_type：簡化模式的固定值為token
• scope：客戶端的權(quán)限
• redirect_uri：跳轉(zhuǎn)的uri，這里后面攜帶的直接是令牌，不是授權(quán)碼了。

2、返回令牌

認(rèn)證中心認(rèn)證通過后，會跳轉(zhuǎn)到redirect_uri，并且后面攜帶著令牌，鏈接如下：

https://xxxx#token=NPmdj5

#token=NPmdj5這一段后面攜帶的就是認(rèn)證中心攜帶的，令牌為NPmdj5。

3、密碼模式

密碼模式也很簡單，直接通過用戶名、密碼獲取令牌，流程如下：

1、請求令牌

認(rèn)證中心要求客戶端輸入用戶名、密碼，認(rèn)證成功則頒發(fā)令牌，請求的url如下：

/oauth/token?
grant_type=password&
username=&
password=&
client_id=&
client_secret=

參數(shù)解析如下：

• grant_type：授權(quán)類型，密碼模式固定值為password
• username：用戶名
• password：密碼
• client_id：客戶端id
• client_secret：客戶端的秘鑰

2、返回令牌

上述認(rèn)證通過，直接返回JSON數(shù)據(jù)，不需要跳轉(zhuǎn)，如下：

{    
"access_token":"ACCESS_TOKEN",
"token_type":"bearer",
"expires_in":2592000,
"refresh_token":"REFRESH_TOKEN",
"scope":"read",
"uid":100101
}

access_token則是頒發(fā)的令牌，refresh_token是刷新令牌，一旦令牌失效則攜帶這個(gè)令牌進(jìn)行刷新。

4、客戶端模式

適用于沒有前端的命令行應(yīng)用，即在命令行下請求令牌。

這種方式給出的令牌，是針對第三方應(yīng)用的，而不是針對用戶的，即有可能多個(gè)用戶共享同一個(gè)令牌。

流程如下：

1、請求令牌

請求的url為如下：

/oauth/token?
grant_type=client_credentials&
client_id=&
client_secret=

參數(shù)解析如下：

• grant_type：授權(quán)類型，客戶端模式固定值為client_credentials
• client_id：客戶端id
• client_secret：客戶端秘鑰

2、返回令牌

認(rèn)證成功后直接返回令牌，格式為JSON數(shù)據(jù)，如下：

{
"access_token": "ACCESS_TOKEN",
"token_type": "bearer",
"expires_in": 7200,
"scope": "all"
}

OAuth2.0的認(rèn)證中心搭建

為了方便測試OAuth2的四種授權(quán)模式，這里為了方便測試，簡單搭建一個(gè)認(rèn)證中心，后續(xù)會逐漸完善。

1、案例架構(gòu)

陳某使用的是Spring Boot + Spring Cloud Alibaba 作為基礎(chǔ)搭建，新建一個(gè)oauth2-auth-server-in-memory模塊作為認(rèn)證中心，目錄如下：

“

案例源碼已經(jīng)上傳GitHub，關(guān)注公眾號：碼猿技術(shù)專欄，回復(fù)關(guān)鍵詞 9529 獲取。

”

2、添加依賴

Spring Boot 和 Spring Cloud 的相關(guān)依賴這里陳某就不再說了，直接上Spring Security和OAuth2的依賴，如下：

<!--spring security的依賴-->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>

<!--OAuth2的依賴-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-oauth2</artifactId>
</dependency>

3、Spring Security安全配置

這里主要涉及到Spring Security的配置，有不清楚的可以陳某第一篇文章：實(shí)戰(zhàn)！Spring Boot Security+JWT前后端分離架構(gòu)登錄認(rèn)證！

SecurityConfig這個(gè)配置類中主要設(shè)置有4塊內(nèi)容，如下：

1、加密方式

采用BCryptPasswordEncoder加密，如下：

2、配置用戶

這里為了方便測試，直接將用戶信息存儲在內(nèi)存中，后續(xù)完善，代碼如下：

上述代碼配置了兩個(gè)用戶，如下：

• 用戶名admin，密碼123，角色admin
• 用戶名user，密碼123，角色user

3、注入認(rèn)證管理器AuthenticationManager

AuthenticationManager在密碼授權(quán)模式下會用到，這里提前注入，如果你用的不是密碼模式，可以不注入，代碼如下：

4、配置安全攔截策略

由于需要驗(yàn)證授權(quán)碼模式，因此開啟表單提交模式，所有url都需要認(rèn)證，代碼如下：

4、令牌存儲策略配置

令牌支持多種方式存儲，比如內(nèi)存方式、Redis、JWT，比較常用的兩種則是Redis、JWT。

這里暫時(shí)使用內(nèi)存存儲的方式，一旦服務(wù)器重啟令牌將會失效。

代碼如下：

5、OAuth2.0的配置類

不是所有配置類都可以作為OAuth2.0認(rèn)證中心的配置類，需要滿足以下兩點(diǎn)：

1. 繼承AuthorizationServerConfigurerAdapter
2. 標(biāo)注 @EnableAuthorizationServer 注解

代碼如下：

AuthorizationServerConfigurerAdapter需要實(shí)現(xiàn)的三個(gè)方法如下：

下面便是圍繞這三個(gè)方法進(jìn)行OAuth2的詳細(xì)配置。

6、客戶端配置

在介紹OAuth2.0 協(xié)議的時(shí)候介紹到，并不是所有的客戶端都有權(quán)限向認(rèn)證中心申請令牌的，首先認(rèn)證中心要知道你是誰，你有什么資格？

因此一些必要的配置是要認(rèn)證中心分配給你的，比如客戶端唯一Id、秘鑰、權(quán)限。

客戶端配置的存儲也支持多種方式，比如內(nèi)存、數(shù)據(jù)庫，對應(yīng)的接口為：org.springframework.security.oauth2.provider.ClientDetailsService，接口如下：

同樣這里為了方便測試，依然是加載在內(nèi)存中，后續(xù)完善，完整的配置如下：

幾個(gè)重要參數(shù)說一下，如下：

• .withClient("myjszl")：指定客戶端唯一ID為myjszl
• .secret()：指定秘鑰，使用加密算法加密了，秘鑰為123
• .resourceIds("res1")：給客戶端分配的資源權(quán)限，對應(yīng)的是資源服務(wù)，比如訂單這個(gè)微服務(wù)就可以看成一個(gè)資源，作為客戶端肯定不是所有資源都能訪問。
• authorizedGrantTypes()：定義認(rèn)證中心支持的授權(quán)類型，總共支持五種
• 授權(quán)碼模式：authorization_code
• 密碼模式：password
• 客戶端模式：client_credentials
• 簡化模式：implicit
• 令牌刷新：refresh_token，這并不是OAuth2的模式，定義這個(gè)表示認(rèn)證中心支持令牌刷新
• scopes()：定義客戶端的權(quán)限，這里只是一個(gè)標(biāo)識，資源服務(wù)可以根據(jù)這個(gè)權(quán)限進(jìn)行鑒權(quán)。
• autoApprove：是否需要授權(quán)，設(shè)置為true則不需要用戶點(diǎn)擊確認(rèn)授權(quán)直接返回授權(quán)碼
• redirectUris：跳轉(zhuǎn)的uri

7、授權(quán)碼服務(wù)配置

使用授權(quán)碼模式必須配置一個(gè)授權(quán)碼服務(wù)，用來頒布和刪除授權(quán)碼，當(dāng)然授權(quán)碼也支持多種方式存儲，比如內(nèi)存，數(shù)據(jù)庫，這里暫時(shí)使用內(nèi)存方式存儲，代碼如下：

8、令牌服務(wù)的配置

除了令牌的存儲策略需要配置，還需要配置令牌的服務(wù)AuthorizationServerTokenServices用來創(chuàng)建、獲取、刷新令牌，代碼如下：

9、令牌訪問端點(diǎn)的配置

目前這里僅僅配置了四個(gè)，分別如下：

• 配置了授權(quán)碼模式所需要的服務(wù)，AuthorizationCodeServices
• 配置了密碼模式所需要的AuthenticationManager
• 配置了令牌管理服務(wù)，AuthorizationServerTokenServices
• 配置/oauth/token申請令牌的uri只允許POST提交。

詳細(xì)代碼如下：

spring Security框架默認(rèn)的訪問端點(diǎn)有如下6個(gè)：

• /oauth/authorize：獲取授權(quán)碼的端點(diǎn)
• /oauth/token：獲取令牌端點(diǎn)。
• /oauth/confifirm_access：用戶確認(rèn)授權(quán)提交端點(diǎn)。
• /oauth/error：授權(quán)服務(wù)錯(cuò)誤信息端點(diǎn)。
• /oauth/check_token：用于資源服務(wù)訪問的令牌解析端點(diǎn)。
• /oauth/token_key：提供公有密匙的端點(diǎn)，如果你使用JWT令牌的話。

當(dāng)然如果業(yè)務(wù)要求需要改變這些默認(rèn)的端點(diǎn)的url，也是可以修改的，AuthorizationServerEndpointsConfigurer有一個(gè)方法，如下：

public AuthorizationServerEndpointsConfigurer pathMapping(String defaultPath, String customPath)

第一個(gè)參數(shù)：需要替換的默認(rèn)端點(diǎn)url

第二個(gè)參數(shù)：自定義的端點(diǎn)url

10、令牌訪問安全約束配置

主要對一些端點(diǎn)的權(quán)限進(jìn)行配置，代碼如下：

OAuth2.0的資源服務(wù)搭建

客戶端申請令牌的目的就是為了訪問資源，當(dāng)然這個(gè)資源也是分權(quán)限的，一個(gè)令牌不是所有資源都能訪問的。

在認(rèn)證中心搭建的第6步配置客戶端詳情的時(shí)候，一行代碼.resourceIds("res1")則指定了能夠訪問的資源，可以配置多個(gè)，這里的res1則是唯一對應(yīng)一個(gè)資源。

1、案例架構(gòu)

陳某使用的是Spring Boot + Spring Cloud Alibaba 作為基礎(chǔ)搭建，新建一個(gè)oauth2-auth-resource-in-memory模塊作為認(rèn)證中心，目錄如下：

“

案例源碼已經(jīng)上傳GitHub，關(guān)注公眾號：碼猿技術(shù)專欄，回復(fù)關(guān)鍵詞 9529 獲取。

”

2、OAuth2.0的配置類

作為資源服務(wù)的配置類必須滿足兩個(gè)條件，如下：

• 標(biāo)注注解@EnableResourceServer
• 繼承ResourceServerConfigurerAdapter

代碼如下：

3、令牌校驗(yàn)服務(wù)配置

由于認(rèn)證中心使用的令牌存儲策略是在內(nèi)存中的，因此服務(wù)端必須遠(yuǎn)程調(diào)用認(rèn)證中心的校驗(yàn)令牌端點(diǎn)**/oauth/check_token**進(jìn)行校驗(yàn)。

代碼如下：

“

注意：遠(yuǎn)程校驗(yàn)令牌存在性能問題，但是后續(xù)使用JWT令牌則本地即可進(jìn)行校驗(yàn)，不必遠(yuǎn)程校驗(yàn)了。

”

4、配置客戶端唯一id和令牌校驗(yàn)服務(wù)

上文說到客戶端有一個(gè)唯一標(biāo)識，因此需要配置上，代碼如下：

5、配置security的安全機(jī)制

上文在認(rèn)證中心的第6步配置客戶端詳情那里，有一行代碼.scopes("all")則是指定了客戶端的權(quán)限，資源服務(wù)可以根據(jù)這個(gè)scope進(jìn)行url的攔截。

攔截方式如下：

.access("#oauth2.hasScope('')")

詳細(xì)配置代碼如下：

這里陳某配置了所有路徑都需要all的權(quán)限。

6、新建測試接口

新建了兩個(gè)接口，如下：

• /hello：認(rèn)證成功都可以訪問
• /admin：只有具備ROLE_admin角色的用戶才可以訪問

OAuth2.0的四種模式測試

下面結(jié)合認(rèn)證中心、資源服務(wù)對OAuth2.0的四種服務(wù)進(jìn)行測試。

啟動上述搭建的認(rèn)證中心和資源服務(wù)，如下圖：

授權(quán)碼模式

1、獲取授權(quán)碼

請求的url如下：

http://localhost:2003/auth-server/oauth/authorize?client_id=myjszl&response_type=code&scope=all&redirect_uri=http://www.baidu.com

瀏覽器訪問，security需要登錄，如下：

輸入用戶名user，密碼123，成功登錄。

此時(shí)來到了確認(rèn)授權(quán)的頁面，如下：

選擇Apporove、確認(rèn)授權(quán)，成功跳轉(zhuǎn)到了百度頁面，并且攜帶了授權(quán)碼，如下：

這里的6yV2bF就是獲取到的授權(quán)碼。

2、獲取token

http://localhost:2003/auth-server/oauth/token?code=jvMH5U&client_id=myjszl&client_secret=123&redirect_uri=http://www.baidu.com&grant_type=authorization_code

注意：/oauth/token獲取token的接口請求允許的方式要配置在授權(quán)服務(wù)器中，比如配置POST方式，代碼如下：

.allowedTokenEndpointRequestMethods(HttpMethod.POST)

POSTMAN請求如下圖：

3、訪問資源服務(wù)

拿著令牌訪問資源服務(wù)的**/hello**接口，請求如下：

請求頭需要添加Authorization，并且值為Bearer+" "+access_token的形式。

注意：Bearer后面一定要跟一個(gè)空格。

密碼模式

密碼模式比較簡單，不用先獲取授權(quán)碼，直接使用用戶名、密碼獲取token。

POSTMAN請求如下：

PS：訪問資源自己拿著獲取到的令牌嘗試下.....

簡化模式

簡化模式就很簡單了，拿著客戶端id就可以獲取token，請求的url如下：

http://localhost:2003/auth-server/oauth/authorize?response_type=token&client_id=myjszl&redirect_uri=http://www.baidu.com&scope=all

這個(gè)過程和獲取授權(quán)碼一樣，需要登錄，同意授權(quán)

最終跳轉(zhuǎn)到百度，鏈接后面直接攜帶了令牌，如下：

上圖中的0d5ecf06-b255-4272-b0fa-8e51dde2ce3e則是獲取的令牌。

PS：訪問資源自己嘗試下..........

客戶端模式

請求的url如下：

http://localhost:2003/auth-server/oauth/token?client_id=myjszl&client_secret=123&grant_type=client_credentials

POSTMAN請求如下：

PS：訪問資源自己嘗試下..........

OAuth2.0 其他端點(diǎn)的測試

Spring Security OAuth2.0還提供了其他的端點(diǎn)，下面來逐一測試一下。

1、刷新令牌

OAuth2.0提供了令牌刷新機(jī)制，一旦access_token過期，客戶端可以拿著refresh_token去請求認(rèn)證中心進(jìn)行令牌的續(xù)期。

請求的url如下：

http://localhost:2003/auth-server/oauth/token?client_id=myjszl&client_secret=123&grant_type=refresh_token&refresh_token=

POSTMAN請求如下：

2、校驗(yàn)令牌

OAuth2.0還提供了校驗(yàn)令牌的端點(diǎn)，請求的url如下：

http://localhost:2003/auth-server/oauth/check_token?toke=

POSTMAN請求如下：

總結(jié)

本文介紹了OAuth2.0協(xié)議原理、四種授權(quán)模式，并且搭建了認(rèn)證授權(quán)中心、資源服務(wù)進(jìn)行了四種模式的測試。

作為OAuth2.0入門教程已經(jīng)非常詳細(xì)了...........

最后說一句（別白嫖，求關(guān)注）

陳某每一篇文章都是精心輸出，已經(jīng)寫了3個(gè)專欄，整理成PDF，獲取方式如下：

1. 《Spring Cloud 進(jìn)階》PDF：關(guān)注公眾號：【碼猿技術(shù)專欄】回復(fù)關(guān)鍵詞 Spring Cloud 進(jìn)階 獲?。?/section>
2. 《Spring Boot 進(jìn)階》PDF：關(guān)注公眾號：【碼猿技術(shù)專欄】回復(fù)關(guān)鍵詞 Spring Boot進(jìn)階 獲??！
3. 《Mybatis 進(jìn)階》PDF：關(guān)注公眾號：【碼猿技術(shù)專欄】回復(fù)關(guān)鍵詞 Mybatis 進(jìn)階 獲?。?/section>

如果這篇文章對你有所幫助，或者有所啟發(fā)的話，幫忙點(diǎn)贊、在看、轉(zhuǎn)發(fā)、收藏，你的支持就是我堅(jiān)持下去的最大動力！