Token機(jī)制雖說很早就出現(xiàn)了，但也就是最近十年內(nèi)才廣泛應(yīng)用的，而很多新手對(duì)于Token和Session何時(shí)使用區(qū)分不了，雖說聽說過Token但不知道其原理是啥以及如何使用。

Token是為了解決什么問題而生的？

在Token機(jī)制之前，服務(wù)器端驗(yàn)證客戶端請(qǐng)求是否合法主要是靠Cookie+Session機(jī)制來(lái)實(shí)現(xiàn)的。服務(wù)器端會(huì)為每個(gè)會(huì)話都生成一個(gè)Session，在高并發(fā)場(chǎng)景下會(huì)導(dǎo)致Session文件越來(lái)越多，不利于管理。

而Token是服務(wù)器端生成的一串加密字符串（具有生命周期），分配給客戶端作為令牌使用，Token的好處就是減輕了服務(wù)器端的壓力，因?yàn)門oken是由客戶端存儲(chǔ)的，而且是無(wú)狀態(tài)的。

Token機(jī)制流程

Token超時(shí)問題如何解決？

服務(wù)器端生成的Token是有生命周期的（過期時(shí)間），如果我們拿著已過期的Token去服務(wù)器端驗(yàn)證肯定是無(wú)法通過的，所以我們要在Token過期之前主動(dòng)更新Token，方案如下：

1、客戶端存儲(chǔ)Token時(shí)要記錄Token的過期時(shí)間

客戶端拿到服務(wù)器生成返回的Token后，需要將Token臨時(shí)存儲(chǔ)起來(lái)（SessionStorage、LocalStorage），然后客戶端定時(shí)檢測(cè)Token是否已過期，如果過期了則主動(dòng)向授權(quán)服務(wù)器重新發(fā)起認(rèn)證請(qǐng)求。

2、由服務(wù)器端主動(dòng)通知客戶端進(jìn)行Token更新

客戶端每次的請(qǐng)求中都會(huì)帶上Token，服務(wù)器會(huì)對(duì)此Token進(jìn)行校驗(yàn)，如果服務(wù)器端發(fā)現(xiàn)此Token將會(huì)在很短時(shí)間內(nèi)失敗，那就重新生成Token并附加到響應(yīng)體中，客戶端獲取服務(wù)器響應(yīng)數(shù)據(jù)時(shí)看下是否有Token，如果有則覆蓋本地舊的Token即可。

以上就是我的觀點(diǎn)，對(duì)于這個(gè)問題大家是怎么看待的呢？歡迎在下方評(píng)論區(qū)交流 ~ 我是科技領(lǐng)域創(chuàng)作者，十年互聯(lián)網(wǎng)從業(yè)經(jīng)驗(yàn)，歡迎關(guān)注我了解更多科技知識(shí)！

Token的流程，可以通過分析登錄的流程、退出的流程、置換token的流程分別討論？

登錄的流程

1. 用戶發(fā)送登錄請(qǐng)求

2. 認(rèn)證系統(tǒng)驗(yàn)證登錄-查詢數(shù)據(jù)庫(kù)用是存在該用戶

3. 如果該用戶存在，則生成Token存入Redis中，并將該Token返回客戶端

4. 如果該用戶不存在則提示登錄失敗

驗(yàn)證Token

客戶端

• 將Token key附加至header

服務(wù)端

• 從header中取出Token key

• 通過Token key和Redis中的相關(guān)Token信息進(jìn)行匹配

退出請(qǐng)求流程

1. 前端發(fā)送退出請(qǐng)求

2. 認(rèn)證系統(tǒng)驗(yàn)證token信息-從Redis中查詢相關(guān)Token信息

3. 如果token無(wú)效，提示前端換取token失敗

4. 如果token有效，刪除該token并提示前端退出成功

置換token的流程

以下討論的就是token超時(shí)的解決方案

先說下后端處理流程：

1. 前端請(qǐng)求置換token

2. 認(rèn)證系統(tǒng)驗(yàn)證去redis驗(yàn)證相關(guān)redis信息

3. token無(wú)效，則置換失敗

4. token有效，則從redis刪除相關(guān)redis，并返回前端新的token

置換token的前端處理流程

1. 前端在登錄成功后拿到token設(shè)置到cookie中

