OpenID Connect

本文约需 2 分钟阅读

OpenID Connect (OIDC) 是一种在 OAuth 2.0 授权框架之上添加了认证层的协议。它由 OpenID Foundation 于 2014 年制定，作为「使用 Google 登录」「使用 Apple 登录」等社交登录的技术基础而广泛普及。OAuth 2.0 处理的是「能访问什么 (授权)」，而 OIDC 最大的特点是将「你是谁 (认证)」标准化。

OAuth 2.0 (授权) 与 OIDC (认证) 的区别

OAuth 2.0 与 OIDC 容易混淆，但它们要解决的问题根本不同。OAuth 2.0 是一种授权机制，例如「允许此应用访问照片文件夹」，它本身并不具备证明用户身份的功能。OIDC 通过在 OAuth 2.0 的流程中添加名为 ID 令牌的认证信息，弥补了这一缺失。

比较项	OAuth 2.0	OIDC
目的	授权 (授予对资源的访问权限)	认证 (核实用户身份)
签发的令牌	访问令牌	ID 令牌 + 访问令牌
用户信息	未标准化	通过 UserInfo 端点标准化
类比	酒店房卡 (可以进入房间)	护照 (证明你的身份)

在关于 OAuth 权限风险的文章中，详细解说了混淆授权与认证时会产生的安全问题。

ID 令牌 (JWT) 的作用

OIDC 的核心是 ID 令牌。它以 JWT (JSON Web Token) 格式签发，包含用户标识符 (subject)、签发者、有效期、认证时间等声明 (claim)。SP (依赖方) 通过验证 ID 令牌的签名，确认令牌未被篡改且确实由可信的 IdP 签发。

ID 令牌的 Payload 示例:
{
  "iss": "https://accounts.google.com",
  "sub": "1102847529301",
  "aud": "my-app-client-id",
  "exp": 1714700000,
  "iat": 1714696400,
  "email": "user@example.com",
  "name": "Taro Yamada",
  "nonce": "abc123xyz"
}
iss: 签发者 / sub: 用户标识符 / aud: 目标应用 / exp: 有效期 / nonce: 防止重放攻击

Discovery 端点

OIDC 提供方在一个名为 <code>.well-known/openid-configuration</code> 的标准化 URL 上公开其配置信息。该端点以 JSON 格式记载了授权端点、令牌端点、公钥获取地址 (JWKS URI)、支持的范围 (scope) 等内容。SP 通过自动获取这些信息，无需手动配置即可与 IdP 对接。

OIDC 认证流程 (Authorization Code Flow)

用户点击登录按钮

重定向到 IdP 的授权端点

用户在 IdP 处完成认证

将授权码返回给 SP

SP 用授权码换取 ID 令牌

在 Google、Apple 登录中的应用

「使用 Google 登录」和「使用 Apple 登录」是 OIDC 的代表性实现示例。用户只需用 Google 或 Apple 账户进行认证，无需为每个服务创建新密码。对于 Apple，还提供了通过「隐藏邮件地址」选项保护隐私的功能。在关于 SNS 账户保护的文章中，解说了使用社交登录时的安全对策。

与 SAML 的比较

SAML 是比 OIDC 更早制定的面向企业的认证协议。两者解决的是同一个问题 (联合认证)，但技术方法有很大差异。

比较项	OIDC	SAML
数据格式	JSON / JWT	XML
主要用途	Web、移动应用	企业 SSO
实现的复杂度	相对简单	复杂 (XML 签名处理)
移动端支持	原生支持	依赖浏览器

常见误解

有人误以为「OIDC 是 OAuth 2.0 的替代品」，但 OIDC 并不是要取代 OAuth 2.0，而是构建在其之上的扩展。OAuth 2.0 的访问令牌仍用于资源访问，而 OIDC 的 ID 令牌仅用于认证。两者是互补关系，许多实现会同时使用 OAuth 2.0 与 OIDC。也请在隐私设置指南中了解使用 OIDC 进行服务对接时的隐私管理。OAuth 与认证的相关书籍 (Amazon)也很有参考价值。

现场使用案例

「我们将自家 SaaS 的认证基础设施从自研实现迁移到了 OIDC。通过支持 Google 和 Microsoft 的 IdP，企业客户的导入门槛大幅降低，从试用到签约的转化率提升到了 1.5 倍。我深切体会到，支持 SSO 已成为 B2B SaaS 的必备要求。」