verified_claims de OpenID Connect.
Los mismos endpoints funcionan para cualquier relying party que implemente este perfil, incluidas las Actions post-login de Auth0.
Endpoints
Todos los endpoints se encuentran bajo la URL base del puente de verificación de identidad.
Producción y sandbox usan los mismos endpoints.
La aplicación asociada a tus credenciales de cliente determina el entorno.
Usa credenciales de cliente independientes y un flujo de verificación (workflow) que pertenezca a la aplicación correspondiente en cada entorno.
Consulta Sandbox y datos de prueba para obtener resultados de verificación simulados.
El documento de descubrimiento en
{base}/.well-known/openid-configuration los anuncia todos:
La autenticación del cliente usa
client_secret_basic o client_secret_post.
El flujo de código de autorización requiere PKCE con code_challenge_method=S256.
Los tokens de ID se firman con RS256; verifícalos con el endpoint de JWKS.
Flujo
- La relying party envía la solicitud de autorización a
POST /par, con el desafío PKCE,state,nonce, suredirect_uriregistrada, los scopesopenid profile identity_assurancey los claims que quiere verificar. Didit devuelve unrequest_uride un solo uso, válido durante 60 segundos. - La relying party redirige el navegador del usuario a
GET /authorize?request_uri=.... Didit crea una sesión de verificación y lleva al usuario al flujo de verificación alojado. - Cuando el usuario termina, Didit evalúa la decisión de verificación, compara la identidad extraída con los claims enviados y devuelve al usuario a la
redirect_uride la relying party con uncodede un solo uso y elstateoriginal. - La relying party intercambia el código en
POST /tokencon sucode_verifiery recibe un ID token firmado.
Solicitar claims
Envía los claims que quieres comparar dentro del parámetro estándarclaims de OpenID Connect en la solicitud PAR.
Se admiten tanto given_name como family_name, y ambos se comparan siempre de forma difusa.
verified_claims es un array, conforme al perfil BYO IDV de Okta y a la respuesta del ID token que se muestra a continuación.
El ID token
El ID token contiene un arrayverified_claims. assurance_level es VERIFIED solo cuando la sesión de verificación fue aprobada y todos los claims solicitados coincidieron con el documento verificado.
En caso contrario, es FAILED.
verification_process es el ID de la sesión de Didit, así que puedes consultar la verificación en la consola o mediante la API de sesiones.
Considera al usuario verificado solo cuando
trust_framework sea IDV-DELEGATED y assurance_level sea VERIFIED.
Cualquier otra combinación significa que la verificación no tuvo éxito.Configurar Okta
Pide a Didit que habilite la verificación de identidad para tus aplicaciones de producción y sandbox, que asocie cada una a su flujo de verificación y que registre la URL de callback exacta de cada tenant de Okta. Una aplicación o una clave de API existentes no bastan por sí solas para habilitar esta integración. En la Okta Admin Console, añade un proveedor personalizado de verificación de identidad y completa los valores siguientes. Okta crea la integración como un proveedor de identidad de tipoIDV_STANDARD con el protocolo ID_PROOFING, y después la referencias desde una regla de Account Management Policy.
Configura producción y sandbox como integraciones de verificación de identidad independientes, cada una con sus credenciales.
Usa los endpoints anteriores para ambas.
El client secret es obligatorio aunque el flujo también use PKCE.
Una clave de API con nombre creada por separado no puede sustituir a la clave de API principal de la aplicación en esta integración.
Proporciona a Didit tu URL de callback para que la registre en tu cliente.
Okta la construye como
{yourOktaOrgUrl}/idp/identity-verification/callback.
Configurar Auth0
Auth0 no tiene un espacio nativo para proveedores de IDV, así que la verificación se ejecuta desde una Action post-login que redirige al usuario al mismo flujo. GuardaDIDIT_IDV_BASE, DIDIT_CLIENT_ID y DIDIT_CLIENT_SECRET como secretos de la Action y registra https://{yourAuth0Domain}/continue como URI de redirección en Didit.
Auth0 añade su propio
state a la redirección a /authorize para poder reanudar el inicio de sesión. Didit adopta ese state y lo devuelve a /continue, lo que permite a Auth0 completar la transacción: no tienes que pasar el state de Auth0 en el cuerpo de la PAR (no se genera hasta la redirección).Guarda el
code_verifier de PKCE por cada transacción de inicio de sesión (con event.transaction.id como clave), no en un único campo de app_metadata.
Si un usuario vuelve a intentarlo o realiza inicios de sesión superpuestos, un único campo compartido se sobrescribe y el intercambio del token falla con invalid_grant.Errores
Los errores siguen RFC 6749 y RFC 9126. Si la autenticación del cliente falla, se devuelve401 con {"error": "invalid_client"}; un request_uri o un código de autorización expirado o reutilizado devuelve 400 con invalid_request o invalid_grant.
Los códigos de autorización, los valores request_uri y las sesiones de verificación son todos de un solo uso.