2. 請(qǐng)求業(yè)務(wù)接口時(shí)獲取token，并判斷是否到了該換取token的時(shí)間段了

3. 如果可以調(diào)用置換token接口，重新生成token,返回前端設(shè)置到cookie中

以上就是token的請(qǐng)求流程，及token超時(shí)的解決方案!!

希望能夠幫助到你��！

Token

Token是服務(wù)端生成的一串字符串，可以看做客戶端進(jìn)行請(qǐng)求的一個(gè)令牌，客戶端在請(qǐng)求網(wǎng)絡(luò)上某些資源的時(shí)候，必須帶著這塊令牌（通行證）。

當(dāng)客戶端第一次訪問服務(wù)端，服務(wù)端會(huì)根據(jù)傳過來(lái)的唯一標(biāo)識(shí)userId，運(yùn)用一些加密算法，生成一個(gè)Token，客戶端下次請(qǐng)求時(shí)，只需要帶上Token，服務(wù)器收到請(qǐng)求后，會(huì)驗(yàn)證這個(gè)Token。

有些公司會(huì)建設(shè)統(tǒng)一登錄系統(tǒng)（單點(diǎn)登錄），客戶端先去這個(gè)系統(tǒng)獲取Token，驗(yàn)證通過再拿著這些Token去訪問其他系統(tǒng)；API Gateway也可以提供類似的功能，我們公司就是這樣，客戶端接入的時(shí)候，先向網(wǎng)關(guān)獲取Token，驗(yàn)證通過了才能訪問被授權(quán)的接口，并且一段時(shí)間后要重新或者Token。

基于Token的認(rèn)證流程

1. 客戶端使用用戶名、密碼做身份驗(yàn)證；
   

2. 服務(wù)端收到請(qǐng)求后進(jìn)行身份驗(yàn)證；(也可能是統(tǒng)一登錄平臺(tái)、網(wǎng)關(guān))
   

3. 驗(yàn)證成功后，服務(wù)端會(huì)簽發(fā)一個(gè)Token返回給客戶端；
   

4. 客戶端收到Token以后可以把它存儲(chǔ)起來(lái)；每次向服務(wù)端發(fā)送請(qǐng)求的時(shí)候，都要帶著Token；
   

5. Token會(huì)有過期時(shí)間，過期后需要重新進(jìn)行驗(yàn)證；
   

6. 服務(wù)端收到請(qǐng)求，會(huì)驗(yàn)證客戶端請(qǐng)求里面的Token，驗(yàn)證成功，才會(huì)響應(yīng)客戶端的請(qǐng)求；
   

Token過期時(shí)間及超時(shí)刷新策略

因?yàn)門oken是訪問資源的憑證，所以必須要有過期時(shí)間。否則一次認(rèn)證通過就可以永久使用資源，那么認(rèn)證功能也就失去了意義，所以Token需要有過期時(shí)間。

• Token的過期時(shí)間很容易甚至，在生成Token的元素中，增加時(shí)間戳即可；然后在驗(yàn)證過程中，判斷是否超時(shí)；Token的超時(shí)時(shí)間不宜過長(zhǎng)，也不宜過短，我們項(xiàng)目設(shè)置的是1個(gè)小時(shí)。
  

• Token過期之后，需要重新獲取，一種方式是重新來(lái)一遍獲取Token的過程（比如重新登錄），這種做法實(shí)現(xiàn)起來(lái)簡(jiǎn)單，但是用戶體驗(yàn)不好；另外一種主動(dòng)刷新Token，在過期后自動(dòng)續(xù)約，或者定時(shí)任務(wù)定期去刷新Token，以保持Token始終在有效期內(nèi)；我們現(xiàn)在采用被動(dòng)的方式獲取和更新Token。
  

希望我的回答，能夠幫助到你！我將持續(xù)分享Java開發(fā)、架構(gòu)設(shè)計(jì)、程序員職業(yè)發(fā)展等方面的見解，希望能得到你的關(guān)注。

對(duì)于編程初學(xué)者來(lái)說，幾乎總是弄不清Token和Session的區(qū)別，也并不了解為何要用Token或者Session，尤其是對(duì)目前只學(xué)過單頁(yè)開發(fā)的人員來(lái)說，Session完全可以說是過去時(shí)了。

