OpenID Connect (OIDC) 构建于 OAuth 2.0 (IETF RFC 6749 和 6750 标准）之上。[1]
对于应用程序、网站开发者而言，他们可以使用 OpenID Connect 创建登录流 (sign-in flows) ，并在基于Web、移动及JavaScript客户端上接收关于用户的可验证断言。该规范套件具备可扩展性，支持一系列可选特性，如身份数据加密、OpenID提供者发现以及会话注销功能 ( identity data, discovery of OpenID Providers, and session logout) 。[1]
对于开发者而言，它为“当前连接浏览器或移动应用的用户身份是谁”这一问题提供了安全且可验证的答案。最重要的是，它免除了设置、存储和管理密码的责任，而这些往往与基于凭证的数据泄露事件密切相关。[1]
OpenID Connect协议的设计旨在开放，以鼓励形成一个开放的身份提供商（IDP）生态系统。尽管目前领先的IDP主要是大型云服务提供商，如谷歌和微软，但OpenID Connect能够支持多种类型的开放提供商（OP），服务于网站、应用程序、客户端及设备。[2]
和 OAuth 2.0/2.1 的关联[编辑 | 编辑源代码]
- OIDC 不是一个独立的协议，它是一个身份层 (Identity Layer)，其核心建立在 OAuth 2.0 的授权框架之上。
- OAuth 2.0/2.1 提供了授权 (Authorization) 的基础机制（授权码、令牌、端点等），但它本身不定义如何认证用户身份 (Authentication) 或如何标准化地传递用户身份信息。
- OIDC 扩展了 OAuth 2.0，主要添加了：
id_token： 一个签名的 JWT 令牌，明确包含用户的身份信息（如唯一标识sub）、认证时间 (auth_time)、认证方式 (acr) 等。这是 OIDC 的核心，直接解决了“用户是谁”的问题。/userinfoEndpoint： 一个标准化的端点，客户端可以使用有效的访问令牌来获取更多关于用户的声明信息（如姓名、邮箱、头像等）。- 标准化发现 (
/.well-known/openid-configuration) 和 JWK (/jwks) 端点： 方便客户端动态获取服务器的配置信息和用于验证令牌签名的公钥。 - 会话管理规范： 定义了如何管理用户的登录状态（如基于 iframe 的会话检查）。
- 因此，OIDC = OAuth 2.x +
id_token+userinfo端点 + 标准化发现/JWK + 会话管理规范。
关键区别[编辑 | 编辑源代码]
- 纯 OAuth 2.0/2.1：
Access Token代表授权 (Authorization) (能做什么)。不一定知道用户具体是谁。 - OIDC (基于 OAuth 2.x):
Access Token(可能)代表授权访问用户信息，ID Token代表认证 (Authentication) (用户是谁)。两者结合提供了完整的身份认证和授权解决方案。
OIDC 下的 Authorization Server 和 Identity Provider[编辑 | 编辑源代码]
- 为了实现用户身份认证 (
id_token) 和提供用户信息 (/userinfo)，OIDC 要求 其依赖的 Authorization Server (AS，通常称为 OpenID Provider - OP) 必须 具备 Identity Provider (IdP) 的功能，或者与一个 IdP 深度集成。 - 在 OIDC 中，OpenID Provider (OP) 是一个同时扮演了 Authorization Server (AS) 和 Identity Provider (IdP) 角色的实体。它：
- 像 OAuth AS 一样处理授权请求、颁发访问令牌。
- 像 IdP 一样认证用户身份。
- 颁发包含用户身份信息的
id_token。 - 提供
/userinfo端点。
- 因此，在 OIDC 中，术语 Authorization Server (AS) 和 Identity Provider (IdP) 通常指的是同一个 OP 实例内部的不同功能模块，或者是一个高度集成的系统。当我说 AS 和 IdP 协同工作时，本质是在描述 OP 内部处理 OIDC 流程时，授权功能和身份认证功能如何协作。