詳解token已過(guò)期含義及解決方 token過(guò)期是否需要重新登錄Web應(yīng)用和用戶的身份驗(yàn)證息息相關(guān)，從單一服務(wù)器架構(gòu)到分布式服務(wù)架構(gòu)再到微服務(wù)架構(gòu)，用戶安全認(rèn)證和授權(quán)的機(jī)制也一直在演進(jìn)，下文對(duì)各個(gè)架構(gòu)下的認(rèn)證機(jī)制做個(gè)總結(jié)。單一服務(wù)器架構(gòu)該架

Web應(yīng)用和用戶的身份驗(yàn)證息息相關(guān)，從單一服務(wù)器架構(gòu)到分布式服務(wù)架構(gòu)再到微服務(wù)架構(gòu)，用戶安全認(rèn)證和授權(quán)的機(jī)制也一直在演進(jìn)，下文對(duì)各個(gè)架構(gòu)下的認(rèn)證機(jī)制做個(gè)總結(jié)。

單一服務(wù)器架構(gòu)

該架構(gòu)下后端只有一臺(tái)服務(wù)器提供服務(wù)。

認(rèn)證授權(quán)流程：

1.Web應(yīng)用中設(shè)置攔截器對(duì)所有請(qǐng)求進(jìn)行攔截，如果校驗(yàn)不通過(guò)則跳轉(zhuǎn)登陸重新認(rèn)證

2.客戶端發(fā)起認(rèn)證請(qǐng)求，傳入用戶名密碼

3.通過(guò)驗(yàn)證后，應(yīng)用在服務(wù)器上將用戶信息存入session中，并將session id返回給客戶端

4.客戶端將session id存在本地cookie或local storage中，再次訪問(wèn)時(shí)傳入session id

5.Web應(yīng)用根據(jù)session id對(duì)比服務(wù)器的session數(shù)據(jù)，確認(rèn)用戶身份

適合場(chǎng)景

這種模式只適合單服務(wù)器的場(chǎng)景

常用實(shí)現(xiàn)

shiro ；自定義注解 + 攔截器/AOP方案；filter方案等

缺陷

如果是分布式服務(wù)或跨域體系架構(gòu)的系統(tǒng)則會(huì)出現(xiàn)session無(wú)法共享的問(wèn)題。

如何解決

解決方案有兩種，第一種是將session統(tǒng)一存放，實(shí)現(xiàn)分布式session共享，第二種方案是客戶端生成token

分布式服務(wù)架構(gòu)

分布式服務(wù)架構(gòu)下，后端的服務(wù)器由一臺(tái)變成了多臺(tái)。

Session共享方案

認(rèn)證授權(quán)流程：

1.使用nginx做負(fù)載均衡，多臺(tái)web應(yīng)用

2.客戶端發(fā)起認(rèn)證請(qǐng)求，根據(jù)策略到其中一臺(tái)web

3.通過(guò)驗(yàn)證后，服務(wù)端將用戶的信息存入持久化層，例如redis緩存數(shù)據(jù)庫(kù)，再生成token令牌

4.并將生成的token返回客戶端，存入客戶端緩存。

5.客戶端再次訪問(wèn)web，根據(jù)策略路由到其中一臺(tái)，web應(yīng)用查詢持久化層，根據(jù)帶入的token查詢用戶登陸信息，確認(rèn)身份。

適合場(chǎng)景

并發(fā)量不高的分布式應(yīng)用

常用實(shí)現(xiàn)

shiro ；自定義注解 + 攔截器/AOP方案；filter方案等

缺陷

1、這種方案的缺陷在于依賴(lài)于持久層的數(shù)據(jù)庫(kù)如redis，會(huì)有單點(diǎn)風(fēng)險(xiǎn)，如果持久層失敗，整個(gè)認(rèn)證體系都會(huì)掛掉；

2、每一次調(diào)用都需要訪問(wèn)持久化層進(jìn)行驗(yàn)證，會(huì)給持久化層造成壓力，在高并發(fā)場(chǎng)景，持久化層容易成為瓶頸；

如何解決

持久層的數(shù)據(jù)庫(kù)如redis做高可用和集群。

客戶端token方案

認(rèn)證授權(quán)流程：

1.客戶端發(fā)起認(rèn)證請(qǐng)求，根據(jù)策略到其中一臺(tái)web

2.通過(guò)驗(yàn)證后，服務(wù)端將用戶登陸信息封裝成token（token本身可以自解釋?zhuān)┓祷亟o客戶端，不存儲(chǔ)在服務(wù)端

