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

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

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

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

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

1.Web應用中設置攔截器對所有請求進行攔截，如果校驗不通過則跳轉(zhuǎn)登陸重新認證

2.客戶端發(fā)起認證請求，傳入用戶名密碼

3.通過驗證后，應用在服務器上將用戶信息存入session中，并將session id返回給客戶端

4.客戶端將session id存在本地cookie或local storage中，再次訪問時傳入session id

5.Web應用根據(jù)session id對比服務器的session數(shù)據(jù)，確認用戶身份

適合場景

這種模式只適合單服務器的場景

常用實現(xiàn)

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

缺陷

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

如何解決

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

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

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

Session共享方案

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

1.使用nginx做負載均衡，多臺web應用

2.客戶端發(fā)起認證請求，根據(jù)策略到其中一臺web

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

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

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

適合場景

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

常用實現(xiàn)

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

缺陷

1、這種方案的缺陷在于依賴于持久層的數(shù)據(jù)庫如redis，會有單點風險，如果持久層失敗，整個認證體系都會掛掉；

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

如何解決

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

客戶端token方案

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

1.客戶端發(fā)起認證請求，根據(jù)策略到其中一臺web

2.通過驗證后，服務端將用戶登陸信息封裝成token（token本身可以自解釋）返回給客戶端，不存儲在服務端

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

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

適合場景

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

常用實現(xiàn)

jwt

缺陷

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

1、失效問題，因為token是存放在客戶端的，服務端無法主動讓token失效，比如踢人下線、用戶權(quán)限發(fā)生變化等場景就實現(xiàn)不了

2、續(xù)簽問題，token 有效期一般都建議設置的不太長， token 過期后用戶需要重新登錄，導致用戶需要頻繁登錄

如何解決

針對失效問題：

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

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

針對續(xù)簽問題：

① 類似于 Session 認證中的做法： 假設服務端給的 token 有效期設置為30分鐘，服務端每次進行校驗時，如果發(fā)現(xiàn) token 的有效期馬上快過期了，服務端就重新生成 token 給客戶端?？蛻舳嗣看握埱蠖紮z查新舊token，如果不一致，則更新本地的token。這種做法的問題是僅僅在快過期的時候請求才會更新 token ,對客戶端不是很友好。每次請求都返回新 token :這種方案的的思路很簡單，但是，很明顯，開銷會比較大。

② 用戶登錄返回兩個 token ：第一個是 acessToken ，它的過期時間比較短，不如1天；另外一個是 refreshToken 它的過期時間更長一點比如為10天?？蛻舳说卿浐?，將 accessToken和refreshToken 保存在客戶端本地，每次訪問將 accessToken 傳給服務端。服務端校驗 accessToken 的有效性，如果過期的話，就將 refreshToken 傳給服務端。如果 refreshToken 有效，服務端就生成新的 accessToken 給客戶端。否則，客戶端就重新登錄即可。

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

微服務架構(gòu)

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

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

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

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

適合場景：

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

常用實現(xiàn)：

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

缺陷：

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

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

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

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

適合場景：

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

常用實現(xiàn)：

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

缺陷：

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

JWT + OAutstrong.0 +CAS方案

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

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

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

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

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

4.用戶登錄；

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

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

7.認證中心返回對應的用戶名；

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

常用實現(xiàn)

spring security + CAS

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

OAutstrong.0還有個替代方案，OIDC，它是OpenID Connect的簡稱，OIDC=(Identity, Authentication) + OAuth 2.0。它在OAutstrong上構(gòu)建了一個身份層，是一個基于OAutstrong協(xié)議的身份認證標準協(xié)議。暫時沒研究，有興趣的朋友可以查查。

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

1、在點擊分享鏈接時，主服務器會直接（接口）請求第三方服務器，第三方服務器會校驗主服務器上的用戶此時是否授權(quán)給自己（第三方）；

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

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

4、認證失敗，密碼錯誤。（重新登錄）

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

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

7、用戶操作分享操作（填寫自己的話語），點擊分享按鈕完成。

常用實現(xiàn)

spring security +OAutstrong.0

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

授權(quán)碼模式

授權(quán)碼模式相對其他三個模式來說是功能最完整，流程最安全嚴謹?shù)氖跈?quán)方式。它的特點是通過客戶端的后臺服務器與服務提供商的認證服務器進行交互：

A. 用戶訪問客戶端，客戶端將用戶導向認證服務器，需要攜帶客戶端ID憑證和重定向URI。

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

C. 假設用戶給予授權(quán)，認證服務器將用戶導向事先指定的重定向URI，同時附上一個授權(quán)碼。

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

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

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

簡化模式

簡化模式不通過服務端程序來完成，比授權(quán)碼模式減少了“授權(quán)碼”這個步驟，直接由瀏覽器發(fā)送請求獲取令牌，令牌對訪問者是可見的，且客戶端不需要認證，這種模式一般用于無后端應用，如手機/桌面客戶端程序、瀏覽器插件

A. 用戶訪問客戶端，客戶端將用戶導向認證服務器，需要攜帶客戶端ID憑證和重定向URI。

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

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

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

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

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

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

密碼模式

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

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

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

C. 認證服務器確認無誤后，向客戶端提供訪問令牌。

客戶端模式

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

A. 客戶端向認證服務器進行身份認證，并要求獲取訪問令牌。

B. 認證服務器確認無誤后，向客戶端提供訪問令牌。

刷新令牌

如果用戶訪問的時候，客戶端的"訪問令牌"已經(jīng)過期，則需要使用"更新令牌"申請一個新的訪問令牌

A. 客戶端向認證服務器進行身份認證，并要求獲取訪問令牌。

B. 認證服務器確認無誤后，返回訪問令牌和一個刷新令牌。

C. 客戶端通過訪問令牌訪問受保護資源。

D. 如果訪問令牌未過期，則向客戶端提供資源服務。

E. 客戶端通過訪問令牌訪問受保護資源。

F. 如果訪問令牌過期，受保護資源服務器返回Invalid Token Error。

G. 客戶端得到上方的錯誤后，通過刷新令牌向授權(quán)服務器申請一個新的訪問令牌。

H. 認證服務器確認無誤后，返回訪問令牌和一個刷新令牌。

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