簡(jiǎn)單點(diǎn)說Token就是服務(wù)器端生產(chǎn)了一串字符串令牌，而且返回給客戶端進(jìn)行存儲(chǔ)，在下一次請(qǐng)求時(shí)將這串令牌放在請(qǐng)求頭Header上，就無(wú)需每次在帶上用戶名和密碼進(jìn)行校驗(yàn)，這樣就可以減少對(duì)數(shù)據(jù)庫(kù)的查詢操作，減輕服務(wù)器的壓力。

在Token未興起之時(shí)，其實(shí)大部分都是采用的Session機(jī)制，有服務(wù)器端保有Session會(huì)話對(duì)象，客戶端則是需要通過Cookie中的SessionId回傳到服務(wù)器來(lái)判斷當(dāng)前會(huì)話是否存在，若存在則是已登錄，若不存在則是失效未登錄！這也是Token與Session的區(qū)別！當(dāng)然了Session機(jī)制一般要求前端代碼與后端代碼放在同一域名服務(wù)器下，雖然目前有很多跨服務(wù)器Session同步，但是那個(gè)就比較麻煩了。

而Token則是完全滿足了目前前后端分離的需求，更是可以實(shí)現(xiàn)前端和后端項(xiàng)目的分別負(fù)載均衡。那么如何解決Token超時(shí)過期問題呢？這兒就需要對(duì)Token的時(shí)間進(jìn)行存儲(chǔ)并更新，也就是保留用戶最后一次請(qǐng)求服務(wù)器的時(shí)間，然后下一次請(qǐng)求與該時(shí)間進(jìn)行比對(duì)校驗(yàn)，若間隔大于自己設(shè)置的超時(shí)期限，那么就是過期超時(shí)退出，那么如何在自己設(shè)置的間隔范圍之內(nèi)，那么該Token有效時(shí)間就順延下去，以此類推，這樣就可以完成對(duì)應(yīng)Token的超時(shí)過期問題。

以上就是我的回答，也是目前我在項(xiàng)目中進(jìn)行使用的解決辦法，希望能夠?qū)δ阌兴鶐椭�和解答，我�?strong>路飛寫代碼，歡迎關(guān)注我，一起分享知識(shí)！

Token的運(yùn)用流程：當(dāng)用戶首次登錄成功之后, 服務(wù)器端就會(huì)生成一個(gè) token 值，這個(gè)值，會(huì)在服務(wù)器保存token值(保存在數(shù)據(jù)庫(kù)中)，再將這個(gè)token值返回給客戶端；

客戶端拿到 token 值之后，進(jìn)行保存 （保存位置由服務(wù)器端設(shè)置）；

以后客戶端再次發(fā)送網(wǎng)絡(luò)請(qǐng)求(一般不是登錄請(qǐng)求)的時(shí)候,就會(huì)將這個(gè) token 值附帶到參數(shù)中發(fā)送給服務(wù)器.；

服務(wù)器接收到客戶端的請(qǐng)求之后,會(huì)取出token值與保存在本地(數(shù)據(jù)庫(kù))中的token值進(jìn)行比較；

如果兩個(gè) token 值相同， 說明用戶登錄成功過!當(dāng)前用戶處于登錄狀態(tài)；

如果沒有這個(gè) token 值, 沒有登錄成功；

如果 token 值不同: 說明原來(lái)的登錄信息已經(jīng)失效,讓用戶重新登錄。

但一直有個(gè)問題就是超時(shí)，延時(shí)還要重新登錄！那該怎么解決呢？

服務(wù)器端生成的Token是有生命周期的（過期時(shí)間），如果我們拿著已過期的Token去服務(wù)器端驗(yàn)證肯定是無(wú)法通過的，所以我們要在Token過期之前主動(dòng)更新Token，方案如下：

1、客戶端存儲(chǔ)Token時(shí)要記錄Token的過期時(shí)間

客戶端拿到服務(wù)器生成返回的Token后，需要將Token臨時(shí)存儲(chǔ)起來(lái)（SessionStorage、LocalStorage），然后客戶端定時(shí)檢測(cè)Token是否已過期，如果過期了則主動(dòng)向授權(quán)服務(wù)器重新發(fā)起認(rèn)證請(qǐng)求。