3.客戶端將返回的完整信息存入緩存。

4.客戶端再次訪問(wèn)web，根據(jù)策略路由到其中一臺(tái)，帶入登陸信息，服務(wù)端根據(jù)信息確認(rèn)身份。

適合場(chǎng)景

優(yōu)勢(shì)在于服務(wù)端不保存用戶會(huì)話數(shù)據(jù)，服務(wù)端無(wú)狀態(tài)，不用去持久層查詢從而增加了效率，適合一次性驗(yàn)證、restful api 的無(wú)狀態(tài)認(rèn)證、并發(fā)量較高的分布式應(yīng)用等

常用實(shí)現(xiàn)

jwt

缺陷

token一旦下發(fā)便不受服務(wù)端控制，如果發(fā)生token泄露，服務(wù)器也只能任其蹂躪，在其未過(guò)期期間不能有任何措施，同時(shí)存在以下兩個(gè)問(wèn)題：

1、失效問(wèn)題，因?yàn)閠oken是存放在客戶端的，服務(wù)端無(wú)法主動(dòng)讓token失效，比如踢人下線、用戶權(quán)限發(fā)生變化等場(chǎng)景就實(shí)現(xiàn)不了

2、續(xù)簽問(wèn)題，token 有效期一般都建議設(shè)置的不太長(zhǎng)， token 過(guò)期后用戶需要重新登錄，導(dǎo)致用戶需要頻繁登錄

如何解決

針對(duì)失效問(wèn)題：

① 將 token 存入內(nèi)存數(shù)據(jù)庫(kù)：將 token 存入 DB 或redis中。如果需要讓某個(gè) token 失效就直接從 redis 中刪除這個(gè) token 即可。但是，這樣會(huì)導(dǎo)致每次使用 token 發(fā)送請(qǐng)求都要先從redis中查詢 token 是否存在的步驟，而且違背了 JWT 的無(wú)狀態(tài)原則，不可取。

② 黑名單機(jī)制：使用內(nèi)存數(shù)據(jù)庫(kù)比如 redis 維護(hù)一個(gè)黑名單，如果想讓某個(gè) token 失效的話就直接將這個(gè) token 加入到 黑名單 即可。然后，每次使用 token 進(jìn)行請(qǐng)求的話都會(huì)先判斷這個(gè) token 是否存在于黑名單中。

針對(duì)續(xù)簽問(wèn)題：

① 類(lèi)似于 Session 認(rèn)證中的做法： 假設(shè)服務(wù)端給的 token 有效期設(shè)置為30分鐘，服務(wù)端每次進(jìn)行校驗(yàn)時(shí)，如果發(fā)現(xiàn) token 的有效期馬上快過(guò)期了，服務(wù)端就重新生成 token 給客戶端。客戶端每次請(qǐng)求都檢查新舊token，如果不一致，則更新本地的token。這種做法的問(wèn)題是僅僅在快過(guò)期的時(shí)候請(qǐng)求才會(huì)更新 token ,對(duì)客戶端不是很友好。每次請(qǐng)求都返回新 token :這種方案的的思路很簡(jiǎn)單，但是，很明顯，開(kāi)銷(xiāo)會(huì)比較大。

② 用戶登錄返回兩個(gè) token ：第一個(gè)是 acessToken ，它的過(guò)期時(shí)間比較短，不如1天；另外一個(gè)是 refreshToken 它的過(guò)期時(shí)間更長(zhǎng)一點(diǎn)比如為10天。客戶端登錄后，將 accessToken和refreshToken 保存在客戶端本地，每次訪問(wèn)將 accessToken 傳給服務(wù)端。服務(wù)端校驗(yàn) accessToken 的有效性，如果過(guò)期的話，就將 refreshToken 傳給服務(wù)端。如果 refreshToken 有效，服務(wù)端就生成新的 accessToken 給客戶端。否則，客戶端就重新登錄即可。

說(shuō)明：JWT 最適合的場(chǎng)景是不需要服務(wù)端保存用戶狀態(tài)的場(chǎng)景，但是如果考慮到 token 注銷(xiāo)和 token 續(xù)簽的場(chǎng)景話，沒(méi)有特別好的解決方案，大部分解決方案都給 token 加上了狀態(tài)，這就有點(diǎn)類(lèi)似 Session 認(rèn)證了。

微服務(wù)架構(gòu)

