IAM、OAuth 2.0、OIDC 与 SSO：从概念到架构的系统化理解

目录

1. 一、术语表
2. 1.1 核心术语
3. 1.2 IAM 与访问控制术语
4. 二、What：这些东西到底是什么
5. 2.1 Authentication：你是谁？
6. 2.2 Authorization：你能做什么？
7. 2.3 IAM：身份与访问管理体系
8. 2.4 OAuth 2.0：授权框架
9. 2.5 OIDC：身份认证协议
10. 2.6 SSO：单点登录
11. 无需为每个系统重新输入密码。
12. 2.7 JWT：Token 表示格式
13. 三、Why：为什么需要这些东西
14. 3.1 为什么需要 Authentication？
15. 3.2 为什么 Authentication 和 Authorization 必须分开？
16. 这是 IAM 设计中最基础的边界。
17. 3.3 为什么需要 OAuth 2.0？
18. 3.4 为什么需要 OIDC？
19. 应用只需要信任统一的 Identity Provider。
20. 3.5 为什么需要 SSO？
21. 四、When：什么时候需要使用
22. 4.1 场景一：只有一个应用
23. 这不是“落后”，而是合理的最小复杂度。
24. 4.2 场景二：一个 Web + 自己的 API
25. 通常已经足够。 不要因为存在 REST API 就自动引入 OAuth 2.0。
26. 4.3 场景三：多个独立应用
27. 这是 OIDC + SSO 的典型使用场景。
28. 4.4 场景四：多个 API / 微服务
29. 4.5 场景五：服务到服务调用
30. 因为服务本身不是 End User。
31. 4.6 场景六：企业内部系统
32. 通常非常有价值。
33. 4.7 场景七：企业 SaaS
34. 4.8 场景八：第三方登录
35. 应用信任外部 Identity Provider 提供的身份结果。
36. 4.9 场景九：第三方访问你的 API
37. 五、How：这些东西到底是怎么工作的
38. 5.1 最简单的 Session 登录
39. 这是最简单的 Web Authentication。
40. 5.2 引入 IAM
41. 而业务系统仍然进行最终的业务授权判断。
42. 5.3 OIDC Authorization Code Flow
43. 5.4 ID Token 和 Access Token 的区别
44. ID Token
45. Access Token
46. 5.5 SSO 是怎么实现的？
47. 5.6 SSO 不等于共享 Session
48. 六、核心关系与边界
49. 6.1 一张关系图
50. 6.2 OAuth 2.0 vs OIDC
51. 6.3 OIDC vs SSO
52. 6.4 IAM vs OIDC
53. 6.5 JWT vs OAuth / OIDC
54. 五者根本不在同一个抽象层级。
55. 七、完整企业 IAM 架构
56. 八、选型决策表
57. 九、架构决策树
58. 十、最重要的心智模型
59. 十一、常见误区
60. 11.1 “用了 JWT 就是 OAuth 2.0”
61. JWT 可以被 OAuth 使用，也可以完全脱离 OAuth 使用。
62. 11.2 “OAuth 2.0 就是登录”
63. 11.3 “OIDC 就是 SSO”
64. OIDC 可以用于实现 SSO。
65. 11.4 “SSO 就是所有系统共享一个 Session”
66. 各应用仍然可以维护自己的 Session。
67. 11.5 “微服务都应该使用 OIDC”
68. 更符合职责边界。
69. 11.6 “只要是 API 就必须 OAuth 2.0”
70. 11.7 “IAM 就等于登录系统”
71. 十二、总结
72. 最终的工程判断原则

本文用于建立 IAM（Identity and Access Management）、Authentication、Authorization、OAuth 2.0、OIDC、SSO、Identity Federation 等概念之间的完整关系。 核心目标不是背协议，而是能够根据系统实际需求判断：什么时候需要什么，以及为什么需要。

---

一、术语表#

1.1 核心术语#

1.2 IAM 与访问控制术语#

---

二、What：这些东西到底是什么#

不要一开始就从 OAuth 2.0 或 OIDC 开始。 先从四个基本问题理解整个 IAM 领域：

---

2.1 Authentication：你是谁？#

