第一階段：架構愿景與業務架構設計 (Architecture Vision & Business Architecture)

任何架構的起點都必須是業務目標和需求。

1.1 核心業務目標 (Business Goals)

• 提升用戶體驗：用戶一次登錄，即可無縫訪問集團下所有子公司的官網和應用，無需重復輸入密碼。
• 強化品牌統一性：統一的登錄入口和體驗，強化集團的整體品牌形象。
• 降低運營成本：減少因密碼重置、賬號管理帶來的IT支持成本。
• 賦能業務創新：為未來整合用戶數據、實現精準營銷和個性化服務提供統一的身價認證基石。
• 提升安全性：集中進行安全審計和風險控制，避免各個子系統出現安全短板。

1.2 業務用例與用戶旅程 (Business Use Cases & User Journey)

• 用戶：訪問A公司官網，點擊登錄，跳轉到統一登錄中心，登錄后自動返回A官網且已登錄狀態。再訪問B公司官網，直接已是登錄狀態。
• 管理員：在統一后臺管理所有用戶賬號、權限、審計日志。
• 開發人員：新應用只需簡單集成SDK，即可快速獲得登錄能力，無需自行開發認證模塊。

1.3 業務能力映射 (Business Capability Mapping)

識別出需要構建或增強的核心業務能力：

• 身份認證能力
• 集中授權能力
• 用戶生命周期管理能力
• 安全審計與風險控制能力

---

第二階段：數據架構設計 (Data Architecture)

數據是身份系統的核心資產。

2.1 核心數據實體 (Core Data Entities)

• User (用戶)：核心身份信息（UserID, 用戶名, 手機號/郵箱, 密碼哈希, 狀態）。
• Application (應用)：注冊到SSO系統的客戶端應用信息（AppID, AppSecret, 回調地址, 權限范圍）。
• Session (會話)：用戶的登錄會話狀態（SessionID, UserID, 登錄時間、過期時間、設備信息）。
• Token (令牌)：頒發的認證令牌（Access Token, Refresh Token, 關聯UserID, scope, 過期時間）。
• Audit Log (審計日志)：所有關鍵操作的日志（時間、用戶、操作、結果、IP地址）。

2.2 數據流設計 (Data Flow)

1. 用戶憑據 -> 認證中心 -> (驗證) -> 寫Session、生成Token。
2. 客戶端應用 -> 攜帶Token -> 認證中心 -> (驗證Token) -> 返回User信息。
3. 任何操作 -> 寫Audit Log。

---

第三階段：應用架構設計 (Application Architecture)

這里我們采用基于標準協議（OAuth 2.0 / OpenID Connect）的中心化認證服務模式。

3.1 系統組件劃分 (Component Diagram)

我們將系統分解為以下幾個核心微服務，其交互關系如下圖所示，它清晰地展示了用戶登錄、令牌驗證及資源訪問的完整流程：

• 統一認證中心 (Identity Provider - IdP)

  • 認證端點 (Auth Endpoint)：處理登錄請求，渲染登錄頁面。
  • 令牌端點 (Token Endpoint)：交換授權碼、頒發令牌（Access Token / Refresh Token）。
  • 用戶信息端點 (UserInfo Endpoint)：根據Access Token返回用戶身份信息。
  • JWK 端點：提供公鑰，用于驗證JWT簽名。
  • 管理端點：提供應用注冊、用戶管理等API（內部使用）。

• 客戶端應用 (Service Provider - SP)

  • 即各個集團官網和需要接入的內部系統。
  • 集成輕量級SDK（例如：OIDC Client），負責：
    • 攔截未認證請求。
    • 重定向到IdP。
    • 處理回調，換取Token。
    • 驗證Token并建立本地會話。

• 后臺管理系統

  • 為用戶、應用、權限提供圖形化管理界面。

3.2 協議選型 (Protocol Selection)

