1. 课程导入与全景认知

在企业信息化建设中，身份认证是所有业务系统的第一道门。过去，每个应用各自维护一套账号密码，员工需要记住十几组凭据，管理员要在多个系统里重复开通和注销账号，安全团队则难以回答“谁在什么时候访问了什么”这一基本问题。OpenID Connect（OIDC）正是为解决这类问题而生的协议：它建立在 OAuth 2.0 授权框架之上，用一套标准化、可互操作的流程，把“用户是谁”这一判断从各个业务系统里抽离出来，交给统一的身份平台完成。

理解 OIDC 的定位，需要先厘清它与相邻概念的关系。OAuth 2.0 解决的是“授权”——让第三方应用在用户许可下获得访问某资源的令牌，它本身并不规定如何证明用户身份。OIDC 在 OAuth 2.0 之上增加了一层身份语义：在授权流程中额外返回一个 ID Token，这是一个由身份平台签名的 JWT，里面包含 sub（用户唯一标识）、iss（签发者）、aud（受众）、exp（过期时间）等标准声明。业务系统只要验证这个 ID Token 的签名、签发者和受众，就能确认用户身份，而不必接触用户密码。SAML 2.0 同样能实现单点登录，但它的断言基于 XML 且更偏重浏览器重定向场景；OIDC 使用 JSON 与 JWT，天然适配移动端、SPA 和 API 网关，这也是它在现代企业架构中逐渐成为主流的直接原因。

从企业身份平台的角度看，OIDC 带来的核心价值可以归纳为四点。第一是统一身份源：员工在主身份平台（如 Keycloak、Azure AD、Okta 或企业自建的 IAM）完成一次认证，即可访问所有接入 OIDC 的应用，账号生命周期由 HR 系统驱动，入职开通、离职回收形成闭环。第二是降低应用改造成本：业务系统不再实现密码校验、找回密码、多因素认证等逻辑，只需接入标准客户端库，把认证委托出去。第三是可审计与合规：所有认证事件集中在身份平台记录，登录时间、来源 IP、客户端、认证方式一目了然，满足等保与内控审计要求。第四是支持细粒度授权：ID Token 中的声明和 UserInfo 接口返回的属性可以携带部门、角色、租户等信息，业务系统据此做访问控制，无需再单独维护用户档案。

典型集成场景在企业中大致分为四类。其一是Web 应用单点登录，采用授权码模式（Authorization Code Flow），后端用 client_secret 换取令牌，适合有服务端渲染的传统系统。其二是前后端分离与 SPA，使用授权码 + PKCE 模式，避免在浏览器中暴露客户端密钥。其三是移动端与桌面客户端，同样采用 PKCE，配合系统浏览器完成认证，令牌由应用安全存储。其四是服务间调用与 API 网关，使用客户端凭证模式（Client Credentials）获取访问令牌，网关校验 JWT 后放行请求。这四类场景共享同一套身份平台，但流程细节和令牌使用方式不同，后续章节会逐一展开。

下面这张全景图把身份平台、OIDC 协议层与四类业务应用的关系集中呈现出来，帮助建立整体认知：

要真正把 OIDC 用起来，光知道概念远远不够。企业集成中真正容易出问题的环节，往往集中在几个具体位置：回调地址（Redirect URI）配置不一致导致 redirect_uri_mismatch；时钟偏移或缓存导致 ID Token 验签失败；aud 与 iss 校验缺失造成令牌被错误接受；PKCE 的 code_verifier 与 code_challenge 不匹配导致换令牌被拒；以及登出时只清理了本地会话，没有调用 end_session_endpoint，造成“退出后仍能免登”的假象。这些问题的共同点是：它们都能通过观察具体参数和返回结果定位，而不是靠反复重启服务碰运气。

本课程的学习路线按“认知—协议—集成—运维”四段推进。第一阶段建立全景认知，明确 OIDC 与 OAuth 2.0、SAML 的边界，理解 ID Token 与 Access Token 的分工。第二阶段深入协议细节，掌握 Discovery 文档、授权码流程、PKCE、令牌校验和 UserInfo 接口，能够手工构造一次完整的认证请求并读懂每一步返回。第三阶段进入集成实操，分别完成 Web 应用、SPA、移动端和 API 网关四类接入，处理回调、会话、登出和声明映射。第四阶段面向生产运维，覆盖多租户隔离、密钥轮换、令牌吊销、日志审计与常见故障排查。每一阶段都以可观察的参数和可复现的结果为落点，而不是停留在名词解释。

最后需要建立的一个基本判断是：OIDC 不是“装一个插件就完事”的开关，而是一套需要双方（身份平台与应用）在端点、密钥、声明和会话策略上达成一致的契约。理解这套契约的每个字段和每个端点，是后续所有集成工作的前提。接下来的章节会从协议基础开始，逐步把这套契约拆开讲清楚。