Authentication（身份认证）解决：

Who are you? 例如：

username = alice
password = ********

系统验证凭证后得出：

Alice 是 Alice

Authentication 可以通过多种方式实现：

• Password
• MFA
• WebAuthn
• Certificate
• OIDC
• SAML 注意：

Authentication 是一个问题域，不是某一个具体协议。

---

2.2 Authorization：你能做什么？#

Authorization（授权）解决：

What are you allowed to do? 例如：

Alice
Role = Operator

Operator 可能拥有：

order.read
order.update

但没有：

order.delete
user.manage

因此：

核心区别：

Authentication 证明身份，Authorization 决定权限。

---

2.3 IAM：身份与访问管理体系#

IAM（Identity and Access Management）不是一个协议，而是一整套系统和能力。

所以：

IAM 是领域和系统，OIDC、OAuth 2.0、SAML 等是解决其中具体问题的协议。

---

2.4 OAuth 2.0：授权框架#

OAuth 2.0 解决：

一个客户端是否被允许访问某个受保护资源？ 典型关系：

例如 Access Token 对应：

scope:
    user.read
    order.read

API 根据 Token 和 Scope 判断是否允许访问。 因此：

OAuth 2.0 的核心是 Authorization，而不是 User Authentication。

---

2.5 OIDC：身份认证协议#

OIDC（OpenID Connect）建立在 OAuth 2.0 之上。 它解决：

这个用户是谁？ OIDC 在 OAuth 2.0 基础上增加了身份层：

可以用一个非常粗略但实用的方式理解：

OAuth 2.0
    ↓
“你可以访问什么资源？”

OIDC
    ↓
“这个用户是谁？”

---

2.6 SSO：单点登录#

SSO（Single Sign-On）不是协议。 它描述的是一种用户体验和身份架构：

用户登录一次后，可以访问多个独立应用，而无需再次输入凭证。 例如：

用户：

登录 IAM
   ↓
OA
ERP
CRM
Monitoring

无需为每个系统重新输入密码。#

2.7 JWT：Token 表示格式#

JWT（JSON Web Token）只是 Token 的一种表示格式。 因此：

JWT ≠ OAuth 2.0
JWT ≠ OIDC
JWT ≠ SSO
JWT ≠ IAM

可以存在：

OAuth 2.0 + JWT Access Token

也可以存在：

OAuth 2.0 + Opaque Access Token

所以：

不要把“使用 JWT”理解成“使用 OAuth 2.0”或者“使用 OIDC”。

---

三、Why：为什么需要这些东西#

---

3.1 为什么需要 Authentication？#

最基本的问题：

系统只有知道主体身份后，才能进一步进行：

• 权限判断
• 数据隔离
• 审计
• 个性化
• 资源归属判断

---

3.2 为什么 Authentication 和 Authorization 必须分开？#

假设：

Alice

已经通过身份认证。 这只能说明：

Alice 是 Alice

并不能说明：

Alice 可以删除订单
Alice 可以创建用户
Alice 可以修改系统配置

因此：

这是 IAM 设计中最基础的边界。#

3.3 为什么需要 OAuth 2.0？#

假设系统需要：

Frontend → API

你自己设计授权协议，很快就需要处理：

Token
Scope
Client
Expiration
Refresh
Authorization
Resource

OAuth 2.0 的价值就是：

把客户端访问受保护资源的授权流程标准化。

---

3.4 为什么需要 OIDC？#

假设有多个独立应用：

如果每个应用都自己维护：

User
Password
MFA
Login
Session

就会形成：

最终得到多套重复的身份系统。 OIDC 允许：

应用只需要信任统一的 Identity Provider。#

3.5 为什么需要 SSO？#

当系统数量增加：

OA
ERP
CRM
HR
Finance
Git
Monitoring

如果没有 SSO：

用户体验和账号管理成本都会迅速恶化。 有 SSO：

统一：

• Login
• MFA
• Identity
• Account Lifecycle

---

四、When：什么时候需要使用#

核心原则：

不要因为 OAuth 2.0、OIDC、SSO 是“现代技术”就强行使用。应该从实际架构问题反推技术。

---