微服務(wù)架構(gòu)下服務(wù)端根據(jù)業(yè)務(wù)拆分為多個(gè)服務(wù)，除了公司內(nèi)部服務(wù)外，外部客戶或者第三方也通過(guò)api網(wǎng)關(guān)統(tǒng)一轉(zhuǎn)發(fā)請(qǐng)求，在這個(gè)階段系統(tǒng)需要提供跨系統(tǒng)單點(diǎn)登錄、第三方授權(quán)登錄等基礎(chǔ)能力。在這種架構(gòu)下后端建立單獨(dú)的認(rèn)證授權(quán)中心。 目前實(shí)現(xiàn)統(tǒng)一身份認(rèn)證和授權(quán)的技術(shù)手段較多，總體可以歸納為以下幾類(lèi)。

傳統(tǒng)的 Cookie + Session 解決方案 ，有狀態(tài)會(huì)話模式

認(rèn)證授權(quán)流程：

同分布式服務(wù)架構(gòu)中的“Session共享方案”

適合場(chǎng)景：

同分布式服務(wù)架構(gòu)中的“Session共享方案”

常用實(shí)現(xiàn)：

同分布式服務(wù)架構(gòu)中的“Session共享方案”

缺陷：

分布式 Session 是老牌的成熟解決方案，但因其狀態(tài)化通信的特性與微服務(wù)提倡的API導(dǎo)向無(wú)狀態(tài)通信相互違背，且共享式存儲(chǔ)存在安全隱患，因此微服務(wù)一般不太采用

JWT+網(wǎng)關(guān)撤銷(xiāo)令牌方案，無(wú)狀態(tài)交互模式

認(rèn)證授權(quán)流程：

同分布式服務(wù)架構(gòu)中的“客戶端token方案”，只是在該基礎(chǔ)上，加上API網(wǎng)關(guān)令牌失效和令牌續(xù)簽的機(jī)制，參考分布式服務(wù)架構(gòu)中的“Session共享方案”的“如何解決”部分。

適合場(chǎng)景：

同分布式服務(wù)架構(gòu)中的“客戶端token方案”

常用實(shí)現(xiàn)：

同分布式服務(wù)架構(gòu)中的“客戶端token方案”

缺陷：

同分布式服務(wù)架構(gòu)中的“客戶端token方案”

JWT + OAutstrong.0 +CAS方案

CAS是單點(diǎn)登錄的解決方案，單點(diǎn)登錄(Single Sign On),簡(jiǎn)稱(chēng)為 SSO,是目前比較流行的企業(yè)業(yè)務(wù)整合的解決方案之一。SSO的定義是在多個(gè)應(yīng)用系統(tǒng)中,用戶只需要登錄一次就可以訪問(wèn)所有相互信任的應(yīng)用系統(tǒng)。CAS共涉及角色有：CAS Client（下文提到的系統(tǒng)A等）、User、CAS Server（認(rèn)證中心）。CAS 是一個(gè)認(rèn)證框架，其本身定義了一套靈活完整的認(rèn)證流程，但其兼容主流的認(rèn)證和授權(quán)協(xié)議如 OAutstrong、SAML、OpenID 等，因此一般采用 CAS + OAutstrong 的方案實(shí)現(xiàn) SSO 和授權(quán)登錄。

認(rèn)證授權(quán)流程：

1.用戶訪問(wèn)系統(tǒng)A；

2.系統(tǒng)A發(fā)現(xiàn)用戶沒(méi)有登錄，也沒(méi)有ticket，重定向到認(rèn)證中心；有ticket跳轉(zhuǎn) 第7步；

3.認(rèn)證中心發(fā)現(xiàn)用戶并未登錄，展示登錄頁(yè)面；

4.用戶登錄；

5.認(rèn)證中心登錄成功，帶著生成的ticket，重定向到之前的系統(tǒng)A頁(yè)面；

6.系統(tǒng)A檢查登錄，還是未登錄，但存在ticket。系統(tǒng)A帶著ticket和認(rèn)證中心進(jìn)行校驗(yàn)；

7.認(rèn)證中心返回對(duì)應(yīng)的用戶名；

8.系統(tǒng)A檢查返回的用戶名是否只有一個(gè)且不為空，若是，則返回給用戶指定的資源信息；若不是，則跳轉(zhuǎn) 第2步。

常用實(shí)現(xiàn)

spring security + CAS

