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