4.1 场景一：只有一个应用#

架构：

通常：

Login
  ↓
Session
  ↓
Cookie

即可。 一般不需要：

OIDC ❌
SSO ❌
OAuth 2.0 ❌

这不是“落后”，而是合理的最小复杂度。#

4.2 场景二：一个 Web + 自己的 API#

例如：

如果 API 只属于这个应用：

Session Cookie

通常已经足够。 不要因为存在 REST API 就自动引入 OAuth 2.0。#

4.3 场景三：多个独立应用#

例如：

如果这些应用需要共享用户身份：

OIDC ✅
SSO  ✅

这是 OIDC + SSO 的典型使用场景。#

4.4 场景四：多个 API / 微服务#

例如：

这里通常关注：

OAuth 2.0 Access Token

而不是让每一个微服务都做一次 OIDC 登录。 微服务通常需要的是：

验证 Access Token
    ↓
检查 Scope / Role
    ↓
Authorization

---

4.5 场景五：服务到服务调用#

例如：

这是：

Machine → Machine

通常不需要：

OIDC ❌

常见方案：

OAuth 2.0 Client Credentials
mTLS
Service Account

因为服务本身不是 End User。#

4.6 场景六：企业内部系统#

例如：

这时候：

IAM
 ↓
OIDC / SAML
 ↓
SSO

通常非常有价值。#

4.7 场景七：企业 SaaS#

你的 SaaS：

企业客户可能已经拥有：

• Microsoft Entra ID
• Okta
• Keycloak
• 企业 AD
• 其他 IdP 他们通常希望：

员工
 ↓
企业 IAM
 ↓
Your SaaS

而不是：

员工
 ↓
Your SaaS
 ↓
再创建一套密码

这就是：

Enterprise SSO / Identity Federation

---

4.8 场景八：第三方登录#

例如：

Login with Google
Login with Microsoft
Login with Apple

现代 Web 应用通常可以通过 OIDC 等标准身份协议实现。 核心思想：

应用信任外部 Identity Provider 提供的身份结果。#

4.9 场景九：第三方访问你的 API#

例如：

核心需求通常是：

OAuth 2.0

如果还需要知道：

Access Token 对应哪个用户？

则可能使用：

OAuth 2.0 + OIDC

---

五、How：这些东西到底是怎么工作的#

---

5.1 最简单的 Session 登录#

单应用：

这是最简单的 Web Authentication。#

5.2 引入 IAM#

架构变成：

IAM 负责：

Authentication
Identity
MFA

应用负责：

Authorization
Business Logic

注意：

IAM 不意味着所有业务权限都必须由 IAM 直接执行。 IAM 可以提供：

Identity
Role
Group
Claims

而业务系统仍然进行最终的业务授权判断。#

5.3 OIDC Authorization Code Flow#

典型 OIDC Web 登录：

核心思想：

User
 ↓
OIDC Provider
 ↓
认证
 ↓
Authorization Code
 ↓
Application
 ↓
ID Token

---

5.4 ID Token 和 Access Token 的区别#

这是 OIDC 学习中最重要的边界之一。

ID Token#

主要给：

Client / Application

回答：

这个用户是谁？

通常包含：

sub
iss
aud
exp
iat

以及其他身份 Claims。

Access Token#

主要给：

Resource Server / API

回答：

这个调用者被授权访问什么？

可能涉及：

scope
audience
expiration
subject

因此：

不要把 ID Token 当成 API Access Token 使用。

---

5.5 SSO 是怎么实现的？#

第一次登录：

之后访问 App B：

关键：

第一次：
User → IAM → Login

第二次：
User → IAM → 已经登录 → 直接返回认证结果

因此用户感知到：

登录一次
   ↓
访问多个应用

---

5.6 SSO 不等于共享 Session#

正确架构通常是：

即：

IAM Session
    ↓
认证中心状态

App A Session
App B Session
App C Session
    ↓
各应用自己的登录状态

共享的是：

Authentication Trust 而不是： 一个全局 Session ID。

---

六、核心关系与边界#

6.1 一张关系图#

---

6.2 OAuth 2.0 vs OIDC#

最重要：

