概述
本文討論分布式架構權限管理的兩種情況，一種是針對統一授權訪問的，一種是跨平台接口訪問的。
雖然分布式架構會做業務的切割，將整體的業務切割為獨立的子業務或者子平台，但是同一平台下往往會有統一的授權和單點登錄，客戶端而言平台是整體的，這種是統一授權訪問的權限管理。但是也會遇到多平台協作的情況，這種情況不用考慮其他平台的架構，只需要為其提供數據接口跟其對接就可以，這種情況就要考慮跨平台接口訪問的權限管理。
一、統一授權訪問
前端采用web服務器，nginx或者haproxy之類的都可以，利用nginx做第一層反向代理，用zuul做第二層反向代理，兩層反向代理對於常見的網絡滲透和爬蟲基本可以輕松應對。在這個前提下，我們處理接口授權和訪問安全等問題，而且需要從客戶端和服務端都進行安全控制。
1、用戶通過用戶名、密碼發起登陸請求，這里可以配合驗證碼、短信驗證、微信驗證等提高安全級別，登陸請求訪問到權限中心的ZUUL。
2、由ZUUL反向代理到權限中心的SERVICE。
3、查詢用戶、角色信息，進行查詢匹配。
4、有查詢結果以后反饋，反饋用戶狀態，用戶、角色、權限信息等。
5、生產TOKEN，TOKEN的算法需要自己編寫，建議加入時間戳等信息進行加密。存放在SESSION或者直接放入REDIS中，一般建議放入SESSION中，因為分布式架構要做SESSION共享，必須有一個SESSION共享池，SESSION共享池一般會用REDIS來做，而SESSION可以利用SESSIONID，確認唯一用戶，比較方便。
6、返回給客戶端用戶、角色、權限信息。
7、瀏覽器客戶端通過得到的用戶、角色、權限信息進行前端功能和菜單的渲染，隱藏非授權的功能，並且可以基於這些信息做前端的校驗，但是這種校驗由於都在客戶端，很容易被人篡改，只能做一些基本防護，但是這是必要的。
8、瀏覽器客戶端發送業務請求到服務端，請求會附帶客戶端菜單或者功能的權限信息，服務端通過ZUUL的攔截器攔截業務請求，訪問SESSION共享池。
9、然后通過SESSIONID得到TOKEN信息，通過我們的TOKEN算法進行解密，得到用戶、角色、權限信息。
10、進行匹配校驗，查看本次請求是否有接口訪問權限，校驗通過就可以訪問接口，校驗不通過就不能訪問。
二、跨平台接口訪問
這里的接口是指一下跨平台的接口服務，類似webservice這樣，沒有單點登錄，沒有統一的授權，往往是其他平台跟我們平台進行遠程交互的，這些往往兩個平台不是統一的公司或部門，所以接口不是長期使用的，有一定的時間限制。
1、用戶管理員配置外部客戶端用戶及其權限信息。
2、添加用戶信息、權限信息到用戶數據庫之中。
3、外部客戶端接口如果沒有TOKEN，需要先發送授權請求到權限中心。
4、權限中心通過驗證是否配置外部客戶端用戶，並且取得該用戶的權限信息，校驗通過以后通過加密算法生產TOKEN，這里的TOKEN根據實際情況，如果安全要求高最好加入時間戳，讓TOKEN過期作廢，讓對方重新請求。
5、將TOKEN存入REDIS中，形成TOKEN共享池，這里由於沒有瀏覽器的SESSIONID，所以存放在SESSION中意義不大。
6、返回TOKEN給客戶端。
7、客戶端拿到TOKEN以后發送業務請求給業務接口地址。
8、業務接口通過ZUUL攔截請求，並且將TOKEN跟REDIS的TOKEN進行比對。
9、比對成功以后，對TOKEN進行解密，然后看是否有接口授權。
10、如果有接口授權則通過，訪問接口，如果沒有則不能訪問。
作者github地址：https://github.com/cyc3552637
原文地址：https://blog.csdn.net/cyc3552637/article/details/82842300