1 用戶認證與授權
1-1認證授權的基礎知識
UAA：User Account and Authentication。
認證定義：判斷一個用戶的身份是否合法的過程
常見的認證方式：
1) 用戶名密碼登錄
2) 二維碼登錄
3) 手機短信登錄
4) 指紋認證
授權定義：根據用戶的權限授予用戶訪問的資源（授權是在用戶認證之后）
1-1-1 認證的實現方式：會話
會話機制：系統為了保持當前用戶的登錄狀態所提供的機制
會話機制的實現手段：
1)基於session方式
2)基於token方式
1-1-2 基於session的認證機制
基於session的認證流程（session_id）
1）用戶首次認證成功后，在服務端生成用戶相關的數據保存在session(當前會話)中，發給客戶端的sesssion_id 存放到 cookie
2）用戶客戶端請求時帶上 session_id 就可以驗證服務器端是否存在 session 數據，以此完成用戶的合法校驗
3）當用戶退出系統或session過期銷毀時,客戶端的session_id也就無效了。
1-1-3 基於token的認證機制
1)用戶認證成功后，服務端生成一個token發給客戶端
2)客戶端存儲token，每次請求時帶上token
3) 服務端收到token通過驗證后即可確認用戶身份。
問題：基於session的認證機制與基於token的認證機制的本質區別？
實現機制上：
- session的認證方式由Servlet規范定制，服務端要維護session信息，客戶端需要cookie
- token的認證機制不需要服務端存儲token，並且不限制客戶端的存儲方式 ，用戶的身份信息交給專門的服務管理
本質區別：session的認證方法使用上限制比較大
共同之處：都需要服務端分配給客戶端一個唯一標識
實際應用：目前項目都需要前后端分離，因此通常采用token的方式實現用戶認證
1-2 分布式認證的特點
特點1：分布式統一認證：
基本思想：采用獨立的認證服務來處理系統認證授權的請求
1) 前端請求UAA認證服務請求認證，認證通過返回Token
2) 前端攜帶Token訪問各應用。
特點2：開發認證體系（支持第三方）
基本思想：不僅服務於平台自身，以開放API的方式供第三方應用接入
1）第三方應用請求UAA認證服務請求認證，認證通過獲取Token。
2）第三方應用攜帶Token訪問API代理（專門針對第三方應用接入開發的微服務）。
3）API代理訪問平台微服務向第三方應用返回業務數據
1-3 session與token的分布式認證實現
1-3-1 基本session的分布式認證機制
特點：每個應用服務都需要在session中存儲用戶身份信息，通過負載均衡將本地的請求分配到另一個應用服務需要將session信息帶過去，否則會重新認證
核心問題：session信息該如何同步，從而避免不必要的重復認證
session信息同步的常見做法：
1）Session復制：多台應用服務器之間同步session，使session保持一致，對外透明。
2）Session黏貼：當用戶訪問集群中某台服務器后，強制指定后續所有請求均落到此機器上
3）Session集中存儲：將Session存入分布式緩存中，所有服務器應用實例統一從分布式緩存中存取Session(信息的同步交給分布式緩存處理)
session分布式認證的特點：
優點：
- 在服務端對會話進行控制，且安全性較高
缺點：
- 基於cookie，不適合移動端，且無法跨域，橫向擴展需考慮session的容錯性
- 正向代理(跨區域訪問)代理的對象是客戶端，反向代理（ngnix負載均衡）代理的對象是服務端
1-3-2 基於token的分布式認證機制
優點：服務端不用存儲認證數據，易維護擴展性強， 客戶端可以把token 存在任意地方，並且可以實現web和app統一認證機制
為什么基於token的方式服務端不需要存儲認證數據？
缺點：
- token由於自包含信息，因此一般數據量較大 ，占用帶寬？？？？？？？？？？？？？？？？
- token的簽名信息驗證CPU開銷較大
問題：為什么采用基於token的分布式認證方式？
1、適合統一認證的機制，客戶端、一方應用、三方應用都遵循一致的認證機制。
2、token認證方式對第三方應用接入更適合，因為它更開放，使用當前有流行的開放協議Oauth2.0、JWT。
3、一般情況服務端無需存儲會話信息，減輕了服務端的壓力
1-4 基於token分布式認證的方案具體實現
流程：
（1）接入方（需要使用平台資源的統稱為接入方）采取OAuth2.0方式請求統一認證服務(UAA)進行認證。
（2）認證服務(UAA)調用統一賬號服務去查詢該用戶信息及其權限信息。（第三方應用接入不需要該步驟）
（3）認證服務(UAA)驗證登錄用戶及第三方應用合法性。
（4）若接入方身份合法，認證服務生成jwt令牌返回給接入方，其中jwt中包含了權限信息。
（5）接入方攜帶jwt令牌對API網關內的微服務資源進行訪問。
（6）API網關對令牌解析、並驗證接入方的權限是否能夠訪問本次請求的微服務。
（7）如果接入方的權限沒問題，API網關將Token轉發至微服務。
（8）微服務收到請求，明文token中包含登錄用戶的身份和權限信息，后續微服務使用用戶身份及權限信息
UAA：User Account and Authentication(用戶身份與認證)
JWT:Json web token
為了在網絡應用環境間傳遞聲明而執行的一種基於JSON的開放標准（(RFC 7519).該token被設計為緊湊且安全的，特別適用於分布式站點的單點登錄（SSO）場景。JWT的聲明一般被用來在身份提供者和服務提供者間傳遞被認證的用戶身份信息，以便於從資源服務器獲取資源，也可以增加一些額外的其它業務邏輯所必須的聲明信息，該token也可直接被用於認證，也可被加密。
user服務、UAA服務、網關服務這三個組件職責如下
1）統一賬號服務
提供商戶和平台運營人員的登錄賬號、密碼、角色、權限、資源等系統級信息的管理，不包含用戶業務信息。
2）統一認證服務(UAA)
它承載了OAuth2.0接入方認證、登入用戶的認證、授權以及生成令牌的職責，完成實際的用戶認證、授權功能。
3）API網關
作為系統的唯一入口，API網關為接入方提供定制的API集合，它可能還具有其它職責，如身份驗證、監控、負載
均衡、緩存等。API網關方式的核心要點是，所有的接入方和消費端都通過統一的網關接入微服務，在網關層處理
所有的非業務功能
注意：上面3個服務都沒有業務相關的信息，因此可以用於各種分布式系統
2 OAuth2認證
2-1 基本流程
OAuth（開放授權）定義：是一個開放標准，允許用戶授權第三方應用訪問他們存儲在另外的服務提供者上的信息，而不需要將用戶名和密碼提供給第三方應用或分享他們數據的所有內容
2-1-1 采用微信登錄第三方P站的實例：
- P站需要成功從微信獲取用戶的身份信息則認為用戶認證成功
A) 用戶掃描二維碼即資源擁有者發送請求微信服務給P站授權
B) 微信服務會對資源擁有者的身份進行驗證， 驗證通過后，微信會詢問用戶是否給授權P站訪問自己的微信數據(防止CSRF攻擊)
C) 用戶點擊“確認登錄”表示同意授權
D) 微信認證服務器會頒發一個授權碼，並重定向到P站（第三方應用）
E) P站攜帶token請求訪問用戶的微信資源
F) 微信服務校驗token並提供資源
| 用戶 | 第三方應用 | 微信認證與授權服務 | 微信用戶信息 |
|---|
2-1-2 OAauth2.0認證的角色
1、客戶端
本身不存儲資源，需要通過資源擁有者的授權去請求資源服務器的資源，比如：Android客戶端、Web客戶端（瀏覽器端）、微信客戶端等
2、資源擁有者
通常為用戶，也可以是應用程序，即該資源的擁有者。
3、授權服務器（也稱認證服務器）
用於服務提供商對資源擁有的身份進行認證、對訪問資源進行授權，認證成功后會給客戶端發放令牌
（access_token），作為客戶端訪問資源服務器的憑據。本例為微信的認證服務器。
4.存儲資源的服務器，本例子為微信存儲的用戶信息
問題：為什么OAuth的授權碼進行兩次認證（客戶端，資源擁有者）？
1）兩次認證的目的不同，第一次認證是對請求訪問資源的客戶端（攜帶client_id：客戶端標識 client_secret：客戶端秘鑰）進行認證，防止非法分子
第二次認證是對資源擁有者進行認證，即對用戶本身進行認證。
實例：某用戶嘗試用微信登錄非法網站，顯然在OAuth認證中第一次認證就無法通過
2）兩次認證可以在第三方登錄時對CSRF攻擊進行有效防護。
2-2 Oauth的四種模式
authorization: 授權碼
四種模式的區別：客戶端獲取token的執行流程不同，適用於不同的場景
| 模式 | 特點 | 安全性 | 使用場景 | 授權類型（grant_type） |
|---|---|---|---|---|
| 授權碼模式 | access token僅在服務端進行交換 | 高 | 用於Web服務器端應用或第三方的原生App調用資源服務 | Authorization（authorization_code） |
| 密碼模式 | access token會給客戶端 | 第一方的單頁面應用以及第一方的原生App（有密碼） | password | |
| 客戶端模式 | 需要對客戶端完全信任 | 低 | 非常信任的客戶端應用 | client_credentials |
| 簡化模式（授權碼模式簡化） | access token會給客戶端(去除授權碼) | 簡化模式用於第三方單頁面應用 | implicit |
2-2-1 授權碼模式的執行步驟
- step1:資源擁有者打開客戶端，點擊第三方登錄，它將瀏覽器被重定向到授權服務器，重定向時會附加客戶端的身份信息
=======================================================================================================
重定向URL實例：/uaa/oauth/authorize?client_id=p2pweb&response_type=code&scope=app&redirect_uri=http://xx.xx/notify
參數列表如下：
client_id：客戶端接入標識。
response_type：授權碼模式固定為code。
scope：客戶端權限。
redirect_uri：跳轉uri，當授權碼申請成功后會跳轉到此地址，並在后邊帶上code參數（授權碼）
- step2:授權服務器驗證客戶端身份后，請求用戶授權，此時瀏覽器出現向授權服務器授權頁面，之后將用戶同意授權(頁面跳轉出詢問是否允許登錄微信)
- step3:授權服務器將授權碼（AuthorizationCode）****轉經瀏覽器發送給client(通過redirect_uri)。
- step4:客戶端拿着授權碼向授權服務器索要訪問access_token,請求如下 ,授權服務器返回令牌(access_token)
/uaa/oauth/token?client_id=p2pweb&client_secret=gdjbcd&grant_type=authorization_code&code=5PgfcD&redirect_uri=htt
p://xx.xx/notify
參數列表如下
client_id：客戶端准入標識。
client_secret：客戶端秘鑰。
grant_type：授權類型，填寫authorization_code，表示授權碼模式
code：授權碼，就是剛剛獲取的授權碼，注意：授權碼只使用一次就無效了，需要重新申請。
redirect_uri：申請授權碼時的跳轉url，一定和申請授權碼時用的redirect_uri一致。
授權碼模式特點：
這種模式是四種模式中最安全的一種模式。一般用於Web服務器端應用或第三方的原生App調用資源服務的時候。
因為在這種模式中access_token不會經過瀏覽器或移動端的App，而是直接從服務端去交換，這樣就最大限度的減
小了令牌泄漏的風險
2-2-2 密碼模式執行步驟
step1:資源擁有者將用戶名、密碼發送給客戶端
step2:客戶端拿着資源擁有者的用戶名、密碼向授權服務器請求令牌（access_token）
/uaa/oauth/token?client_id=p2pweb&client_secret=fgsdgrf&grant_type=password&username=shangsan&password=123456
上面鏈接只是表明傳遞哪些參數，實際傳輸密碼不可能是明文傳輸的
參數列表如下：
client_id：客戶端准入標識。
client_secret：客戶端秘鑰。
grant_type：授權類型，填寫password表示密碼模式
username：資源擁有者用戶名。
password：資源擁有者密碼。
step3:授權服務器將令牌（access_token）發送給client
密碼模式特點：
安全性：直接將用戶敏感信息泄漏給了client，因此這就說明這種模式只能用於client是我們自己開發的情況下。
應用場景：因此密碼模式一般用於我們自己開發的，第一方原生App或第一方單頁面應用。
2-2-3 客戶端模式的執行步驟
（1）客戶端向授權服務器發送自己的身份信息，並請求令牌（access_token）
（2）確認客戶端身份無誤后，將令牌（access_token）發送給client
/uaa/oauth/token?client_id=p2pweb&client_secret=fdafdag&grant_type=client_credentials
client_id：客戶端准入標識。
client_secret：客戶端秘鑰。
grant_type：授權類型，填寫client_credentials表示客戶端模式
特點：最方便但最不安全的模式。因此這就要求我們對client完全的信任，而client本身也是安全的。
應用場景：這種模式一般用來提供給我們完全信任的服務器端服務。比如，合作方系統對接，拉取一組用戶信息。客戶端模式適應於沒有用戶參與的，完全信任的一方或合作方服務器端程序接入
2-2-4 簡化模式執行步驟
- step1:資源擁有者打開客戶端，客戶端要求資源擁有者給予授權，它將瀏覽器被重定向到授權服務器，重定向時會附加客戶端的身份信息
/uaa/oauth/authorize?client_id=p2pweb&response_type=token&scope=app&redirect_uri=http://xx.xx/notify
參數描述同授權碼模式 ，注意response_type=token，說明是簡化模式。
-
step2:瀏覽器出現向授權服務器授權頁面，之后將用戶同意授權。
-
step3:授權服務器將授權碼將令牌（access_token）以Hash的形式存放在重定向uri的fargment中發送給瀏覽器。
fragment 主要是用來標識 URI 所標識資源里的某個資源，在 URI 的末尾通過 （#）作為 fragment 的開頭，
其中 # 不屬於 fragment 的值。如https://domain/index#L18這個 URI 中 L18 就是 fragment 的值。大家只需要
知道js通過響應瀏覽器地址欄變化的方式能獲取到fragment 就行了
2-3 JWT的概念
JSON Web Token（JWT）定義：一種簡潔的、自包含的協議格式，用於在通信雙方傳遞json對象，傳遞的信息經過數字簽名可以被驗證和信任。JWT可以使用HMAC算法或使用RSA的公鑰/私鑰對來簽名，防止被篡改
組成：
| Header | PayLoad | Signature |
|---|---|---|
| 令牌的類型（即JWT）及使用的哈希算法（如HMAC SHA256或RSA） | json對象，它是存放有效信息的地方 | 簽名，此部分用於防止jwt內容被篡改 |
2-4 UAA的密碼模式測試（spring security+oauth2.0）
認證服務返回的結果：
{
"access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOlsic2hhbmp1LXJlc291cmNlIl0sInBheWxvYWQiOnsiNCI6eyJyZXNvdXJjZXMiOm51bGwsInVzZXJfYXV0aG9yaXRpZXMiOnsicl8wMDEiOlsic2pfbV9jb25zb2xlIiwic2pfbV9hcHBfbGlzdCIsInNqX21fdHJhbnNhY3Rpb25fbGlzdCIsInNqX21fYWNjb3VudF9jaGVjayIsInNqX21fcGF5bWVudCIsInNqX21fYWNjb3VudF9saXN0Iiwic2pfbV9lbnRlcnByaXNlX2F1dGgiLCJzal9tX3N0b3JlX2xpc3QiLCJzal9tX3N0YWZmX2xpc3QiLCJzal9vX21lbWJlcl9saXN0Iiwic2pfb19lbnRyZXByaXNlX2xpc3QiLCJzal9vX2F1ZGl0Iiwic2pfb19zZXJ2aWNlX3R5cGUiLCJzal9vX2FjY291bnRfY2hlY2siLCJzal9vX2FkbWluX2xpc3QiLCJzal9vX3JvbGVfbGlzdCIsInNqX21fYXBwX2NyZWF0ZSIsInNqX21fcGF5bWVudF9zZXQiLCJzal9tX3N0b3JlX2NyZWF0ZSIsInNqX21fc3RvcmVfcXVlcnkiLCJzal9tX3N0YWZmX2NyZWF0ZSIsInNqX21fc3RhZmZfcXVlcnkiLCJzal9vX21lbWJlcl9xdWVyeSIsInNqX29fZW50ZXJwcmlzZV9xdWVyeSIsInNqX29fZW50ZXJwcmlzZV9jcmVhdGUiLCJzal9vX3NlcnZpY2VfY3JlYXRlIiwic2pfb19zZXJ2aWNlX3F1ZXJ5Iiwic2pfb19hZG1pbl9jcmVhdGUiLCJzal9vX2FkbWluX3F1ZXJ5Iiwic2pfb19yb2xlX2NyZWF0ZSIsInNqX29fcm9sZV9xdWVyeSIsInNqX29fcm9sZV9zYXZlIiwic2pfbV9hdXRoX2FwcGx5Iiwic2pfbV9jb25zb2xlX3JlbmV3Iiwic2pfbV9jb25zb2xlX3VwZ3JhZGUiLCJzal9tX2FwcF9zYXZlIiwic2pfbV9hcHBfbW9kaWZ5Iiwic2pfbV9wYXlwYXJhbV9zYXZlIiwic2pfbV9wYXlfc2V0Iiwic2pfbV9wYXlfc2F2ZSIsInNqX21fYzJiX3FyY29kZSIsInNqX21fYjJjX29yZGVyIiwic2pfbV9oNV92aWV3Iiwic2pfbV9idW5kbGVfYnV5Iiwic2pfbV9lbnRlcnByaXNlX2luZm9fc3VibWl0Iiwic2pfbV9lbnRlcnByaXNlX2luZm9fY2FuY2VsIiwic2pfb19lbnRlcnByaXNlX2F1dGhfcGFzcyIsInNqX29fZW50ZXJwcmlzZV9hdXRoX3JlamVjdGlvbiIsInNqX21fc3RvcmVfZWRpdCIsInNqX21fc3RhZmZfZWRpdCIsInNqX29fYWRtaW5fZWRpdCIsInNqX29fcm9sZV9lZGl0Iiwic2pfbV9zdG9yZV9zYXZlIiwic2pfbV9zdG9yZV9kZWwiLCJzal9tX3N0YWZmX3NhdmUiXSwicl8wMDIiOlsic2pfbV90cmFuc2FjdGlvbl9saXN0Iiwic2pfbV9hY2NvdW50X2NoZWNrIl19fX0sInVzZXJfbmFtZSI6InRlc3QiLCJzY29wZSI6WyJyZWFkIl0sIm1vYmlsZSI6IjEzNzczMzI1OTcwIiwiZXhwIjoxNjU5MTU3NjYzLCJjbGllbnRfYXV0aG9yaXRpZXMiOlsiUk9MRV9NRVJDSEFOVCIsIlJPTEVfVVNFUiJdLCJqdGkiOiJmNzNmYzA1ZC1mNTQzLTQ5OTItOTdiMS0yMTE3NDJhN2IwYjYiLCJjbGllbnRfaWQiOiJtZXJjaGFudC1wbGF0Zm9ybSJ9.bnmkfJ6lDx6Q6szNf2M_dNHHL42jW9_K9ITrEGZBy5U",
// 訪問token,密碼模式下客戶端拿到該token向授權服務獲取用戶權限信息
"token_type": "bearer",
"refresh_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOlsic2hhbmp1LXJlc291cmNlIl0sInBheWxvYWQiOnsiNCI6eyJyZXNvdXJjZXMiOm51bGwsInVzZXJfYXV0aG9yaXRpZXMiOnsicl8wMDEiOlsic2pfbV9jb25zb2xlIiwic2pfbV9hcHBfbGlzdCIsInNqX21fdHJhbnNhY3Rpb25fbGlzdCIsInNqX21fYWNjb3VudF9jaGVjayIsInNqX21fcGF5bWVudCIsInNqX21fYWNjb3VudF9saXN0Iiwic2pfbV9lbnRlcnByaXNlX2F1dGgiLCJzal9tX3N0b3JlX2xpc3QiLCJzal9tX3N0YWZmX2xpc3QiLCJzal9vX21lbWJlcl9saXN0Iiwic2pfb19lbnRyZXByaXNlX2xpc3QiLCJzal9vX2F1ZGl0Iiwic2pfb19zZXJ2aWNlX3R5cGUiLCJzal9vX2FjY291bnRfY2hlY2siLCJzal9vX2FkbWluX2xpc3QiLCJzal9vX3JvbGVfbGlzdCIsInNqX21fYXBwX2NyZWF0ZSIsInNqX21fcGF5bWVudF9zZXQiLCJzal9tX3N0b3JlX2NyZWF0ZSIsInNqX21fc3RvcmVfcXVlcnkiLCJzal9tX3N0YWZmX2NyZWF0ZSIsInNqX21fc3RhZmZfcXVlcnkiLCJzal9vX21lbWJlcl9xdWVyeSIsInNqX29fZW50ZXJwcmlzZV9xdWVyeSIsInNqX29fZW50ZXJwcmlzZV9jcmVhdGUiLCJzal9vX3NlcnZpY2VfY3JlYXRlIiwic2pfb19zZXJ2aWNlX3F1ZXJ5Iiwic2pfb19hZG1pbl9jcmVhdGUiLCJzal9vX2FkbWluX3F1ZXJ5Iiwic2pfb19yb2xlX2NyZWF0ZSIsInNqX29fcm9sZV9xdWVyeSIsInNqX29fcm9sZV9zYXZlIiwic2pfbV9hdXRoX2FwcGx5Iiwic2pfbV9jb25zb2xlX3JlbmV3Iiwic2pfbV9jb25zb2xlX3VwZ3JhZGUiLCJzal9tX2FwcF9zYXZlIiwic2pfbV9hcHBfbW9kaWZ5Iiwic2pfbV9wYXlwYXJhbV9zYXZlIiwic2pfbV9wYXlfc2V0Iiwic2pfbV9wYXlfc2F2ZSIsInNqX21fYzJiX3FyY29kZSIsInNqX21fYjJjX29yZGVyIiwic2pfbV9oNV92aWV3Iiwic2pfbV9idW5kbGVfYnV5Iiwic2pfbV9lbnRlcnByaXNlX2luZm9fc3VibWl0Iiwic2pfbV9lbnRlcnByaXNlX2luZm9fY2FuY2VsIiwic2pfb19lbnRlcnByaXNlX2F1dGhfcGFzcyIsInNqX29fZW50ZXJwcmlzZV9hdXRoX3JlamVjdGlvbiIsInNqX21fc3RvcmVfZWRpdCIsInNqX21fc3RhZmZfZWRpdCIsInNqX29fYWRtaW5fZWRpdCIsInNqX29fcm9sZV9lZGl0Iiwic2pfbV9zdG9yZV9zYXZlIiwic2pfbV9zdG9yZV9kZWwiLCJzal9tX3N0YWZmX3NhdmUiXSwicl8wMDIiOlsic2pfbV90cmFuc2FjdGlvbl9saXN0Iiwic2pfbV9hY2NvdW50X2NoZWNrIl19fX0sInVzZXJfbmFtZSI6InRlc3QiLCJzY29wZSI6WyJyZWFkIl0sImF0aSI6ImY3M2ZjMDVkLWY1NDMtNDk5Mi05N2IxLTIxMTc0MmE3YjBiNiIsIm1vYmlsZSI6IjEzNzczMzI1OTcwIiwiZXhwIjoxNjI3ODgwODYzLCJjbGllbnRfYXV0aG9yaXRpZXMiOlsiUk9MRV9NRVJDSEFOVCIsIlJPTEVfVVNFUiJdLCJqdGkiOiJmY2NkMDBkYy1jMzhkLTRjNjEtYmEzZC00YmUwNGVmOTMzNmMiLCJjbGllbnRfaWQiOiJtZXJjaGFudC1wbGF0Zm9ybSJ9.wi2LK281j5CZ2aPkhaZkA1w-n7zODY3nGmp3JU2I_NE", // 刷新的token
"expires_in": 31535999, // token的過期時間
"scope": "read", // token的權限
"jti": "f73fc05d-f543-4992-97b1-211742a7b0b6" // token的唯一標識
}
使用access_token從認證服務器那邊獲取用戶的身份與授權信息
{
"aud": [
"shanju-resource"
],
"payload": { //應用名稱
"4": {
"resources": null,
"user_authorities": { //用戶權限
"r_001": [
"sj_m_console",
"sj_m_app_list",
"sj_m_transaction_list",
"sj_m_account_check",
"sj_m_payment",
"sj_m_account_list",
"sj_m_enterprise_auth",
"sj_m_store_list",
"sj_m_staff_list",
"sj_o_member_list",
"sj_o_entreprise_list",
"sj_o_audit",
"sj_o_service_type",
"sj_o_account_check",
"sj_o_admin_list",
"sj_o_role_list",
"sj_m_app_create",
"sj_m_payment_set",
"sj_m_store_create",
"sj_m_store_query",
"sj_m_staff_create",
"sj_m_staff_query",
"sj_o_member_query",
"sj_o_enterprise_query",
"sj_o_enterprise_create",
"sj_o_service_create",
"sj_o_service_query",
"sj_o_admin_create",
"sj_o_admin_query",
"sj_o_role_create",
"sj_o_role_query",
"sj_o_role_save",
"sj_m_auth_apply",
"sj_m_console_renew",
"sj_m_console_upgrade",
"sj_m_app_save",
"sj_m_app_modify",
"sj_m_payparam_save",
"sj_m_pay_set",
"sj_m_pay_save",
"sj_m_c2b_qrcode",
"sj_m_b2c_order",
"sj_m_h5_view",
"sj_m_bundle_buy",
"sj_m_enterprise_info_submit",
"sj_m_enterprise_info_cancel",
"sj_o_enterprise_auth_pass",
"sj_o_enterprise_auth_rejection",
"sj_m_store_edit",
"sj_m_staff_edit",
"sj_o_admin_edit",
"sj_o_role_edit",
"sj_m_store_save",
"sj_m_store_del",
"sj_m_staff_save"
],
"r_002": [
"sj_m_transaction_list",
"sj_m_account_check"
]
}
}
},
"user_name": "test", // 用戶名稱
"scope": [
"read"
],
"mobile": "13773325970", // 用戶手機號
"exp": 1659157663,
"client_authorities": [ // 客戶端
"ROLE_MERCHANT",
"ROLE_USER"
],
"jti": "f73fc05d-f543-4992-97b1-211742a7b0b6",
"client_id": "merchant-platform"
}
問題：為什么已經設置了access_token還另外設置refresh token?
access_token是有時效性的，我們希望在用戶在線的的時候access_token不會失效。
粗暴策略：用戶的每次請求都去延長token的有效期，這樣對服務端的壓力比較大
好的策略：用戶每次登錄成功后，除了分配access_token,此外另外分配一個refresh token,客戶端定時調用refresh token去延長access token有效期(或者說返回新的的access token)
前后端分離跨域訪問解決策略
1.nginx反向代理，純前端解決跨域問題（前端項目將第三方的接口地址映射成本地的地址，前端只要調用本地的地址，就可以請求到第三方的數據了，比如，nginx提供的反向代理服務就很穩定）
2.webservice調用第三方服務，提供本地前端接口，解決跨域問題。（后台提供統一http調用接口,避免跨域的產生）
3.服務導入jar包依賴，純后端解決跨域問題（java-property-utils-1.9.jar和cors-filter-1.7.jar）。