2、由服務(wù)器端主動(dòng)通知客戶端進(jìn)行Token更新

客戶端每次的請(qǐng)求中都會(huì)帶上Token，服務(wù)器會(huì)對(duì)此Token進(jìn)行校驗(yàn)，如果服務(wù)器端發(fā)現(xiàn)此Token將會(huì)在很短時(shí)間內(nèi)失敗，那就重新生成Token并附加到響應(yīng)體中，客戶端獲取服務(wù)器響應(yīng)數(shù)據(jù)時(shí)看下是否有Token，如果有則覆蓋本地舊的Token即可

____________________________________________________________________________________

回答不易，喜歡的朋友請(qǐng)點(diǎn)贊，轉(zhuǎn)發(fā)，評(píng)論哦！

首先你要明白token最初的設(shè)計(jì)思路和目的，并不是很多人所謂的用redis存儲(chǔ)什么東西，那樣只是session共享的一種方式，token實(shí)際上是一串字符串，這個(gè)字符串是將登錄信息用特定手段進(jìn)行加密之后，由客戶端存儲(chǔ)，并在每次請(qǐng)求中攜帶，用于驗(yàn)證身份的一個(gè)令牌機(jī)制，也就是說這個(gè)字符串本身就包含登錄的信息，并不需要其他的redis之類的機(jī)制來(lái)保存其他信息，也就是說他是無(wú)狀態(tài)的，有效性的判定標(biāo)準(zhǔn)由后端的特定邏輯來(lái)確定的，而token在第一次登錄之后，由后端計(jì)算完成，并發(fā)送至客戶端并存儲(chǔ)，對(duì)于客戶端來(lái)說，之后的每次路由跳轉(zhuǎn)，網(wǎng)絡(luò)請(qǐng)求，都需要攜帶這個(gè)token，用來(lái)告訴路由守衛(wèi)也好，服務(wù)提供者也好，我當(dāng)前是誰(shuí)在操作，這個(gè)操作是不是被允許，僅此而已，如果需要當(dāng)前登錄用戶的詳細(xì)信息，可以在登陸的時(shí)候存到類似vuex等狀態(tài)保持機(jī)制中去，隨用隨取，所以這種機(jī)制下，redis完全沒有用處。

Token驗(yàn)證流程：

1.背景介紹

傳統(tǒng)身份驗(yàn)證的方法

HTTP是一種沒有狀態(tài)的協(xié)議，也就是它并不知道是誰(shuí)是訪問應(yīng)用。這里我們把用戶看成是客戶端，客戶端使用用戶名還有密碼通過了身份驗(yàn)證，不過下回這個(gè)客戶端再發(fā)送請(qǐng)求時(shí)候，還得再驗(yàn)證一下。

解決的方法就是，當(dāng)用戶請(qǐng)求登錄的時(shí)候，如果沒有問題，我們?cè)诜��?wù)端生成一條記錄，這個(gè)記錄里可以說明一下登錄的用戶是誰(shuí)，然后把這條記錄的ID號(hào)發(fā)送給客戶端，客戶端收到以后把這個(gè)ID號(hào)存儲(chǔ)在Cookie里，下次這個(gè)用戶再向服務(wù)端發(fā)送請(qǐng)求的時(shí)候，可以帶著這個(gè)Cookie，這樣服務(wù)端會(huì)驗(yàn)證一個(gè)這個(gè)Cookie里的信息，看看能不能在服務(wù)端這里找到對(duì)應(yīng)的記錄，如果可以，說明用戶已經(jīng)通過了身份驗(yàn)證，就把用戶請(qǐng)求的數(shù)據(jù)返回給客戶端。

上面說的就是Session，我們需要在服務(wù)端存儲(chǔ)為登錄的用戶生成的Session，這些Session可能會(huì)存儲(chǔ)在內(nèi)存，磁盤，或者數(shù)據(jù)庫(kù)里。我們可能需要在服務(wù)端定期的去清理過期的Session。

基于Token的身份驗(yàn)證方法

使用基于Token的身份驗(yàn)證方法，在服務(wù)端不需要存儲(chǔ)用戶的登錄記錄。大概的流程是這樣的：

客戶端使用用戶名跟密碼請(qǐng)求登錄

