跳转到主要内容
Didit 提供了一个专为委托式身份验证构建的 OpenID Connect 授权服务器。 它实现了 Okta 的”自带身份验证供应商”(BYO IDV)框架所要求的协议规范:推送授权请求(PAR,RFC 9126)、带 PKCE 的授权码流程,以及携带 OpenID Connect verified_claims 对象的 ID token。 只要依赖方遵循该协议规范,同样的 endpoint 即可使用,包括 Auth0 登录后 Action。

Endpoints

所有 endpoint 都位于身份验证桥接基础 URL 之下。 生产环境与沙盒使用相同的 endpoint。 与您的客户端凭证关联的应用决定所属环境。 每个环境请分别使用对应应用的客户端凭证和工作流。 模拟验证结果请参阅沙盒与测试数据。 位于 {base}/.well-known/openid-configuration 的发现文档列出了以下所有 endpoint: 客户端认证使用 client_secret_basic 或 client_secret_post。 授权码流程要求使用 PKCE,且 code_challenge_method=S256。 ID token 使用 RS256 签名;请通过 JWKS endpoint 验证签名。

流程

  1. 依赖方(relying party)将授权请求推送至 POST /par,其中包括 PKCE 挑战值、state、nonce、其已注册的 redirect_uri、作用域 openid profile identity_assurance,以及需要验证的声明。 Didit 返回一个一次性 request_uri,有效期为 60 秒。
  2. 依赖方将用户的浏览器重定向至 GET /authorize?request_uri=...。 Didit 创建验证会话,并将用户引导至托管验证流程。
  3. 用户完成后,Didit 评估验证决策,将提取的身份信息与推送的声明进行比对,并携带一次性 code 和原始 state 将用户重定向回依赖方的 redirect_uri。
  4. 依赖方使用其 code_verifier 在 POST /token 处交换 code,并获得已签名的 ID token。

请求声明

需要比对的声明应放在 PAR 请求的标准 OpenID Connect claims 参数中发送。 支持 given_name 和 family_name,且两者始终进行模糊比对。 verified_claims 为数组,与 Okta 的 BYO IDV 配置文件以及下文的 ID token 响应格式一致。

ID token

ID token 携带一个 verified_claims 数组。只有当验证会话已通过并且所有请求的声明都与已验证证件匹配时,assurance_level 才为 VERIFIED。否则为 FAILED。
verification_process 即 Didit 会话 ID,因此您可以在控制台中或通过会话 API 查询该验证。
只有当 trust_framework 为 IDV-DELEGATED 并且 assurance_level 为 VERIFIED 时,才能将用户视为已验证。其他任何组合均表示验证未成功。

配置 Okta

请联系 Didit 为您的生产环境和沙盒应用启用身份验证,将每个应用与其验证工作流关联,并为每个 Okta 租户注册准确的回调 URL。 仅有现有应用或 API 密钥并不能启用此集成。 在 Okta 管理控制台中,添加自定义身份验证供应商,并填写下表中的值。 Okta 将该集成创建为类型为 IDV_STANDARD、协议为 ID_PROOFING 的身份提供方,随后您可在账户管理策略规则中引用它。 请将生产环境与沙盒分别配置为独立的身份验证集成,并使用各自的凭证。 两者均使用上述 endpoint。 即使流程同时使用 PKCE,仍需提供客户端密钥。 单独创建的命名 API 密钥不能替代该应用的主 API 密钥用于此集成。 请向 Didit 提供您的回调 URL,以便在您的客户端上注册该 URL。 Okta 生成的回调 URL 格式为 {yourOktaOrgUrl}/idp/identity-verification/callback。

配置 Auth0

Auth0 没有内置的身份验证供应商入口,因此验证通过登录后 Action 运行,该 Action 会将用户重定向至同一流程。 将 DIDIT_IDV_BASE、DIDIT_CLIENT_ID 和 DIDIT_CLIENT_SECRET 保存为 Action 密钥,并在 Didit 中将 https://{yourAuth0Domain}/continue 注册为重定向 URI。
Auth0 会在 /authorize 重定向中附加自己的 state,以便恢复登录。Didit 采用该 state 并将其回传至 /continue,正是这一机制使 Auth0 能够完成该事务。您无需将 Auth0 的 state 传入 PAR 请求体(该值要到重定向时才生成)。
请按登录事务保存 PKCE code_verifier(以 event.transaction.id 为键),而不要保存在单一的 app_metadata 字段中。如果用户重试或发起同时进行的登录,单一共享字段会被覆盖,令牌交换会因 invalid_grant 而失败。

错误

错误遵循 RFC 6749 和 RFC 9126。 客户端认证失败时,返回 401 和 {"error": "invalid_client"};request_uri 或授权码过期或被重放时,返回 400,并附带 invalid_request 或 invalid_grant。 授权码、request_uri 值和验证会话均为一次性使用。
最后修改于 2026年11月7日