一：jwt
1.jwt : json web token，是一款輕量級的用於通訊雙方資訊傳遞的載體。
官方給出的定義是：基於json、在網路間進行通訊的令牌。
2.主要有頭部，載荷和簽名三部分組成。
其中：頭部：存放的是加密演算法和令牌形式;
載荷：存放的主要是通訊的內容，且不能存放敏感的資訊（主要是使用者的賬號和角色碼）;
簽名：存放頭部和載荷以及金鑰;
3.加密的演算法主要有兩種：
①hmsa的對稱式加密，具體的就是hs256對稱式加密。
hs256加密演算法，具體是先對頭部和載荷利用base64加密（此加密方式是可以解密的，所以也就是為什麼載荷中不能放重要資訊，容易被解密）然後用金鑰對簽名進行解密，並拿著解密後的資訊同解密的頭和載荷進行資訊的校驗。能有效的防止其他使用者篡改使用者資訊進行未讀偽登入。（金鑰是儲存在伺服器端的）
②rsa非對稱式加密，即有公鑰和私鑰的形式。具體是通過私鑰對頭和載荷進行加密，然後用公鑰作為簽名來解密。這樣一來，加密和解密用的就不是同一金鑰，更能保證通訊資料的安全性。
4.之所以用jwt作為儲存通訊載體的原因有如下優勢：
採用json形式容易解析；
可以自定義內容；
有效防止資料被篡改；
不依賴認證服務就能直接完成授權；
當然也有它自身的缺點：如果內容很多，那麼經加密後資料很長，儲存在瀏覽器端的cookie中就變得不合時宜。
5.jwt 的json格式:
6.微服務鑑權的思路流程
當使用者在瀏覽器端發起請求，經閘道器後有乙個自定義的全域性過濾器，來判斷當前請求（通過lb:）：
①是登入請求
②是請求其他微服務；
如果是①，則放行，將其路由到system_service_user微服務進行登入，登入成功後生成乙個token（即是jwt），返還至瀏覽器，將其儲存在cookie中；當再次請求時，會在請求的header中以key:value的形式進行攜帶，首先會在過濾器中進行過濾是否攜帶了token（也即是jwt），而後對其進行金鑰解密，進行資訊的校驗，和判斷當前的token是否過期，如果校驗通過則路由到請求服務。
如果是②則需要校驗是否攜帶了token進行解析當前請求的去從。
二：oauth2
oauth 是一種認證協議的通用標準，實現跨系統認證。
1.可以實現的功能有：
①.本系統訪問第三方系統資源 即是：第三方認證登入
②.外部系統訪問本系統資源
③.本系統前端訪問本系統後端微服務的資源
④.本系統各個微服務之間相互訪問資源。 即是：單點登入
2.單點登入
有cas單點登入 和 oauth2的單點登入
3.第三方認證登入
oauth2最常用的模式主要是 授權碼模式 和 密碼模式
授權碼模式核心是：
先獲取到授權碼；
基於授權碼獲取到令牌；
基於令牌獲取到受保護的資源資訊；
密碼模式則不需要獲取授權碼，直接是使用使用者和密碼去oauth服務中認證。
ouath2只是乙個協議，具體的解決方案是springsecurity oauth2，springsecutiry 整合了oauth2協議
4.微服務專案完成使用者認證即授權操作
主要基於的技術：spring security + oauth2 + jwt（未完待續）
SSO單點登入之OAuth2 0登入認證
client 呼叫資源伺服器api的應用 oauth 2.0 provider 包括authorization server和resource server 1 authorization server 認證伺服器，進行認證和授權 2 resource server 資源伺服器，保護受保護的資源 u...
SSO單點登入之OAuth2 0登入認證
一 oauth中的角色 client 呼叫資源伺服器api的應用 oauth 2.0 provider 包括authorization server和resource server 1 authorization server 認證伺服器，進行認證和授權 2 resource server 資源伺服...
和jwt 認證方案之初步認識JWT
前言 現在越來越多的專案或多或少會用到jwt，為什麼會出現使用jwt這樣的場景的呢？傳統的方式 cookie session 需要重新登入，使用者體驗不好。session共享 在多台物理機之間傳輸和複製session 方式對網路io的壓力大，延遲太長，使用者體驗也不好。session方式儲存使用者資...