服務(wù)端收到請(qǐng)求，去驗(yàn)證用戶名與密碼

驗(yàn)證成功后，服務(wù)端會(huì)簽發(fā)一個(gè)Token，再把這個(gè)Token發(fā)送給客戶端

客戶端收到Token以后可以把它存儲(chǔ)起來(lái)，比如放在Cookie里或者LocalStorage里

客戶端每次向服務(wù)端請(qǐng)求資源的時(shí)候需要帶著服務(wù)端簽發(fā)的Token

服務(wù)端收到請(qǐng)求，然后去驗(yàn)證客戶端請(qǐng)求里面帶著的Token，如果驗(yàn)證成功，就向客戶端返回請(qǐng)求的數(shù)據(jù)

傳統(tǒng)身份驗(yàn)證的方法

HTTP是一種沒有狀態(tài)的協(xié)議，也就是它并不知道是誰(shuí)是訪問應(yīng)用。這里我們把用戶看成是客戶端，客戶端使用用戶名還有密碼通過了身份驗(yàn)證，不過下回這個(gè)客戶端再發(fā)送請(qǐng)求時(shí)候，還得再驗(yàn)證一下。

解決的方法就是，當(dāng)用戶請(qǐng)求登錄的時(shí)候，如果沒有問題，我們?cè)诜��?wù)端生成一條記錄，這個(gè)記錄里可以說明一下登錄的用戶是誰(shuí)，然后把這條記錄的ID號(hào)發(fā)送給客戶端，客戶端收到以后把這個(gè)ID號(hào)存儲(chǔ)在Cookie里，下次這個(gè)用戶再向服務(wù)端發(fā)送請(qǐng)求的時(shí)候，可以帶著這個(gè)Cookie，這樣服務(wù)端會(huì)驗(yàn)證一個(gè)這個(gè)Cookie里的信息，看看能不能在服務(wù)端這里找到對(duì)應(yīng)的記錄，如果可以，說明用戶已經(jīng)通過了身份驗(yàn)證，就把用戶請(qǐng)求的數(shù)據(jù)返回給客戶端。

上面說的就是Session，我們需要在服務(wù)端存儲(chǔ)為登錄的用戶生成的Session，這些Session可能會(huì)存儲(chǔ)在內(nèi)存，磁盤，或者數(shù)據(jù)庫(kù)里。我們可能需要在服務(wù)端定期的去清理過期的Session。

基于Token的身份驗(yàn)證方法

使用基于Token的身份驗(yàn)證方法，在服務(wù)端不需要存儲(chǔ)用戶的登錄記錄。大概的流程是這樣的：

客戶端使用用戶名跟密碼請(qǐng)求登錄

服務(wù)端收到請(qǐng)求，去驗(yàn)證用戶名與密碼

驗(yàn)證成功后，服務(wù)端會(huì)簽發(fā)一個(gè)Token，再把這個(gè)Token發(fā)送給客戶端

客戶端收到Token以后可以把它存儲(chǔ)起來(lái)，比如放在Cookie里或者LocalStorage里

客戶端每次向服務(wù)端請(qǐng)求資源的時(shí)候需要帶著服務(wù)端簽發(fā)的Token

服務(wù)端收到請(qǐng)求，然后去驗(yàn)證客戶端請(qǐng)求里面帶著的Token，如果驗(yàn)證成功，就向客戶端返回請(qǐng)求的數(shù)據(jù)Tiles起源

最早的Tiles是組裝在Struts1.1里面的，主要目的是為了將復(fù)數(shù)的jsp頁(yè)面作為一個(gè)的頁(yè)面的部分機(jī)能，然后用來(lái)組合成一個(gè)最終表示用頁(yè)面用的，這樣的話，便于對(duì)頁(yè)面的各個(gè)機(jī)能的變更及維護(hù)。

現(xiàn)在Tiles已經(jīng)作為一個(gè)Apache獨(dú)立的開源項(xiàng)目維護(hù)著。

如果您發(fā)現(xiàn)自己在每個(gè)頁(yè)面上都要編寫三行相同的JSP代碼，或者你想容易地定義復(fù)雜的模版布局，那么相信學(xué)習(xí)Tiles框架會(huì)對(duì)你有幫助