• OAuth 2.0：作為授權框架，提供獲取令牌的標準流程。
• OpenID Connect (OIDC)：在OAuth 2.0之上構建的身份層，提供標準的身份認證功能（ID Token）和用戶信息接口。這是我們實現SSO的核心協議。
• JWT (JSON Web Token)：作為令牌格式，具備自包含、可驗證、防篡改的特性。

---

第四階段：技術架構設計 (Technology Architecture)

4.1 技術棧選型 (Technology Stack)

這是一個基于現代云原生和微服務理念的參考技術棧：

組件	推薦技術選型	說明
IdP 后端	Spring Authorization Server	強烈推薦。Spring生態官方項目，對OAuth 2.1和OIDC支持完善，高度可定制，符合Java技術棧現狀。
IdP 前端	React / Vue.js + Ant Design	構建現代化、響應式的登錄和管理界面。
API 網關	Spring Cloud Gateway / Nginx	路由、限流、安全防護的統一入口。
數據庫	MySQL / PostgreSQL	存儲用戶、應用等核心數據，滿足ACID。
緩存	Redis	必選項。存儲用戶會話(Session)、令牌黑名單，極致性能。
日志與監控	ELK Stack (Elasticsearch, Logstash, Kibana) / Prometheus + Grafana	集中日志收集、性能監控和告警。

4.2 部署與高可用架構 (Deployment & High Availability)

• 部署模式：采用微服務架構，每個核心組件（IdP、網關、緩存、DB）均可獨立部署、擴展。
• 高可用 (HA)：
  • 所有服務無狀態化設計，方便水平擴展。
  • IdP、網關等服務部署多個實例，通過負載均衡器（如Nginx、F5） 對外提供服務。
  • Redis 配置為哨兵（Sentinel）模式或集群模式。
  • 數據庫 配置主從復制，實現讀寫分離和故障切換。
• 安全性：
  • 全鏈路HTTPS。
  • 使用公私鑰對對JWT進行簽名（RS256），防止篡改。
  • 數據庫密碼、AppSecret等敏感信息使用Vault或Kubernetes Secrets管理，嚴禁硬編碼。

---

第五階段：實施與演進路線圖 (Implementation & Evolution Roadmap)

5.1 演進路線圖 (Phased Approach)

• Phase 1 (MVP - 3個月)：

  • 實現基于OIDC授權碼模式的核心登錄流程。
  • 接入1-2個最重要的集團官網作為試點。
  • 實現基本的用戶管理（增刪改查）。
  • 技術棧固化：Spring Authorization Server + Redis + MySQL。

• Phase 2 (增強 - 后續3個月)：

  • 開發完整的后臺管理系統。
  • 接入所有剩余官網和內部系統。
  • 增加多因素認證（MFA） 功能（如短信/郵箱驗證碼）。
  • 實現完整的審計日志功能。

• Phase 3 (未來)：

  • 對接企業微信、AD/LDAP等第三方身份源。
  • 實現風險行為檢測（異常登錄報警）。
  • 探索無密碼認證（Passwordless）。

5.2 治理與保障 (Governance)

• 成立架構評審委員會（ARB）：所有接入SSO的應用必須通過安全性和協議合規性評審。
• 制定接入規范：提供詳細的SDK集成文檔和API文檔，降低接入成本。
• 建立監控大盤：實時監控登錄QPS、成功率、延遲等核心指標。

---

總結：架構決策的核心要點

1. 標準優于自定義：堅決采用OIDC等工業標準，避免閉門造車，保證系統的開放性、安全性和可維護性。
2. 中心化治理：認證和授權邏輯必須集中在IdP，客戶端應用必須“輕量化”，杜絕各自實現安全邏輯。
3. 安全第一：從協議、傳輸、存儲、運維等多個層面構建縱深防御體系。
4. 非功能需求驅動：高可用、高性能、可擴展性不是事后才考慮的，而是架構設計的初始輸入。
5. 演進式設計：通過清晰的路線圖分步實施，快速交付價值，并在過程中不斷迭代優化。