OAuth 2.0
    ↓
Authorization

OIDC
    ↓
Authentication + Identity

---

6.3 OIDC vs SSO#

所以：

SSO
 ├── 可以通过 OIDC 实现
 └── 也可以通过 SAML 等实现

---

6.4 IAM vs OIDC#

所以：

OIDC 是 IAM 对外提供身份能力的重要接口之一，而不是 IAM 本身。

---

6.5 JWT vs OAuth / OIDC#

五者根本不在同一个抽象层级。#

七、完整企业 IAM 架构#

一个比较完整的企业 IAM 可以抽象为：

可以将整个体系拆成四层：

Layer 1: Identity
    User / Group / Service Account

Layer 2: Authentication
    Password / MFA / WebAuthn / OIDC

Layer 3: Authorization
    OAuth 2.0 / RBAC / ABAC / Policy

Layer 4: Federation & SSO
    OIDC / SAML / LDAP / AD / SSO

---

八、选型决策表#

---

九、架构决策树#

以后设计系统时，不要先问：

“我要不要 OIDC？” 而应该按照实际需求判断：

---

十、最重要的心智模型#

如果只记住一张图，建议记住：

再补充：

JWT
    ↓
Token 的一种格式

SAML
    ↓
企业常见的身份联邦 / SSO 协议

Federation
    ↓
不同身份域之间建立信任

RBAC / ABAC
    ↓
认证后的授权决策

---

十一、常见误区#

11.1 “用了 JWT 就是 OAuth 2.0”#

错误。

JWT = Token Format
OAuth = Authorization Framework

JWT 可以被 OAuth 使用，也可以完全脱离 OAuth 使用。#

11.2 “OAuth 2.0 就是登录”#

不准确。 OAuth 2.0 核心是：

Authorization

如果需要标准化用户身份认证：

OIDC

---

11.3 “OIDC 就是 SSO”#

不准确。

OIDC = Protocol
SSO  = Architecture / User Experience

OIDC 可以用于实现 SSO。#

11.4 “SSO 就是所有系统共享一个 Session”#

错误。 通常：

IAM Session
    ↓
Authentication Trust
    ↓
App A Session
App B Session
App C Session

各应用仍然可以维护自己的 Session。#

11.5 “微服务都应该使用 OIDC”#

通常错误。 用户登录：

OIDC

用户访问 API：

OAuth 2.0 Access Token

服务调用服务：

Client Credentials / mTLS

更符合职责边界。#

11.6 “只要是 API 就必须 OAuth 2.0”#

也不正确。 如果：

Browser
 ↓
Your Backend

并且 API 只是这个 Web 应用的一部分：

Session Cookie

完全可以。 OAuth 2.0 的价值主要在于：

跨应用、跨客户端、跨资源边界的标准化授权。

---

11.7 “IAM 就等于登录系统”#

错误。 登录只是 IAM 的一部分。 更完整的是：

---

十二、总结#

整个体系最终可以压缩成下面这张关系图：

最终只需要记住四句话：

IAM 管理身份和访问。 Authentication 解决“你是谁”，Authorization 解决“你能做什么”。 OIDC 主要解决用户身份认证，OAuth 2.0 主要解决资源授权。 SSO 是一次登录、多应用访问的架构目标，可以通过 OIDC、SAML 等协议实现。

---

最终的工程判断原则#

一个应用
    ↓
Session / Cookie

多个独立应用共享身份
    ↓
IAM + OIDC
    ↓
SSO

应用需要访问 API
    ↓
OAuth 2.0

服务调用服务
    ↓
Client Credentials / mTLS

企业已有自己的身份系统
    ↓
OIDC / SAML
    ↓
Identity Federation + Enterprise SSO

因此，不要为了“现代化”而引入 IAM、OAuth 2.0、OIDC 和 SSO。 应该从问题出发：

有没有用户？
    ↓
需要认证吗？
    ↓
是否有多个独立应用？
    ↓
是否需要统一身份？
    ↓
是否需要 SSO？
    ↓
是否需要 API 授权？
    ↓
是否需要企业身份联邦？

这样设计出来的认证体系，才是真正符合架构需求的。