2.知識(shí)剖析

傳統(tǒng)身份驗(yàn)證的方法

HTTP是一種沒有狀態(tài)的協(xié)議，也就是它并不知道是誰(shuí)是訪問應(yīng)用。這里我們把用戶看成是客戶端，客戶端使用用戶名還有密碼通過了身份驗(yàn)證，不過下回這個(gè)客戶端再發(fā)送請(qǐng)求時(shí)候，還得再驗(yàn)證一下。

解決的方法就是，當(dāng)用戶請(qǐng)求登錄的時(shí)候，如果沒有問題，我們?cè)诜��?wù)端生成一條記錄，這個(gè)記錄里可以說明一下登錄的用戶是誰(shuí)，然后把這條記錄的ID號(hào)發(fā)送給客戶端，客戶端收到以后把這個(gè)ID號(hào)存儲(chǔ)在Cookie里，下次這個(gè)用戶再向服務(wù)端發(fā)送請(qǐng)求的時(shí)候，可以帶著這個(gè)Cookie，這樣服務(wù)端會(huì)驗(yàn)證一個(gè)這個(gè)Cookie里的信息，看看能不能在服務(wù)端這里找到對(duì)應(yīng)的記錄，如果可以，說明用戶已經(jīng)通過了身份驗(yàn)證，就把用戶請(qǐng)求的數(shù)據(jù)返回給客戶端。

上面說的就是Session，我們需要在服務(wù)端存儲(chǔ)為登錄的用戶生成的Session，這些Session可能會(huì)存儲(chǔ)在內(nèi)存，磁盤，或者數(shù)據(jù)庫(kù)里。我們可能需要在服務(wù)端定期的去清理過期的Session。

基于Token的身份驗(yàn)證方法

使用基于Token的身份驗(yàn)證方法，在服務(wù)端不需要存儲(chǔ)用戶的登錄記錄。大概的流程是這樣的：

客戶端使用用戶名跟密碼請(qǐng)求登錄

服務(wù)端收到請(qǐng)求，去驗(yàn)證用戶名與密碼

驗(yàn)證成功后，服務(wù)端會(huì)簽發(fā)一個(gè)Token，再把這個(gè)Token發(fā)送給客戶端

客戶端收到Token以后可以把它存儲(chǔ)起來(lái)，比如放在Cookie里或者LocalStorage里

客戶端每次向服務(wù)端請(qǐng)求資源的時(shí)候需要帶著服務(wù)端簽發(fā)的Token

服務(wù)端收到請(qǐng)求，然后去驗(yàn)證客戶端請(qǐng)求里面帶著的Token，如果驗(yàn)證成功，就向客戶端返回請(qǐng)求的數(shù)據(jù)

傳統(tǒng)身份驗(yàn)證的方法

HTTP是一種沒有狀態(tài)的協(xié)議，也就是它并不知道是誰(shuí)是訪問應(yīng)用。這里我們把用戶看成是客戶端，客戶端使用用戶名還有密碼通過了身份驗(yàn)證，不過下回這個(gè)客戶端再發(fā)送請(qǐng)求時(shí)候，還得再驗(yàn)證一下。

解決的方法就是，當(dāng)用戶請(qǐng)求登錄的時(shí)候，如果沒有問題，我們?cè)诜��?wù)端生成一條記錄，這個(gè)記錄里可以說明一下登錄的用戶是誰(shuí)，然后把這條記錄的ID號(hào)發(fā)送給客戶端，客戶端收到以后把這個(gè)ID號(hào)存儲(chǔ)在Cookie里，下次這個(gè)用戶再向服務(wù)端發(fā)送請(qǐng)求的時(shí)候，可以帶著這個(gè)Cookie，這樣服務(wù)端會(huì)驗(yàn)證一個(gè)這個(gè)Cookie里的信息，看看能不能在服務(wù)端這里找到對(duì)應(yīng)的記錄，如果可以，說明用戶已經(jīng)通過了身份驗(yàn)證，就把用戶請(qǐng)求的數(shù)據(jù)返回給客戶端。

上面說的就是Session，我們需要在服務(wù)端存儲(chǔ)為登錄的用戶生成的Session，這些Session可能會(huì)存儲(chǔ)在內(nèi)存，磁盤，或者數(shù)據(jù)庫(kù)里。我們可能需要在服務(wù)端定期的去清理過期的Session。

