1. JWT令牌詳解
JWT是JSON Web Token的縮寫,是一個輕巧的規范,一個開放的行業標准,它定義了一種簡潔的、自包含的協議格式,這個規范允許我們使用JWT在用戶和伺服器之間傳遞安全可靠的消息.
一個JWT實際上就是一個字元串,它由三部分組成,頭部、荷載與簽名
頭部描述關於該JWT的最基本的信息,例如其類型以及簽名所用的演算法等
例如{"type":"JWT","alg":"HS256"}
其頭部指明了簽名演算法是HS256演算法
HMAC演算法(非對稱的)
SH256
RSA
荷載就是存放有效信息的地方
定義一個payload:{"sub":"1234567890","name":"John Doe","admin":true}
簽證又由三部分組成,base64加密後的header和base64加密後的payload使用,連接組成的字元串
然後通過header中聲明的加密方式進行加鹽secret組合加密.
1、jwt基於json,非常方便解析
2、可以在令牌中自定義豐富的內容,易擴張
3、通過非對稱加密演算法以及數字簽名技術,JWT防止篡改,安全性高
4、資源服務使用JWT可不依賴認證服務即可完成授權
JWT令牌較長,占存儲空間比較大.
一個公鑰對應一個私鑰,私鑰作為簽名給JWT加密,那麼這里需要生成與之對應的公鑰:
輸入密鑰庫口令: keytool -list -keystore changgou.jks
顯示的信息為:
密鑰庫類型: jks
密鑰庫提供方: SUN
您的密鑰庫包含 1 個條目
changgou, 2020-7-28, PrivateKeyEntry,
證書指紋 (SHA1): 45:2E:51:8B:84:86:03:8C:AF:99:14:5F:4F:D6:98:33:39:92:33:79
輸入命令後就可以得到公鑰:
注釋:classPathResource:私鑰位置;
new KeyStoreKeyFactory:創建私鑰工廠,需要私鑰庫密碼和私鑰位置兩個參數;
keyStoreKeyFactory.getKeyPair(alias,password.toCharArray):獲取keyPair對象,keyPair.getPrivate()即是獲取私鑰;
根據私鑰獲取令牌:JwtHelper.encode(JSON.toJSONString(map,new RsaSigner(rsaPrivateKey));
2. SpringSecurity+JWT認證流程解析
本文適合： 對Spring Security有一點了解或者跑過簡單demo但是對整體運行流程不明白的同學，對SpringSecurity有興趣的也可以當作你們的入門教程，示例代碼中也有很多注釋。
大家在做系統的時候，一般做的第一個模塊就是 認證與授權 模塊，因為這是一個系統的入口，也是一個系統最重要最基礎的一環，在認證與授權服務設計搭建好了之後，剩下的模塊才得以安全訪問。
市面上一般做認證授權的框架就是shiro和Spring Security，也有大部分公司選擇自己研製。出於之前看過很多Spring Security的入門教程，但都覺得講的不是太好，所以我這兩天在自己鼓搗Spring Security的時候萌生了分享一下的想法，希望可以幫助到有興趣的人。
Spring Security框架我們主要用它就是解決一個認證授權功能，所以我的文章主要會分為兩部分：
我會為大家用一個Spring Security + JWT + 緩存的一個demo來展現我要講的東西，畢竟腦子的東西要體現在具體事物上才可以更直觀的讓大家去了解去認識。
學習一件新事物的時候，我推薦使用自頂向下的學習方法，這樣可以更好的認識新事物，而不是盲人摸象。
注 ：只涉及到用戶認證授權不涉及oauth2之類的第三方授權。
想上手 Spring Security 一定要先了解它的工作流程，因為它不像工具包一樣，拿來即用，必須要對它有一定的了解，再根據它的用法進行自定義操作。
我們可以先來看看它的工作流程：
在Spring Security的官方文檔上有這么一句話：
Spring Security 的web基礎是Filters。
這句話展示了Spring Security的設計思想： 即通過一層層的Filters來對web請求做處理。
放到真實的Spring Security中，用文字表述的話可以這樣說:
一個web請求會經過一條過濾器鏈，在經過過濾器鏈的過程中會完成認證與授權，如果中間發現這條請求未認證或者未授權，會根據被保護API的許可權去拋出異常，然後由異常處理器去處理這些異常。
用圖片表述的話可以這樣畫，這是我在網路找到的一張圖片：
如上圖，一個請求想要訪問到API就會以從左到右的形式經過藍線框框裡面的過濾器，其中綠色部分是我們本篇主要講的負責認證的過濾器，藍色部分負責異常處理，橙色部分則是負責授權。
圖中的這兩個綠色過濾器我們今天不會去說，因為這是Spring Security對form表單認證和Basic認證內置的兩個Filter，而我們的demo是JWT認證方式所以用不上。
如果你用過Spring Security就應該知道配置中有兩個叫formLogin和httpBasic的配置項，在配置中打開了它倆就對應著打開了上面的過濾器。
換言之，你配置了這兩種認證方式，過濾器鏈中才會加入它們，否則它們是不會被加到過濾器鏈中去的。
因為Spring Security自帶的過濾器中是沒有針對JWT這種認證方式的，所以我們的demo中會 寫一個JWT的認證過濾器，然後放在綠色的位置進行認證工作。
知道了Spring Security的大致工作流程之後，我們還需要知道一些非常重要的概念也可以說是組件：
上下文對象，認證後的數據就放在這裡面，介面定義如下：
這個介面裡面只有兩個方法，其主要作用就是get or set Authentication。
可以說是SecurityContext的工具類，用於get or set or clear SecurityContext，默認會把數據都存儲到當前線程中。
這幾個方法效果如下：
Authentication只是定義了一種在SpringSecurity進行認證過的數據的數據形式應該是怎麼樣的，要有許可權，要有密碼，要有身份信息，要有額外信息。
AuthenticationManager定義了一個認證方法，它將一個未認證的Authentication傳入，返回一個已認證的Authentication，默認使用的實現類為：ProviderManager。
接下來大家可以構思一下如何將這四個部分，串聯起來，構成Spring Security進行認證的流程：
1. 先是一個請求帶著身份信息進來
2. 經過AuthenticationManager的認證，
3. 再通過SecurityContextHolder獲取SecurityContext，
4. 最後將認證後的信息放入到SecurityContext。
真正開始講訴我們的認證代碼之前，我們首先需要導入必要的依賴，資料庫相關的依賴可以自行選擇什麼JDBC框架，我這里用的是國人二次開發的myabtis-plus。
接著，我們需要定義幾個必須的組件。
由於我用的Spring-Boot是2.X所以必須要我們自己定義一個加密器：
這個Bean是不必可少的，Spring Security在認證操作時會使用我們定義的這個加密器，如果沒有則會出現異常。
實現UserDetailsService的抽象方法並返回一個 UserDetails 對象，認證過程中SpringSecurity會調用這個方法訪問資料庫進行對用戶的搜索，邏輯什麼都可以自定義，無論是從資料庫中還是從緩存中，但是我們需要將我們查詢出來的用戶信息和許可權信息組裝成一個 UserDetails 返回。
UserDetails 也是一個定義了數據形式的介面，用於保存我們從資料庫中查出來的數據，其功能主要是驗證賬號狀態和獲取許可權，具體實現可以查閱我倉庫的代碼。
由於我們是JWT的認證模式，所以我們也需要一個幫我們操作Token的工具類，一般來說它具有以下三個方法就夠了：
在下文我的代碼裡面，JwtProvider充當了Token工具類的角色，具體實現可以查閱我倉庫的代碼。
有了前面的講解之後，大家應該都知道用SpringSecurity做JWT認證需要我們自己寫一個過濾器來做JWT的校驗，然後將這個過濾器放到綠色部分。
在我們編寫這個過濾器之前，我們還需要進行一個認證操作，因為我們要先訪問認證介面拿到token，才能把token放到請求頭上，進行接下來請求。
如果你不太明白，不要緊，先接著往下看我會在這節結束再次梳理一下。
訪問一個系統，一般最先訪問的是認證方法，這里我寫了最簡略的認證需要的幾個步驟，因為實際系統中我們還要寫登錄記錄啊，前台密碼解密啊這些操作。
這里一共五個步驟，大概只有前四步是比較陌生的：
這樣的話就算完成了，感覺上很簡單，因為主要認證操作都會由authenticationManager.authenticate()幫我們完成。
接下來我們可以看看源碼，從中窺得Spring Security是如何幫我們做這個認證的（省略了一部分）：
看了源碼之後你會發現和我們平常寫的一樣，其主要邏輯也是查資料庫然後對比密碼。
登錄之後效果如下：
我們返回token之後，下次請求其他API的時候就要在請求頭中帶上這個token，都按照JWT的標准來做就可以。
有了token之後，我們要把過濾器放在過濾器鏈中，用於解析token，因為我們沒有session，所以我們每次去辨別這是哪個用戶的請求的時候，都是根據請求中的token來解析出來當前是哪個用戶。
所以我們需要一個過濾器去攔截所有請求，前文我們也說過，這個過濾器我們會放在綠色部分用來替代，所以我們新建一個JwtAuthenticationTokenFilter，然後將它注冊為Bean，並在編寫配置文件的時候需要加上這個：
addFilterBefore的語義是添加一個Filter到XXXFilter之前，放在這里就是把JwtAuthenticationTokenFilter放在之前，因為filter的執行也是有順序的，我們必須要把我們的filter放在過濾器鏈中綠色的部分才會起到自動認證的效果。
接下來我們可以看看JwtAuthenticationTokenFilter的具體實現了：
代碼里步驟雖然說的很詳細了，但是可能因為代碼過長不利於閱讀，我還是簡單說說，也可以直接去倉庫查看源碼：
這樣的話，每一個帶有正確token的請求進來之後，都會找到它的賬號信息，並放在上下文對象中，我們可以使用SecurityContextHolder很方便的拿到上下文對象中的Authentication對象。
完成之後，啟動我們的demo，可以看到過濾器鏈中有以下過濾器，其中我們自定義的是第5個：
就醬，我們登錄完了之後獲取到的賬號信息與角色信息我們都會放到緩存中，當帶著token的請求來到時，我們就把它從緩存中拿出來，再次放到上下文對象中去。
結合認證方法，我們的邏輯鏈就變成了：
登錄拿到token請求帶上tokenJWT過濾器攔截校驗token將從緩存中查出來的對象放到上下文中
這樣之後，我們認證的邏輯就算完成了。
認證和JWT過濾器完成後，這個JWT的項目其實就可以跑起來了，可以實現我們想要的效果，如果想讓程序更健壯，我們還需要再加一些輔助功能，讓代碼更友好。
當用戶未登錄或者token解析失敗時會觸發這個處理器，返回一個非法訪問的結果。
當用戶本身許可權不滿足所訪問API需要的許可權時，觸發這個處理器，返回一個許可權不足的結果。
用戶退出一般就是清除掉上下文對象和緩存就行了，你也可以做一下附加操作，這兩步是必須的。
JWT的項目token刷新也是必不可少的，這里刷新token的主要方法放在了token工具類裡面，刷新完了把緩存重載一遍就行了，因為緩存是有有效期的，重新put可以重置失效時間。
這篇文我從上周日就開始構思了，為了能講的老嫗能解，修修改改了幾遍才發出來。
作者：和耳朵
鏈接：https://juejin.cn/post/6846687598442708999
3. JWT-token—前後端分離架構的api安全問題
前後端分離架構帶來的好處一搜一大堆，我們來看一下分離後後端介面的安全問題。
前後端分離架構現狀：
這樣的情況後端api是暴露在外網中，因為常規的web項目無論如何前端都是要通過公網訪問到後台api的，帶來的隱患也有很多。
1.介面公開，誰都可以訪問
2.數據請求的參數在傳輸過程被篡改
3.介面被重復調用
...
session和cookie都是客戶端與服務端通訊需要提供的認證，當客戶端的值和伺服器的值吻合時，才允許請求api，解決了第1個問題，但是當攻擊者獲取到了傳輸過程中的session或者cookie值後，就可以進行第2、3種攻擊了
JWT標準的token包含三部分：
頭部用於描述關於該JWT的最基本的信息，例如其類型以及簽名所用的演算法等
將上面的JSON對象進行 [base64編碼] 可以得到下面的字元串。這個字元串我們將它稱作JWT的Header
Payload也是一個JSON對象。包含了一些其他的信息
這裡面的前五個欄位都是由JWT的標准所定義的。
將上面的JSON對象進行 [base64編碼] 可以得到下面的字元串。這個字元串我們將它稱作JWT的Payload
將上面的兩個編碼後的字元串都用句號 . 連接在一起（頭部在前），就形成了
最後，我們將上面拼接完的字元串用 HS256演算法 進行加密。在加密的時候，我們還需要提供一個 密鑰（secret） 。如果我們用 mystar 作為密鑰的話，那麼就可以得到我們加密後的內容
這一部分叫做 簽名
最後將這一部分簽名也拼接在被簽名的字元串後面，我們就得到了完整的JWT
簽名解決了數據傳輸過程中參數被篡改的風險
一般而言，加密演算法對於不同的輸入產生的輸出總是不一樣的，如果有人 對Header以及Payload的內容解碼之後進行修改，再進行編碼的話，那麼新的頭部和載荷的簽名和之前的簽名就將是不一樣的。 而且，如果不知道伺服器加密的時候用的密鑰的話，得出來的簽名也一定會是不一樣的。
解決了篡改數據的問題，還有第3個問題，那就是攻擊者不修改數據，只是重復攻擊
比如在瀏覽器端通過用戶名/密碼驗證獲得簽名的Token被木馬竊取。即使用戶登出了系統，黑客還是可以利用竊取的Token模擬正常請求，而伺服器端對此完全不知道， 因為JWT機制是無狀態的。
可以在Payload里增加時間戳並且前後端都參與來解決：
4. ID Token - JWT
我們來繼續前兩章（ OAuth2 總結 , 對OpenID Connect的理解 ）的討論，進入對JWT的理解。先來簡單回顧一下OAuth2和OpenID：
OpenID建立在OAuth之上，完成了認證和授權。而認證和授權的結果就體現在這個ID token之上，而這個ID token通常會是JWT。那麼為什麼會是JWT呢？我們通過以下幾點來逐一解釋。
JWT RFC 7519 給出了官方定義的一些欄位：
當然也不限於此，可以根據自己的需要，添加其他欄位。到此，我們可以看出JWT提供了ID token所需要的能力。一個完整的JTW是由三部分組成：Header，Payload，Signature。三者之間由 . 隔開，剛才提到的認證授權的欄位就存在於Payload中。
Header中存放的是JTW的元數據，包含簽名的演算法以及token的類型，如下所示：
Signature部分是對前兩部分的簽名， 防止數據篡改 。首先，需要指定一個密鑰（secret）。這個密鑰只有伺服器才知道，不能泄露給用戶。然後，使用 Header 裡面指定的簽名演算法（默認是 HMAC SHA256），按照下面的公式產生簽名。
算出簽名以後，把 Header、Payload、Signature三個部分經過base64序列化為三個字元串，再講三個字元串由 . 為間隔拼接成一個字元串返回給客戶端。
ID Token需要有足夠的安全性，JWT是如何做到的呢？
剛看到了簽名部分，簽名的作用只是為了防止數據篡改，而JWT默認是不加密，但也是可以加密的。生成原始 Token 以後，可以用密鑰再加密一次。比如認證伺服器中使用私鑰進行加密，把公鑰分發給其他應用伺服器，應用服務拿到加密後的token後用公鑰解密，獲取到JWT，再用簽名的秘鑰來驗證數據是否經過的篡改。
我們來看看還有神馬其他備選么？Simple Web Tokens (SWT)和Security Assertion Markup Language Tokens (SAML)。
JWT vs SAML：JWT基於json，而SAML基於XML，在大小上就有足夠的優勢，更適用於HTML和HTTP。
JWT vs SWT：在安全性上，SWT只支持對稱加密，而JWT和SAML支持公私鑰的加密方式。
作為一個mobile developer，也想在這里對比一下原先的簡單token模式和SSO中的JWT：
在沒有該機制前，我們通常會使用一個隨機產生的字元串作為token，認證成功後返回給前端，之後前端的每個請求帶上這個token。若後台服務的是個單體應用沒有什麼問題，請求來了，驗證一下token是否有效即可，但當認證服務和其他的應用服務是分離的，怎麼做呢？應用服務受到請求，再向認證服務發起一個請求來驗證驗證token是否合法，是否有許可權訪問該應用服務。這樣做到沒有什麼問題，只是當服務變多時，比如微服務下，勢必會造成認證伺服器的壓力過大。
在使用該機制後，客戶端通過認證服務登錄，獲得這個JWT，之後其他應用服務自身便可以驗證這個token的是否有效，是否有權訪問。
看似完美，但也有它自身的問題，我們來看一個場景：許可權變更。某用戶原先是一個超級管理員，可以訪問所有服務，並可進行任意的刪除，更改操作，他在這個狀態下拿到了JWT。隨後，由於許可權更改為普通管理員，便不應該具有所有許可權，但此時他開始時的JWT被緩存在客戶端仍然可用，其他應用服務也並無法知道這個用戶的許可權已經被更改，後果可想而知了。解決的方式無非是將這個token的有效時間設置的短一些。
5. JWT生成token及過期處理方案
## 業務場景
在前後分離場景下，越來越多的項目使用token作為介面的安全機制，APP端或者WEB端（使用VUE、REACTJS等構建）使用token與後端介面交互，以達到安全的目的。本文結合stackoverflow以及本身項目實踐，試圖總結出一個通用的，可落地的方案。
## 基本思路
- 單個token
1. token（A）過期設置為15分鍾
2. 前端發起請求，後端驗證token（A）是否過期；如果過期，前端發起刷新token請求，後端設置已再次授權標記為true，請求成功
3. 前端發起請求，後端驗證再次授權標記，如果已經再次授權，則拒絕刷新token的請求，請求成功
4. 如果前端每隔72小時，必須重新登錄，後端檢查用戶最後一次登錄日期，如超過72小時，則拒絕刷新token的請求，請求失敗
- 授權token加上刷新token
用戶僅登錄一次，用戶改變密碼，則廢除token，重新登錄
## 1.0實現
1.登錄成功，返回access\_token和refresh\_token，客戶端緩存此兩種token;
2.使用access_token請求介面資源，成功則調用成功；如果token超時，客戶端
攜帶refresh\_token調用中間件介面獲取新的access\_token;
3.中間件接受刷新token的請求後，檢查refresh_token是否過期。
如過期，拒絕刷新，客戶端收到該狀態後，跳轉到登錄頁；
如未過期，生成新的access\_token和refresh\_token並返回給客戶端（如有可能，讓舊的refresh\_token失效），客戶端攜帶新的access\_token重新調用上面的資源介面。
4.客戶端退出登錄或修改密碼後，調用中間件注銷舊的token(使access\_token和refresh\_token失效)，同時清空客戶端的access\_token和refresh\_toke。
後端表
id user\_id client\_id client\_secret refresh\_token expire\_in create\_date del_flag
## 2.0實現
場景： access\_token訪問資源 refresh\_token授權訪問 設置固定時間X必須重新登錄
1.登錄成功，後台jwt生成access\_token（jwt有效期30分鍾）和refresh\_token（jwt有效期15天），並緩存到redis（hash-key為token,sub-key為手機號,value為設備唯一編號（根據手機號碼，可以人工廢除全部token，也可以根據sub-key,廢除部分設備的token。），設置過期時間為1個月，保證最終所有token都能刪除)，返回後，客戶端緩存此兩種token;
2.使用access\_token請求介面資源，校驗成功且redis中存在該access\_token（未廢除）則調用成功；如果token超時，中間件刪除access\_token（廢除）；客戶端再次攜帶refresh\_token調用中間件介面獲取新的access_token;
3.中間件接受刷新token的請求後，檢查refresh_token是否過期。
如過期，拒絕刷新，刪除refresh_token（廢除）； 客戶端收到該狀態後，跳轉到登錄頁；
如未過期，檢查緩存中是否有refresh\_token（是否被廢除），如果有，則生成新的access\_token並返回給客戶端，客戶端接著攜帶新的access_token重新調用上面的資源介面。
4.客戶端退出登錄或修改密碼後，調用中間件注銷舊的token(中間件刪除access\_token和refresh\_token（廢除）)，同時清空客戶端側的access\_token和refresh\_toke。
5.如手機丟失，可以根據手機號人工廢除指定用戶設備關聯的token。
6.以上3刷新access_token可以增加根據登錄時間判斷最長X時間必須重新登錄，此時則拒絕刷新token。（拒絕的場景：失效，長時間未登錄，頻繁刷新）
2.0 變動
1.登錄
2.登錄攔截器
3.增加刷新access_token介面
4.退出登錄
5.修改密碼
## 3.0實現
場景：自動續期 長時間未使用需重新登錄
1.登錄成功，後台jwt生成access\_token（jwt有效期30分鍾），並緩存到redis（hash-key為access\_token,sub-key為手機號,value為設備唯一編號（根據手機號碼，可以人工廢除全部token），設置access_token過期時間為7天，保證最終所有token都能刪除)，返回後，客戶端緩存此token;
2.使用access\_token請求介面資源，校驗成功且redis中存在該access\_token（未廢除）則調用成功；如果token超時，中間件刪除access\_token（廢除）,同時生成新的access\_token並返回。客戶端收到新的access_token，
再次請求介面資源。
3.客戶端退出登錄或修改密碼後，調用中間件注銷舊的token(中間件刪除access\_token（廢除）)，同時清空客戶端側的access\_token。
4.以上2 可以增加根據登錄時間判斷最長X時間必須重新登錄，此時則拒絕刷新token。（拒絕的場景：長時間未登錄，頻繁刷新）
5.如手機丟失，可以根據手機號人工廢除指定用戶設備關聯的token。
3.0 變動
1.登錄
2.登錄攔截器
3.退出登錄
4.修改密碼
1.3 場景：token過期重新登錄 長時間未使用需重新登錄
1.登錄成功，後台jwt生成access\_token（jwt有效期7天），並緩存到redis，key為 "user\_id:access\_token",value為access\_token（根據用戶id，可以人工廢除指定用戶全部token），設置緩存過期時間為7天，保證最終所有token都能刪除，請求返回後，客戶端緩存此access_token；
2.使用access\_token請求介面資源，校驗成功且redis中存在該access\_token（未廢除）則調用成功；如果token超時，中間件刪除access\_token（廢除）,同時生成新的access\_token並返回。客戶端收到新的access_token，
再次請求介面資源。
3.客戶端退出登錄或修改密碼後，調用中間件注銷舊的token(中間件刪除access\_token（廢除）)，同時清空客戶端側的access\_token。
4.以上2 可以增加根據登錄時間判斷最長X時間必須重新登錄，此時則拒絕刷新token。（拒絕的場景：長時間未登錄，頻繁刷新）
5.如手機丟失，可以根據手機號人工廢除指定用戶設備關聯的token。
1.3 變動
1.登錄
2.登錄攔截器
3.退出登錄
4.修改密碼
# 解決方案
2.0 場景： access\_token訪問資源 refresh\_token授權訪問 設置固定時間X必須重新登錄
1.登錄成功，後台jwt生成access\_token（jwt有效期30分鍾）和refresh\_token（jwt有效期15天），並緩
存到redis（hash-key為token,sub-key為手機號,value為設備唯一編號（根據手機號碼，可以人工廢除全
部token，也可以根據sub-key,廢除部分設備的token。），設置過期時間為1個月，保證最終所有token都
能刪除)，返回後，客戶端緩存此兩種token;
2.使用access\_token請求介面資源，校驗成功且redis中存在該access\_token（未廢除）則調用成功；如果
token超時，中間件刪除access\_token（廢除）；客戶端再次攜帶refresh\_token調用中間件介面獲取新的
access_token;
3.中間件接受刷新token的請求後，檢查refresh_token是否過期。
如過期，拒絕刷新，刪除refresh_token（廢除）； 客戶端收到該狀態後，跳轉到登錄頁；
如未過期，檢查緩存中是否有refresh\_token（是否被廢除），如果有，則生成新的access\_token並返回給
客戶端，客戶端接著攜帶新的access_token重新調用上面的資源介面。
4.客戶端退出登錄或修改密碼後，調用中間件注銷舊的token(中間件刪除access\_token和refresh\_token（
廢除）)，同時清空客戶端側的access\_token和refresh\_toke。
5.如手機丟失，可以根據手機號人工廢除指定用戶設備關聯的token。
6.以上3刷新access_token可以增加根據登錄時間判斷最長X時間必須重新登錄，此時則拒絕刷新token。（
拒絕的場景：失效，長時間未登錄，頻繁刷新）
2.0 變動
1.登錄
2.登錄攔截器
3.增加刷新access_token介面
4.退出登錄
5.修改密碼
3.0 場景：自動續期 長時間未使用需重新登錄
1.登錄成功，後台jwt生成access_token（jwt有效期30分鍾），並緩存到redis（hash-key為
access_token,sub-key為手機號,value為設備唯一編號（根據手機號碼，可以人工廢除全部token，也可以
根據sub-key,廢除部分設備的token。），設置access_token過期時間為1個月，保證最終所有token都能刪
除)，返回後，客戶端緩存此token;
2.使用access\_token請求介面資源，校驗成功且redis中存在該access\_token（未廢除）則調用成功；如果
token超時，中間件刪除access\_token（廢除）,同時生成新的access\_token並返回。客戶端收到新的
access_token，
再次請求介面資源。
3.客戶端退出登錄或修改密碼後，調用中間件注銷舊的token(中間件刪除access_token（廢除）)，同時清
空客戶端側的access_token。
4.以上2 可以增加根據登錄時間判斷最長X時間必須重新登錄，此時則拒絕刷新token。（拒絕的場景：長
時間未登錄，頻繁刷新）
5.如手機丟失，可以根據手機號人工廢除指定用戶設備關聯的token。
3.0 變動
1.登錄
2.登錄攔截器
3.退出登錄
4.修改密碼
4.0 場景：token過期重新登錄 長時間未使用需重新登錄
1.登錄成功，後台jwt生成access_token（jwt有效期7天），並緩存到redis，key為
"user\_id:access\_token" + 用戶id,value為access_token（根據用戶id，可以人工廢除指定用戶全部
token），設置緩存過期時間為7天，保證最終所有token都能刪除，請求返回後，客戶端緩存此
access_token；
2.使用access\_token請求介面資源，校驗成功且redis中存在該access\_token（未廢除）則調用成功；如果
token超時，中間件刪除access\_token（廢除）,同時生成新的access\_token並返回。客戶端收到新的
access_token，
再次請求介面資源。
3.客戶端退出登錄或修改密碼後，調用中間件注銷舊的token(中間件刪除access_token（廢除）)，同時清
空客戶端側的access_token。
4.以上2 可以增加根據登錄時間判斷最長X時間必須重新登錄，此時則拒絕刷新token。（拒絕的場景：長
時間未登錄，頻繁刷新）
5.如手機丟失，可以根據手機號人工廢除指定用戶設備關聯的token。
4.0 變動
1.登錄
2.登錄攔截器
3.退出登錄
4.修改密碼
## 最終實現
### 後端
1. 在登錄介面中 如果校驗賬號密碼成功 則根據用戶id和用戶類型創建jwt token(有效期設置為-1，即永不過期),得到A
2. 更新登錄日期(當前時間new Date()即可)（業務上可選），得到B
3. 在redis中緩存key為ACCESS_TOKEN:userId:A(加上A是為了防止用戶多個客戶端登錄 造成token覆蓋),value為B的毫秒數（轉換成字元串類型），過期時間為7天（7 * 24 * 60 * 60）
4. 在登錄結果中返回json格式為{"result":"success","token": A}
5. 用戶在介面請求header中攜帶token進行登錄，後端在所有介面前置攔截器進行攔截，作用是解析token 拿到userId和用戶類型（用戶調用業務介面只需要傳token即可），
如果解析失敗（拋出SignatureException），則返回json（code = 0 ,info= Token驗證不通過, errorCode = '1001'）；
此外如果解析成功，驗證redis中key為ACCESS_TOKEN:userId:A 是否存在 如果不存在 則返回json（code = 0 ,info= 會話過期請重新登錄, errorCode = '1002'）；
如果緩存key存在，則自動續7天超時時間（value不變），實現頻繁登錄用戶免登陸。
6. 把userId和用戶類型放入request參數中 介面方法中可以直接拿到登錄用戶信息
7. 如果是修改密碼或退出登錄 則廢除access_tokens（刪除key）
### 前端（VUE）
1. 用戶登錄成功，則把username存入cookie中，key為loginUser;把token存入cookie中，key為accessToken
把token存入Vuex全局狀態中
2. 進入首頁
6. 前端怎麼解析json
不建議使用eval（）函數，因為eval（）接受任意的字元串，並當作JavaScript代碼來處理,這個機制已經有安全隱患了var str='{ "name": "John" }';var obj = eval ('(' + str + ')');alert(obj.name); $.parseJSON()和JSON.parse()函數用於將格式完好的JSON字元串轉為與之對應的JavaScript對象。所謂"格式完好"，就是要求指定的字元串必須符合嚴格的JSON格式，例如：屬性名稱必須加雙引號、字元串值也必須用雙引號。其次，JSON標准不允許字元串中出現"控制字元"，正確寫法應該是使用兩個反斜杠，以免被JS解析器直接轉義。 1、JSON字元串轉換為JSON對象var str='{ "name": "John" ,"age": "24" }';var obj = $.parseJSON(str);alert(obj.name); //John var str = '{ "name": "John", "age": "24" }';var obj = JSON.parse(str);alert(obj.name); //John 2、將JSON對象轉換為字元串var obj={name: "John", age: "24"};var last=JSON.stringify(obj);alert(last); //'{name: "John", age: "24"}' var obj={name: "John", age: "24"};var last=obj.toJSONString();alert(last); //'{name: "John", age: "24"}' 3、解析讀取json對象var str={ "result":{ "age":"33", "id":"2server", "name":"mady" }};alert(str.result.age); //33 var result = $.parseJSON( '[ 1, true, "CodePlayer" ]' );alert( result[1] ); // CodePlayer var result = $.parseJSON( "\"專注於編程開發技術分享\"" );alert(result); //專注於編程開發技術分享
7. Springboot security oauth2 jwt實現許可權控制，實現微服務獲取當前用戶信息
在原先bbo+zookeeper項目中，web模塊只暴露Restful介面，各服務模塊只暴露boo介面，此時用戶登錄後由web項目進行token的鑒權和驗證，並通過bbo的隱式傳參將sessionID傳遞給bbo服務模塊, 攔截器再根據sessionID從Redis中獲取用戶信息設置到當前線程
然鵝，在springcloud中，各個微服務直接暴露的是restful介面，此時如何讓各個微服務獲取到當前用戶信息呢？最佳的方式就是token了，token作為BS之間的會話標識（一般是原生隨機token），同時也可以作為信息的載體傳遞一些自定義信息（jwt， 即Json web token）。
為了能更清楚的了解本文，需要對spring-security-oauth 及 jwt有一定了解，本文只關注用戶信息傳遞這一塊
認證伺服器配置
自定義token轉換器
CustomJwtAccessTokenConverter
此時按照固定格式訪問授權伺服器token介面獲取token，如圖，可以獲取到jwt格式的token，並且額外信息nick_name也已經添加
直接解析jwt字元串可以獲取到以下信息，即用戶名和授權信息
只需要指定和授權伺服器一模一樣的token store 和token converter
在securiy的過濾器中 會從token中獲取相關信息進行鑒權
源碼：
注意，資源伺服器主要配置在
微服務獲取jwttoken中的用戶信息，兩種方式，使用security上下文可以直接獲取當前用戶名和許可權，另一種自定義攔截器獲取額外信息。
這個就簡單了，獲取header頭解析驗證token
然後獲取之前從授權伺服器中的添加的 nick_name的額外信息放入線程變數
其中用戶上下文類
啟動攔截器注冊webmvc配置類
在controller中獲取用戶信息如圖
在默認的認證異常如圖
假設我們做了全局異常處理，前端希望在token過期時做統一的登錄跳轉如何做？
實現 AuthenticationEntryPoint 介面重寫 commence 方法即可
注意，直接拋出異常並不會走 @RestControllerAdvice , 因為在這里是response直接返回，並沒有使用到Controller處理
此時返回我自定義的Response對象，如圖