Skip to content

第15篇: OpenID Connect(OIDC)

第15篇：OpenID Connect (OIDC)：在OAuth 2.0之上构建身份认证层

在前面的文章中，我们深入探讨了OAuth 2.0，了解到它是一个强大的授权框架，解决了“客户端应用如何安全地访问用户资源”的问题。然而，OAuth 2.0本身并不直接提供身份认证（Authentication） 功能，也就是说，它无法直接回答“当前登录的用户是谁”这个问题。

在实际应用中，尤其是在需要单点登录（SSO）的场景下，应用不仅需要获取用户的授权去访问资源，更需要确认用户的身份。这就是OpenID Connect (OIDC) 出现的背景。OIDC巧妙地构建在OAuth 2.0之上，为我们提供了一个简单、可互操作的身份认证层。

1. OIDC与OAuth 2.0的关系：授权之上的身份认证

OpenID Connect不是一个全新的协议，它是一个基于OAuth 2.0的身份认证层。可以这样理解：

  • OAuth 2.0： 是授权协议，目标是让第三方应用获得访问用户资源的权限。它回答的是“你（客户端）能替我（用户）做什么？”
  • OpenID Connect： 是身份认证协议，目标是验证用户的身份，并获取用户的基本资料（User Profile）。它回答的是“当前登录的用户是谁？”

OIDC的精髓在于，它利用了OAuth 2.0的授权流程（特别是授权码模式）来安全地分发代表用户身份的令牌。 当一个客户端（通常称为依赖方，Relying Party, RP）需要验证用户身份时，它会向OpenID Provider (OP)（即OAuth 2.0中的授权服务器）发起一个OAuth 2.0授权请求，OP在用户认证和授权后，除了返回OAuth 2.0的访问令牌（Access Token），还会返回一个额外的令牌——ID Token，其中包含了用户的身份信息。

这种关系使得OIDC既继承了OAuth 2.0的灵活性和安全性，又在其上增加了标准的身份认证机制，从而非常适合现代Web和移动应用的单点登录（SSO）场景。

2. ID Token详解：用户的数字身份证

ID Token是OpenID Connect的核心。它是一个JSON Web Token (JWT)，包含了关于用户认证事件和用户身份的关键信息。对于依赖方（RP）来说，ID Token就是用户的数字身份证。

2.1 JWT结构回顾

JWT通常由三部分组成，用点（.）分隔：Header.Payload.Signature。

  • Header（头部）： 声明令牌的类型（JWT）和所使用的签名算法（如HS256、RS256）。
  • Payload（负载/内容）： 包含了一组声明（Claims），即关于实体（通常是用户）和额外数据的陈述。这是ID Token真正包含身份信息的部分。
  • Signature（签名）： 用于验证令牌的完整性，确保令牌在传输过程中没有被篡改。

2.2 ID Token中的核心Claims

ID Token的Payload中包含了一系列标准化的Claims（声明），这些声明提供了用户的身份信息和认证上下文。

  • iss (Issuer)： 必选。ID Token的颁发者，通常是OpenID Provider的URL。RP会验证此值。
  • sub (Subject)： 必选。主题标识符，是OP为此用户分配的唯一标识。在OP的上下文中，此值在所有客户端中对该用户都是唯一的且不可重新分配。
  • aud (Audience)： 必选。ID Token的接收方，即依赖方（RP）的client_id。RP会验证此值，确保令牌是为其自身颁发的。
  • exp (Expiration Time)： 必选。JWT的过期时间戳。RP会检查此值，拒绝过期的令牌。
  • iat (Issued At)： 必选。JWT的签发时间戳。
  • auth_time (Authentication Time)： 可选。用户进行认证的时间。RP可以使用此值来判断用户上次认证的时间是否满足其安全策略。
  • nonce： 可选，但强烈推荐在授权码模式和隐式模式中使用。一个由RP生成，在认证请求中发送到OP，并在ID Token中返回的随机值。用于防止重放攻击和CSRF攻击。RP会验证此值是否与请求时发送的一致。
  • azp (Authorized Party)： 可选，但推荐在某些场景下使用。表示授权令牌的客户端ID，用于RP验证。
  • amr (Authentication Methods References)： 可选。指示用户认证时使用的认证方法列表（如pwd密码、mfa多因素认证、face面部识别等）。
  • acr (Authentication Context Class Reference)： 可选。指示用户认证的上下文级别或强度，例如，LoA2低安全级别，LoA3高安全级别。
  • c_hash (Code Hash) / at_hash (Access Token Hash)： 可选，用于隐式模式和混合模式，用于客户端验证授权码或访问令牌是否与ID Token相关联，防止令牌注入攻击。

