當你的公司有很多業務線同時在運營，每條業務線有自己的網域名稱和使用者中心，這個時候就有乙個顯而易見的弊端出現了：一是資料大量冗餘，本是同乙個使用者，卻在多個產品系統中建立和儲存，不利於統一管理；另一方面，使用者也需要註冊多個賬號，不利於從乙個產品引導到使用其他產品。基於以上問題，就需要乙個統一管理的使用者中心。統一使用者中心，首先支援各業務系統有不同的網域名稱，其次需要提供統一的登陸邏輯（業務系統不需要實現登陸邏輯）以及支援各業務系統自行提供登陸邏輯（為了保持業務系統風格統一）。所以，需要分統一登陸邏輯和業務系統自帶登陸邏輯兩種情況分別討論。
先看圖
上圖清楚的描繪了使用者登陸驗證的過程：
1、從瀏覽器任意發起乙個向業務系統的訪問請求。
2、業務系統檢測session中是否儲存有token。
3、如果session中有token，則到使用者中心去驗證token。
4、如果使用者中心驗證token有效，則儲存token到session中，然後訪問正常的業務邏輯，返回業務邏輯頁面。
5、如果使用者中心驗證token無效，則返回瀏覽器乙個跳轉到使用者中心登陸邏輯的指令並帶上使用者訪問的業務url。
6、執行使用者中心的登陸邏輯。
7、登陸成功後建立token，並跳轉到使用者中心儲存到session的業務邏輯url。
8、步驟2如果session中無token，則返回瀏覽器乙個jsonp，通過jsonp到使用者中心去獲取token。
9、獲取token後，帶token訪問業務系統，然後執行步驟3驗證token。
還是看圖說話
從瀏覽器任意發起乙個向業務系統的訪問請求。
業務系統檢測session中是否儲存有token。
如果session中有token，則到使用者中心去驗證token。
如果使用者中心驗證token有效，則儲存token到session中，然後訪問正常的業務邏輯，返回業務邏輯頁面。
如果使用者中心驗證token無效，則將url先暫存在session中，然後跳轉到業務系統自帶的登陸邏輯，返回瀏覽器登陸介面。
執行登陸邏輯。
登陸成功後，則訪問使用者中心去建立token，並拿回乙個token。
從session中取出url，然後返回瀏覽器乙個帶token和url的jsonp，通過jsonp到使用者中心去註冊這個token。
到註冊中心註冊完token後，跳轉訪問url，也就是最開始發起的業務系統的訪問請求。
步驟2如果session中無token，則返回瀏覽器乙個jsonp，通過jsonp到使用者中心去獲取token。
獲取token後，帶token訪問業務系統，然後執行步驟3驗證token。
至於具體的實現的話，主要有以下幾個方面
token的管理
使用者中心實現登陸和退出邏輯
提供給業務系統的3個api：驗證token、建立token、銷毀token
jonsp訪問介面：註冊token、獲取token
最後，附上詳細**，有需要的可以參詳：
多平台統一使用者系統設計
但是很多系統在開發初期沒有做出有足夠擴充套件的設計，在後續業務擴大的時候又急急忙忙，導致多平台統一使用者的目標很難實現，造成很多意想不到的問題。這篇文章裡面我將說明乙個自己的方案。從功能 資料表設計 介面設計三部分展開。能夠在系統構建之初就為未來的需求提供足夠擴充套件的可能。系統中使用者部分最基礎的...
多租戶使用者管理系統中常見的業務場景
在多租戶使用者管理系統中，常見的業務場景有以下幾種 使用者註冊 使用者通過填寫手機號碼等資訊，進行註冊操作 該場景這重驗證使用者手機號碼的有效性，一般通過簡訊驗證碼進行驗證 租戶註冊 使用者通過填寫租戶的相關資訊，註冊租戶，該使用者預設為租戶的超級管理員。該場景注重收集租戶的相關資訊 使用者登入 通...
2023年3月反思 關於統一使用者管理系統的思考
近日，企業定額系統與曹工的成本系統將要進行系統整合。在交流過程中，首先遇到的第乙個技術問題，就是使用者不一致 不能過從曹工的成本系統無縫連線到企業定額系統中。客戶在曹工的成本系統登入後，想要應用我們的企業定額系統還需在使用相同或者不同的使用者名稱重新登入一次，才能使用企業定額，這樣給客戶帶來極為不佳...