SSO 实现方案对比#

选 SSO 方案就像选数据库——没有银弹，只有适合不适合。创业公司可能只需要 Auth0 的几分钟快速接入；大型金融机构可能需要 Keycloak 的全功能自托管；学术圈可能离不开 Shibboleth 的联邦身份支持。

本文从协议支持、功能特性、部署模式、成本等维度，全面对比主流 SSO 方案。

#一、主流方案概览

#二、协议支持对比

#OIDC 支持

OIDC 是现代应用的首选协议，各方案支持程度：

结论：现代 Web/Mobile 应用首选 OIDC，Keycloak、Auth0、Okta、Azure AD 都是一等公民。

#SAML 支持

SAML 仍是企业 SSO 的主流协议，尤其在传统 Web 应用中：

结论：SAML 2.0 已成为事实标准，所有主流方案都完整支持。

#三、部署模式对比

graph TB
    subgraph SelfHosted["自托管方案"]
        KC[Keycloak]
        CAS[CAS Server]
        SHIB[Shibboleth IdP]
    end

    subgraph Cloud["云服务方案"]
        A0[Auth0]
        OKTA[Okta]
        AZURE[Azure AD]
    end

    subgraph Hybrid["混合方案"]
        KC_CLOUD[Keycloak Cloud]
        OKTA_H[Okta Access Gateway]
    end

    SelfHosted -->|完全控制| KC
    Cloud -->|零运维| A0
    Hybrid -->|按需扩展| KC_CLOUD

#自托管 vs 云服务

#成本分析

#四、功能特性对比

#核心功能

#用户联盟（Identity Brokering）

用户联盟指通过外部 IdP 登录：

#MFA 支持

#五、Keycloak 深度分析

#适用场景

• 需要完全数据主权的企业
• 已有 Kubernetes 基础设施的云原生团队
• 需要深度定制的复杂身份管理需求

#优势

1. 功能完整：开源方案中功能最全
2. 协议覆盖广：OIDC、SAML、CAS 全部支持
3. 活跃社区：Red Hat 背书，社区活跃
4. Quarkus 版本：现代化架构，性能优秀

#劣势

1. 运维复杂度：需要专业的 Keycloak 运维知识
2. 文档质量：官方文档不够完善
3. 版本升级：大版本升级有时需要特殊处理

#六、Auth0 深度分析

#适用场景

• 快速启动的创业公司
• 没有专职运维团队的中小企业
• 需要快速接入多个社交登录的应用

#优势

1. 开发者体验：SDK 完善，文档友好
2. 快速接入：几分钟完成 SSO 集成
3. 托管部署：零运维负担
4. 合规认证：SOC2、ISO27001 等开箱即用

#劣势

1. 成本：随用户量增长成本上升
2. 定制限制：深度定制受限于平台能力
3. 数据主权：用户数据在第三方

#七、选型决策矩阵

flowchart TD
    Start["开始选型"] --> Q1{"团队规模?"}
    Q1 -->|"< 10人"| Small["创业公司"]
    Q1 -->|"10-100人"| Medium["成长型企业"]
    Q1 -->|"100+"| Large["大型企业"]

    Small --> R1["推荐：Auth0"]
    Medium --> Q2{"预算?"}
    Large --> Q3{"合规要求?"}

    Q2 -->|"有限"| R2["推荐：Keycloak 自托管"]
    Q2 -->|"充足"| R3["推荐：Okta / Azure AD"]

    Q3 -->|"高合规"| R4["推荐：Keycloak / Azure AD"]
    Q3 -->|"标准"| Q4{"技术栈?"}

    Q4 -->|"Microsoft 生态"| R5["推荐：Azure AD"]
    Q4 -->|"Java 技术栈"| R6["推荐：Keycloak"]
    Q4 -->|"多技术栈"| R3

#场景化推荐

#八、迁移策略

如果现有 SSO 方案不满足需求，需要迁移：

#从 Auth0/Okta 迁移到 Keycloak

1. 并行运行：新旧 IdP 同时运行
2. 用户数据同步：将用户数据导出并导入 Keycloak
3. 逐步切换应用：按优先级逐个应用切换
4. 验证和监控：监控迁移后的登录成功率

# Auth0 用户导出
auth0 export users --format json > users.json

# Keycloak 用户导入
kcadm.sh create users -r master -s username=xxx ...

#从 CAS 迁移到 Keycloak

1. 分析现有配置：梳理 CAS 所有 Service Registry
2. 创建 Keycloak Client：配置对应的 OIDC/SAML Client
3. 用户数据迁移：LDAP 同步或数据迁移
4. 测试验证：在测试环境完整验证流程

#思考题

问题 1：某中型企业（200人）计划从自建 CAS 迁移到现代化 SSO 方案。现有 15 个应用，其中 8 个是传统 JSP 应用，5 个是 REST API，2 个是 Vue SPA。用户主要使用企业微信作为入口。你会推荐什么方案？迁移路径是什么？

┌─────────────────────────────────────────────┐
│              企业微信                        │
│         （统一身份入口）                     │
└──────────────┬──────────────────────────────┘
               │ OIDC
               ▼
┌─────────────────────────────────────────────┐
│           Keycloak                          │
│  ┌─────────────┐  ┌───────────────────┐   │
│  │ 企业微信 IdP │  │ 本地用户（备选）   │   │
│  └─────────────┘  └───────────────────┘   │
│  ┌─────────────┐  ┌───────────────────┐   │
│  │ SAML Client │  │ OIDC Client       │   │
│  │ (JSP 应用)   │  │ (Vue SPA + API)   │   │
│  └─────────────┘  └───────────────────┘   │
└─────────────────────────────────────────────┘

问题 2：在评估 SSO 方案时，「供应商锁定」（Vendor Lock-in）是一个重要考量因素。如何在享受云服务便利的同时，降低供应商锁定风险？

┌─────────────────────────────────────────────┐
│           应用层（无感知变化）                │
├─────────────────────────────────────────────┤
│         统一认证抽象层                        │
│    ┌─────────┐    ┌─────────┐              │
│    │Auth0    │    │Okta     │              │
│    │Adapter  │    │Adapter  │              │
│    └─────────┘    └─────────┘              │
├─────────────────────────────────────────────┤
│         标准协议层（OIDC/SAML）              │
└─────────────────────────────────────────────┘