認證和鑑權
SpringCloud認證和鑑權方案
開始我們接觸的時候權限認證 無從下手，但是當接觸之後會發現 權限認證時一件很簡單的事情，但是我們 方案眾多又該如何選擇呢，下面會分別對每種方案進行簡單的闡述，有問題或者不明白的可以私信或者下方留言，一起討論
含義
認證：簡單來說，認證這個用戶是誰。
鑑權：簡單來說，就是了解這個用戶能做什麼事情
本篇章介紹如下幾種方式
1.單體應用下的常用方案
2.微服務下的SSO單點登陸方案
3.分佈式Session與網關結合方案
4.客戶端Token與 網關結合方案
5.瀏覽器Cookie與網關結合方案
6.網關Token和 服務間鑑權結合
（還有狠多，不再一一列舉）
7.簡單案例講解
詳細介紹
1.單體應用下的常用方案
傳統的單體應用，一般會寫一個固定的認證和鑑權的包，裡面包含很多的認證和鑑權的類，當用戶請求時可以利用session的方式，把用戶存入session並生成一個sessionid，之後返回客戶端。客戶端可以存在cookie裡，從而在後續的請求中順利通過驗證。
常用框架：shiro 、自定義註解、Filter攔截等
2. 微服務下的SSO單點登陸方案
單點登錄(Single Sign On),簡稱為 SSO,是目前比較流行的企業業務 整合的解決方案之一。SSO的定義是在多個應用系統中,用戶只需要登錄一次就可以訪問所有相互信任的應用系統，如CAS（Central Authentication Service），是耶魯大學開發的單點登錄系統（SSO，single sign-on），應用廣泛，具有獨立於平臺的，易於理解，支持代理功能。
但是針對微服務(服務之間調用)：每個 服務都進行每個用戶端 的sso動作，那麼每個服務裡都會做用戶的認證和鑑權，可能保存每個用戶的信息或者每個用戶都會和鑑權服務打交道，這些情況都會帶來非常大的網路開銷和性能消耗，也有可能會造成數據的不一致，所以不建議用這種方案。
3.分佈式Session與網關結合方案
1)用戶在網關進行sso登陸 ，進行用戶認證，檢查用戶是否存在和有效
2）如何用戶通過，則將用戶信息存儲在第三方中間件中，如mysql、redis
3)後端可以從共享存儲拿到用戶的數據
很多 場景下，這種方案是推薦的，因為方便擴展，也 可以保證高可用的方案。但是這種方案的缺點是依賴於第三方中間件，且這些部件需要 做高可用，並且增加安全的控制，所有對於實現有一定的複雜度
4.客戶端Token與 網關結合方案
實現步驟
1）客戶端持有一個token，通常可用jwt或者其它加密的算法實現自己的一種Token，然後通過token保存用戶的信息
2）發起用戶請求並攜帶token，token傳到網關層後，網關 層進行認證和校驗。
3）校驗通過，攜帶token到後端服務中
4）如果涉及到用戶的大量信息存放，token就有可能不太合適（或者用中間件來存放）
這種方案也是業界很常用的方案，但是對於 token來說，他的註銷有一定的麻煩，需要在網關層進行Token的註銷
5. 瀏覽器Cookie與網關結合方案
這種方式和上面的方式類似，但不同的是我們把用戶的信息存放在cookie裡，然後通過網關來解析cookie，從而 獲取用戶的相關信息，這種方式在一些老系統做改造時遇到的比較多，適合做為老系統改造時採取的方案，因為很多系統需要繼承，這時cookie在別的系統中也是同樣的適用。
6. 網關Token和 服務間鑑權結合
我們都知道網關適合做認證和鑑權，但是在安全層面，我們要求更嚴格的權限，對於有些項目來說，本身網絡跟外部隔離，再加上其它的安全手段，所以我們只要求在網關上鑑權就可以了。
但是有些時候服務對 服務之間的調用進行鑑權，知道某個用戶是否有權限調用某個接口，這些都需要進行鑑權。
這時的方案如下。
1）在gateway網關層做認證，通過用戶校驗後，傳遞用戶信息到header中，後臺做服務在收到header後進行解析，解析完後查看是否有調用此服務或者某個url的權限，然後完成鑑權
2）從服務內部發出的請求，在出去時進行攔截，把用戶信息保存在header裡，然後傳出去,被調用方取到header後進行解析和鑑權
7.略
文字比較多 ，會在分一篇張闡述
End
閱讀更多 閒的發慌的人們 的文章