OAutstrong.0協(xié)議考慮到了微服務(wù)認(rèn)證中的方方面面，提供的多種授權(quán)模式。這種方案的優(yōu)點(diǎn)是安全性好，是業(yè)內(nèi)成熟的給第三方提供授權(quán)登錄解決方案，但是實(shí)現(xiàn)成本和復(fù)雜度高。 OAutstrong.0提供了4種授權(quán)模式，能夠適應(yīng)多種場(chǎng)景，作為基于令牌的安全框架，可以廣泛用于需要統(tǒng)一身份認(rèn)證和授權(quán)的場(chǎng)景。 在 OAutstrong.0 的實(shí)施過(guò)程中，一般會(huì)采用 JWT 作為令牌的主要標(biāo)準(zhǔn)。以文章分享舉個(gè)例子，你在（登錄后）瀏覽某論壇時(shí)，遇到了一篇好文章，想要分享給大家時(shí)，你需要登錄（掃碼或者登錄用戶名密碼）第三方賬戶如來(lái)完成分享。

OAutstrong.0還有個(gè)替代方案，OIDC，它是OpenID Connect的簡(jiǎn)稱(chēng)，OIDC=(Identity, Authentication) + OAuth 2.0。它在OAutstrong上構(gòu)建了一個(gè)身份層，是一個(gè)基于OAutstrong協(xié)議的身份認(rèn)證標(biāo)準(zhǔn)協(xié)議。暫時(shí)沒(méi)研究，有興趣的朋友可以查查。

認(rèn)證授權(quán)流程：

1、在點(diǎn)擊分享鏈接時(shí)，主服務(wù)器會(huì)直接（接口）請(qǐng)求第三方服務(wù)器，第三方服務(wù)器會(huì)校驗(yàn)主服務(wù)器上的用戶此時(shí)是否授權(quán)給自己（第三方）；

2、沒(méi)有授權(quán)信息，用戶登錄（掃描或者密碼）。

3、主服務(wù)器拿著用戶的登錄信息去第三方確認(rèn)認(rèn)證授權(quán)（密碼是否正確、是否授權(quán)）。

4、認(rèn)證失敗，密碼錯(cuò)誤。（重新登錄）

5、認(rèn)證成功（確認(rèn)授權(quán)），第三方認(rèn)證服務(wù)會(huì)返回的授權(quán)碼。

6、主服務(wù)器帶著授權(quán)碼請(qǐng)求第三方資源服務(wù)器，第三方資源服務(wù)器會(huì)返回指定的URI（分享界面）。

7、用戶操作分享操作（填寫(xiě)自己的話語(yǔ)），點(diǎn)擊分享按鈕完成。

常用實(shí)現(xiàn)

spring security +OAutstrong.0

OAutstrong.0提供了4種授權(quán)模式，如下：

授權(quán)碼模式

授權(quán)碼模式相對(duì)其他三個(gè)模式來(lái)說(shuō)是功能最完整，流程最安全嚴(yán)謹(jǐn)?shù)氖跈?quán)方式。它的特點(diǎn)是通過(guò)客戶端的后臺(tái)服務(wù)器與服務(wù)提供商的認(rèn)證服務(wù)器進(jìn)行交互：

A. 用戶訪問(wèn)客戶端，客戶端將用戶導(dǎo)向認(rèn)證服務(wù)器，需要攜帶客戶端ID憑證和重定向URI。

B. 用戶選擇是否給予客戶端授權(quán)。

C. 假設(shè)用戶給予授權(quán)，認(rèn)證服務(wù)器將用戶導(dǎo)向事先指定的重定向URI，同時(shí)附上一個(gè)授權(quán)碼。

D. 客戶端收到授權(quán)碼后，攜帶事先指定的重定向URI和授權(quán)碼向認(rèn)證服務(wù)器申請(qǐng)令牌。

E. 認(rèn)證服務(wù)器核對(duì)授權(quán)碼和重定向URI，確認(rèn)無(wú)誤后，向客戶端頒發(fā)訪問(wèn)令牌（access token）和刷新令牌（refresh token）。

這里的resource owner代表客戶，user-agent代表客戶使用的訪問(wèn)工具如瀏覽器或App，client指第三方客戶端

簡(jiǎn)化模式

簡(jiǎn)化模式不通過(guò)服務(wù)端程序來(lái)完成，比授權(quán)碼模式減少了“授權(quán)碼”這個(gè)步驟，直接由瀏覽器發(fā)送請(qǐng)求獲取令牌，令牌對(duì)訪問(wèn)者是可見(jiàn)的，且客戶端不需要認(rèn)證，這種模式一般用于無(wú)后端應(yīng)用，如手機(jī)/桌面客戶端程序、瀏覽器插件