基于Token的身份驗(yàn)證方法

使用基于Token的身份驗(yàn)證方法，在服務(wù)端不需要存儲(chǔ)用戶的登錄記錄。大概的流程是這樣的：

客戶端使用用戶名跟密碼請(qǐng)求登錄

服務(wù)端收到請(qǐng)求，去驗(yàn)證用戶名與密碼

驗(yàn)證成功后，服務(wù)端會(huì)簽發(fā)一個(gè)Token，再把這個(gè)Token發(fā)送給客戶端

客戶端收到Token以后可以把它存儲(chǔ)起來(lái)，比如放在Cookie里或者LocalStorage里

客戶端每次向服務(wù)端請(qǐng)求資源的時(shí)候需要帶著服務(wù)端簽發(fā)的Token

服務(wù)端收到請(qǐng)求，然后去驗(yàn)證客戶端請(qǐng)求里面帶著的Token，如果驗(yàn)證成功，就向客戶端返回請(qǐng)求的數(shù)據(jù)

3.常見問題

基于服務(wù)器驗(yàn)證方式暴露的一些問題

1.Seesion：每次認(rèn)證用戶發(fā)起請(qǐng)求時(shí)，服務(wù)器需要去創(chuàng)建一個(gè)記錄來(lái)存儲(chǔ)信息。當(dāng)越來(lái)越多的用戶發(fā)請(qǐng)求時(shí)，內(nèi)存的開銷也會(huì)不斷增加。

2.可擴(kuò)展性：在服務(wù)端的內(nèi)存中使用Seesion存儲(chǔ)登錄信息，伴隨而來(lái)的是可擴(kuò)展性問題。

3.CORS(跨域資源共享)：當(dāng)我們需要讓數(shù)據(jù)跨多臺(tái)移動(dòng)設(shè)備上使用時(shí)，跨域資源的共享會(huì)是一個(gè)讓人頭疼的問題。在使用Ajax抓取另一個(gè)域的資源，就可以會(huì)出現(xiàn)禁止請(qǐng)求的情況。

4.CSRF(跨站請(qǐng)求偽造)：用戶在訪問銀行網(wǎng)站時(shí)，他們很容易受到跨站請(qǐng)求偽造的攻擊，并且能夠被利用其訪問其他的網(wǎng)站。在這些問題中，可擴(kuò)展行是最突出的。因此我們有必要去尋求一種更有行之有效的方法。

4.解決方案

基于Token的身份驗(yàn)證的過程如下:

1.用戶通過用戶名和密碼發(fā)送請(qǐng)求。

2.程序驗(yàn)證。

3.程序返回一個(gè)簽名的token給客戶端。

4.客戶端儲(chǔ)存token,并且每次用于每次發(fā)送請(qǐng)求。

5.服務(wù)端驗(yàn)證token并返回?cái)?shù)據(jù)。

token有一定的時(shí)效，過期之后需要重新向登陸認(rèn)證，拿到新的token；

移動(dòng)客戶端向服務(wù)器登陸時(shí)，需要提供包含token的認(rèn)證，服務(wù)器需要向渠道認(rèn)證包含token的認(rèn)證信息，如果渠道返回有效，則認(rèn)為移動(dòng)客戶端為合法；

過程中經(jīng)常會(huì)斷線重連，每次重連過程相當(dāng)于走一次向服務(wù)器登錄的過程，服務(wù)器也會(huì)將token向渠道服務(wù)器進(jìn)行了認(rèn)證，但是token的時(shí)效性，導(dǎo)致一段時(shí)間之后的斷線重連會(huì)被拒絕；

一種解決方案是：每次斷線重連的時(shí)候，先向服務(wù)器登陸，申請(qǐng)新的token；另一種是：當(dāng)服務(wù)器得到的反饋是token已經(jīng)過期，那么告知客戶端重新向渠道服務(wù)器獲取，然后帶著新的token進(jìn)行斷線重連操作。相對(duì)于可能頻繁的獲取token，更趨向于第二種方法，從經(jīng)驗(yàn)來(lái)看，大部分token的時(shí)效是按照小時(shí)來(lái)計(jì)算的