一: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方式儲存使用者資...