Saltar al contenido principal
Didit expone un servidor de autorización OpenID Connect diseñado específicamente para la verificación de identidad delegada. Implementa el contrato que espera el marco “bring your own identity verification vendor” (BYO IDV) de Okta: Pushed Authorization Requests (PAR, RFC 9126), el flujo de código de autorización con PKCE y un ID token que contiene un objeto 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

  1. La relying party envía la solicitud de autorización a POST /par, con el desafío PKCE, state, nonce, su redirect_uri registrada, los scopes openid profile identity_assurance y los claims que quiere verificar. Didit devuelve un request_uri de un solo uso, válido durante 60 segundos.
  2. 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.
  3. 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_uri de la relying party con un code de un solo uso y el state original.
  4. La relying party intercambia el código en POST /token con su code_verifier y recibe un ID token firmado.

Solicitar claims

Envía los claims que quieres comparar dentro del parámetro estándar claims 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 array verified_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 tipo IDV_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. Guarda DIDIT_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 devuelve 401 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.
Última modificación el 1 de noviembre de 2026