2.3 ID Token的验证

依赖方（RP）收到ID Token后，必须对其进行严格验证，才能信任其中的身份信息：

  1. 签名验证： 使用OP提供的公钥（通常通过OP的发现端点获取）验证ID Token的数字签名，确保令牌未被篡改。
  2. iss验证： 确认iss声明与已知的OP URL匹配。
  3. aud验证： 确认aud声明包含自己的client_id。
  4. exp验证： 确认令牌未过期。
  5. iat验证： 确认令牌的签发时间在合理范围内（防范时钟偏差）。
  6. nonce验证： 如果在请求中发送了nonce，则验证ID Token中的nonce是否匹配。
  7. azp验证（如存在）： 验证azp是否与自己的client_id匹配。
  8. c_hash / at_hash验证（如适用）： 验证哈希值，确保授权码或访问令牌与ID Token的关联性。

通过这些验证步骤，RP可以高度信任ID Token中包含的用户身份信息。

3. OIDC的核心端点：交互的桥梁

OpenID Connect定义了一系列标准化的HTTP端点，用于客户端（RP）与OpenID Provider (OP) 之间的交互。这些端点的具体URL通常可以从发现端点（Discovery Endpoint） 获取。

3.1 授权端点（Authorization Endpoint）

  • 作用： 这是用户进行认证和授权的入口点。客户端将用户浏览器重定向到此端点，并传递OAuth 2.0授权请求参数（如response_type、client_id、redirect_uri、scope、state、nonce等）。
  • URL示例： 通常以 /authorize 或 /auth 结尾，例如 https://accounts.google.com/o/oauth2/v2/auth。
  • 返回： 认证成功后，根据response_type，OP会重定向用户浏览器到redirect_uri，并返回授权码、ID Token或访问令牌等。

3.2 令牌端点（Token Endpoint）

  • 作用： 客户端（通常是服务器端应用）使用授权码、刷新令牌或客户端凭证来此端点交换Access Token、ID Token和Refresh Token。
  • URL示例： 通常以 /token 结尾，例如 https://oauth2.googleapis.com/token。
  • 通信： 通常是后端对后端的直接通信，通过HTTPS POST请求。

3.3 用户信息端点（UserInfo Endpoint）

  • 作用： 这是一个受保护的资源API。客户端在获取到Access Token后，可以使用该令牌向此端点发起请求，以获取更丰富的用户基本资料（如姓名、邮箱、头像等），这些信息通常是ID Token中未包含的。
  • URL示例： 通常以 /userinfo 结尾，例如 https://openidconnect.googleapis.com/v1/userinfo。
  • 通信： 客户端携带Access Token通过HTTPS GET/POST请求访问此端点，OP验证Access Token后返回JSON格式的用户信息。

3.4 发现端点（Discovery Endpoint）

  • 作用： 这是一个元数据端点，OP在此端点发布自己的所有配置信息，包括其他核心端点的URL、支持的response_type、scope、grant_type、JWKS（JSON Web Key Set）URI等。
  • URL规范： 按照OpenID Connect Discovery规范，此端点必须位于OP的Issuer URL后拼接 /.well-known/openid-configuration。例如，如果Issuer是 https://accounts.google.com，则发现端点是 https://accounts.google.com/.well-known/openid-configuration。
  • 重要性： 使得客户端（RP）能够自动化发现OP的各项配置，无需手动配置，大大简化了集成过程。

3.5 JWKS 端点 (JSON Web Key Set Endpoint)

  • 作用： 虽然不总是作为独立的核心端点列出，但其重要性不亚于其他。这是一个公共端点，OP在此处发布用于签名其ID Token和JWT（如访问令牌）的公钥。
  • URL示例： 通常在发现文档中通过 jwks_uri 字段指定，例如 https://www.googleapis.com/oauth2/v3/certs。
  • 用途： 依赖方（RP）通过此端点获取OP的公钥，以便验证ID Token的数字签名。

总结

OpenID Connect (OIDC) 是在OAuth 2.0授权框架之上构建的，提供了一个轻量级、可互操作的身份认证层。它通过引入ID Token（一个包含用户身份信息的JWT）和一系列标准化的端点（授权、令牌、用户信息、发现、JWKS），解决了OAuth 2.0在身份认证方面的空白。

OIDC使得第三方应用能够安全、便捷地验证用户身份并获取其基本资料，而无需直接处理用户的敏感凭证。这不仅极大地简化了单点登录（SSO）的实现，也为构建现代、安全的微服务和分布式应用提供了坚实的基础。理解OIDC的这些核心概念和端点，是你在IAM领域深入实践的关键一步。