A. 用戶訪問(wèn)客戶端，客戶端將用戶導(dǎo)向認(rèn)證服務(wù)器，需要攜帶客戶端ID憑證和重定向URI。

B. 用戶選擇是否給予客戶端授權(quán)。

C. 假設(shè)用戶給予授權(quán)，認(rèn)證服務(wù)器將用戶導(dǎo)向事先指定的重定向URI，并在URI的Hash部分包含了訪問(wèn)令牌（Fragment）。

D. 瀏覽器向資源服務(wù)器發(fā)出請(qǐng)求，其中不包含事先收到的Hash部分（Fragment）。

E. 資源服務(wù)器返回一段腳本，其中包含的代碼可以獲取Hash部分中的令牌。

F. 瀏覽器執(zhí)行事先獲取的腳本，提取出令牌

G. 瀏覽器將令牌發(fā)送給客戶端。

密碼模式

密碼模式中，用戶向客戶端提供用戶名和密碼，客戶端使用這些信息，直接向認(rèn)證服務(wù)器索要授權(quán)。這種模式違背了前面提到的微服務(wù)安全要解決的問(wèn)題（不暴露用戶名和密碼），但是在一些用戶對(duì)客戶端高度信任的情況下，例如公司內(nèi)部軟件間的授權(quán)下，使用這種模式也是適用的

A. 用戶向客戶端提供用戶名和密碼。

B. 客戶端將用戶名和密碼發(fā)送給認(rèn)證服務(wù)器，向認(rèn)證服務(wù)器索要令牌。

C. 認(rèn)證服務(wù)器確認(rèn)無(wú)誤后，向客戶端提供訪問(wèn)令牌。

客戶端模式

客戶端模式是客戶端以自己的名義去授權(quán)服務(wù)器申請(qǐng)授權(quán)令牌，并不是完全意義上的授權(quán)。一般不適用這種模式

A. 客戶端向認(rèn)證服務(wù)器進(jìn)行身份認(rèn)證，并要求獲取訪問(wèn)令牌。

B. 認(rèn)證服務(wù)器確認(rèn)無(wú)誤后，向客戶端提供訪問(wèn)令牌。

刷新令牌

如果用戶訪問(wèn)的時(shí)候，客戶端的"訪問(wèn)令牌"已經(jīng)過(guò)期，則需要使用"更新令牌"申請(qǐng)一個(gè)新的訪問(wèn)令牌

A. 客戶端向認(rèn)證服務(wù)器進(jìn)行身份認(rèn)證，并要求獲取訪問(wèn)令牌。

B. 認(rèn)證服務(wù)器確認(rèn)無(wú)誤后，返回訪問(wèn)令牌和一個(gè)刷新令牌。

C. 客戶端通過(guò)訪問(wèn)令牌訪問(wèn)受保護(hù)資源。

D. 如果訪問(wèn)令牌未過(guò)期，則向客戶端提供資源服務(wù)。

E. 客戶端通過(guò)訪問(wèn)令牌訪問(wèn)受保護(hù)資源。

F. 如果訪問(wèn)令牌過(guò)期，受保護(hù)資源服務(wù)器返回Invalid Token Error。

G. 客戶端得到上方的錯(cuò)誤后，通過(guò)刷新令牌向授權(quán)服務(wù)器申請(qǐng)一個(gè)新的訪問(wèn)令牌。

H. 認(rèn)證服務(wù)器確認(rèn)無(wú)誤后，返回訪問(wèn)令牌和一個(gè)刷新令牌。

【版權(quán)聲明】CRMEB社區(qū)提醒您：請(qǐng)?jiān)跒g覽本網(wǎng)站關(guān)于《詳解token已過(guò)期含義及解決方 token過(guò)期是否需要重新登錄》信息時(shí),請(qǐng)您務(wù)必閱讀并理解本聲明。本站部分內(nèi)容以及圖片來(lái)源于商家投稿和網(wǎng)絡(luò)轉(zhuǎn)載，如網(wǎng)站發(fā)布的有關(guān)的信息侵犯到您的權(quán)益，請(qǐng)及時(shí)與我們?nèi)〉寐?lián)系，郵箱：[email protected]，我們會(huì)尊重您的決定并當(dāng)天作出刪除處理。