verified_claims d’OpenID Connect.
Els mateixos endpoints funcionen per a qualsevol part confiant que utilitzi aquest perfil, inclosos les Actions posteriors a l’inici de sessió d’Auth0.
Endpoints
Tots els endpoints són sota la URL base del pont de verificació d’identitat.
La producció i el sandbox utilitzen els mateixos endpoints.
L’aplicació associada a les teves credencials de client determina l’entorn.
Utilitza credencials de client separades i un flux de treball que pertanyi a l’aplicació corresponent per a cada entorn.
Consulta Sandbox i dades de prova per als resultats de verificació simulats.
El document de descobriment a
{base}/.well-known/openid-configuration els anuncia tots:
L’autenticació del client utilitza
client_secret_basic o client_secret_post.
El flux d’autorització amb codi requereix PKCE amb code_challenge_method=S256.
Els tokens d’ID es signen amb RS256; verifica’ls amb l’endpoint JWKS.
Flux
- La part confiant envia la sol·licitud d’autorització a
POST /par, incloent-hi el desafiament PKCE,state,nonce, el seuredirect_uriregistrat, els scopesopenid profile identity_assurancei els claims que vol verificar. Didit retorna unrequest_urid’un sol ús vàlid durant 60 segons. - La part confiant redirigeix el navegador de l’usuari a
GET /authorize?request_uri=.... Didit crea una sessió de verificació i envia l’usuari al flux de verificació allotjat. - Quan l’usuari acaba, Didit avalua la decisió de verificació, compara la identitat extreta amb els claims enviats i retorna l’usuari al
redirect_uride la part confiant amb uncoded’un sol ús i elstateoriginal. - La part confiant intercanvia el code a
POST /tokenamb el seucode_verifieri rep un token d’ID signat.
Sol·licitud de claims
Envia els claims a comparar dins del paràmetreclaims estàndard d’OpenID Connect de la sol·licitud PAR.
Són compatibles given_name i family_name, i sempre es comparen de manera aproximada.
verified_claims és una matriu, d’acord amb el perfil BYO IDV d’Okta i la resposta del token d’ID següent.
El token d’ID
El token d’ID porta una matriuverified_claims. assurance_level és VERIFIED només quan la sessió de verificació ha estat aprovada i tots els claims sol·licitats coincideixen amb el document verificat.
En cas contrari, és FAILED.
verification_process és l’id de la sessió de Didit, de manera que pots consultar la verificació a la consola o a través de l’API de sessions.
Considera l’usuari verificat només quan
trust_framework és IDV-DELEGATED i assurance_level és VERIFIED.
Qualsevol altra combinació significa que la verificació no s’ha completat amb èxit.Configurar Okta
Demana a Didit que activi la verificació d’identitat per a les teves aplicacions de producció i sandbox, que associï cadascuna amb el seu flux de treball de verificació i que registri la URL de callback exacta per a cada tenant d’Okta. Una aplicació o una clau d’API existents no activen per si soles aquesta integració. A la consola d’administració d’Okta, afegeix un proveïdor personalitzat de verificació d’identitat i omple els valors següents. Okta crea la integració com a proveïdor d’identitat de tipusIDV_STANDARD amb el protocol ID_PROOFING, i després la referencies des d’una regla de la política de gestió de comptes.
Configura la producció i el sandbox com a integracions de verificació d’identitat separades, amb les seves credencials respectives.
Utilitza els endpoints anteriors per a totes dues.
El client secret és obligatori encara que el flux també utilitzi PKCE.
Una clau d’API amb nom creada per separat no pot substituir la clau d’API primària de l’aplicació en aquesta integració.
Passa a Didit la teva URL de callback perquè es pugui registrar al teu client.
Okta la construeix com
{yourOktaOrgUrl}/idp/identity-verification/callback.
Configurar Auth0
Auth0 no té una ranura nativa per a proveïdors de verificació d’identitat, de manera que la verificació s’executa des d’un Action post-login que redirigeix l’usuari al mateix flux. DesaDIDIT_IDV_BASE, DIDIT_CLIENT_ID i DIDIT_CLIENT_SECRET com a secrets de l’Action, i registra https://{yourAuth0Domain}/continue com a redirect URI a Didit.
Auth0 afegeix el seu propi
state a la redirecció cap a /authorize perquè pugui reprendre l’inici de sessió. Didit adopta aquest state i el retorna a /continue, cosa que permet a Auth0 completar la transacció. No has de passar l’state d’Auth0 pel cos de la PAR (no es genera fins a la redirecció).Desa el
code_verifier de PKCE per cada transacció d’inici de sessió (indexat per event.transaction.id), no en un únic camp de app_metadata.
Si un usuari torna a intentar-ho o hi ha un inici de sessió simultani, un camp compartit es sobreescriu i l’intercanvi del token falla amb invalid_grant.Errors
Els errors segueixen les especificacions RFC 6749 i RFC 9126. Una autenticació de client fallida retorna401 amb {"error": "invalid_client"}; un request_uri o un codi d’autorització caducat o reutilitzat retorna 400 amb invalid_request o invalid_grant.
Els codis d’autorització, els valors de request_uri i les sessions de verificació són tots d’un sol ús.