Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 26132:2024 OpenID Connect Discovery 1.0 — 发现身份提供者
OpenID Connect依赖方如何使用WebFinger和配置元数据发现OpenID提供者
一、发现协议概述
ISO/IEC 26132:2024定义了OpenID Connect Discovery 1.0协议，该协议提供了一种机制，使OpenID Connect依赖方（RP）能够发现终端用户的OpenID提供者（OP），并获取与其交互所需的配置信息，包括OAuth 2.0端点位置。
发现过程解决了一个基本问题：给定一个终端用户标识符，客户端应用程序如何知道应该与哪个身份提供者通信，以及应该使用哪些端点？该标准通过使用WebFinger和众所周知的配置端点的两步过程解决了这个问题。
发现机制支持真正的去中心化身份场景。单个客户端应用程序可以支持来自任何OpenID提供者的用户，而无需事先为每个提供者进行配置，极大地减少了接入阻力。
二、通过WebFinger发现OpenID提供者
签发者发现过程使用WebFinger协议（RFC 7033）确定OpenID提供者的位置：
| 步骤 | 操作 | 说明 |
|---|---|---|
| 1 | 用户输入 | 终端用户向RP提供标识符（邮箱、URL或其他格式） |
| 2 | 标准化 | RP标准化标识符以确定资源和主机 |
| 3 | WebFinger请求 | RP向主机的WebFinger端点发送带有resource参数的HTTP GET请求 |
| 4 | 响应解析 | RP从链接关系http://openid.net/specs/connect/1.0/issuer的href值中提取签发者位置 |
标识符标准化支持多种格式：
- 电子邮件地址格式：
user@example.com— 标准化为acct:user@example.com - URL格式：
https://example.com/user— 直接用作资源 - 主机名和端口：
example.com:8080— 同时用作资源和主机 - 账户URI：
acct:user@example.com— 显式账户格式
所有WebFinger通信必须使用TLS。此外，WebFinger端点应支持CORS（跨源资源共享），以支持基于浏览器的JavaScript客户端直接执行发现。
三、OpenID提供者配置信息
一旦发现签发者URL，RP从已知位置检索配置元数据。OP在https://{issuer}/.well-known/openid-configuration发布包含以下内容的JSON文档：
| 元数据字段 | 类型 | 说明 |
|---|---|---|
issuer |
字符串 | OP的签发者标识符URL（必须与发现URL匹配） |
authorization_endpoint |
字符串 | OAuth 2.0授权端点URL |
token_endpoint |
字符串 | OAuth 2.0令牌端点URL |
userinfo_endpoint |
字符串 | OpenID Connect UserInfo端点URL |
jwks_uri |
字符串 | OP的JSON Web密钥集文档URL |
scopes_supported |
数组 | 支持的范围值的JSON数组 |
response_types_supported |
数组 | 支持的响应类型值的JSON数组 |
subject_types_supported |
数组 | 主题标识符类型数组（public或pairwise） |
id_token_signing_alg_values_supported |
数组 | ID Token支持的JWS签名算法数组 |
实施RP时，使用适当的TTL缓存提供者配置响应。配置很少更改，缓存消除了每次身份验证请求的往返时间。使用配置响应中的
cache-control标头确定刷新间隔。四、发现实施的工程考量
实施或使用OpenID Connect Discovery时的关键工程考量：
- 提供者元数据验证：始终验证配置响应中的
issuer值是否与用于获取它的签发者URL完全匹配。这可以防止恶意提供者伪造身份的网络钓鱼攻击。 - CORS支持：WebFinger端点应支持CORS以启用基于浏览器的发现。没有CORS，JavaScript客户端无法直接执行发现，必须依赖后端服务。
- 无状态操作：从RP的角度来看，发现是完全无状态的——无需事先与特定提供者注册或配置即可发现它们。
冒充攻击是发现流程中的主要威胁。能够控制WebFinger响应的攻击者可以将RP重定向到恶意OpenID提供者。所有发现通信必须使用TLS，RP必须验证签发者身份。
常见问题
问：所有OpenID Connect实现都必须支持发现吗？
答：不是。发现是可选的。如果RP已经通过带外机制（如配置文件）知道OP的签发者位置，它可以跳过WebFinger步骤，直接进入提供者配置检索。
问：发现如何与基于电子邮件的标识符配合使用？
答：当用户输入电子邮件地址时，RP将其标准化为acct: URI方案（例如acct:user@example.com），在域名部分执行WebFinger查找，并从响应中接收OpenID提供者签发者URL。这使得任何电子邮件域都可以充当身份提供者。
问：如果WebFinger端点不可用怎么办？
答：RP应将发现失败视为身份验证错误，并向用户显示适当的消息。实现还应考虑备用机制，例如尝试其他标识符格式或允许手动输入提供者URL。
