verified_claims.
Gli stessi endpoint funzionano per qualsiasi parte che fa affidamento e che adotta questo profilo, inclusi gli Actions post-login di Auth0.
Endpoint
Tutti gli endpoint si trovano sotto l’URL di base del ponte di verifica dell’identità.
Produzione e sandbox usano gli stessi endpoint.
L’applicazione associata alle tue credenziali client determina l’ambiente.
Usa credenziali client separate e un workflow appartenente all’applicazione corrispondente per ciascun ambiente.
Consulta Sandbox e dati di test per gli esiti di verifica simulati.
Il documento di discovery in
{base}/.well-known/openid-configuration li elenca tutti:
L’autenticazione del client usa
client_secret_basic o client_secret_post.
Il flusso del codice di autorizzazione richiede PKCE con code_challenge_method=S256.
Gli ID token sono firmati con RS256; verificali tramite l’endpoint JWKS.
Flusso
- La parte che fa affidamento invia la richiesta di autorizzazione a
POST /par, includendo la sfida PKCE,state,nonce, ilredirect_uriregistrato, gli scopeopenid profile identity_assurancee i claim da verificare. Didit restituisce unrequest_urimonouso valido per 60 secondi. - La parte che fa affidamento reindirizza il browser dell’utente a
GET /authorize?request_uri=.... Didit crea una sessione di verifica e porta l’utente nel flusso di verifica ospitato. - Al termine, Didit valuta la decisione di verifica, confronta l’identità estratta con i claim inviati e riporta l’utente al
redirect_uridella parte che fa affidamento con uncodemonouso e lostateoriginale. - La parte che fa affidamento scambia il codice in
POST /tokencon il propriocode_verifiere riceve un ID token firmato.
Richiesta dei claim
Invia i claim da confrontare nel parametro standardclaims di OpenID Connect della richiesta PAR.
Sono supportati sia given_name sia family_name, e vengono sempre confrontati mediante una corrispondenza approssimativa.
verified_claims è un array, in linea con il profilo BYO IDV di Okta e con la risposta dell’ID token riportata di seguito.
L’ID token
L’ID token contiene un arrayverified_claims. assurance_level è VERIFIED solo quando la sessione di verifica è stata approvata e ogni claim richiesto corrisponde al documento verificato.
Altrimenti è FAILED.
verification_process è l’ID della sessione Didit, così puoi consultare la verifica nella console o tramite l’API delle sessioni.
Considera l’utente verificato solo quando
trust_framework è IDV-DELEGATED e assurance_level è VERIFIED.
Qualsiasi altra combinazione significa che la verifica non è riuscita.Configurare Okta
Chiedi a Didit di abilitare la verifica dell’identità per le tue applicazioni di produzione e sandbox, di associare ciascuna al proprio workflow di verifica e di registrare l’URL di callback esatto per ogni tenant Okta. Un’applicazione o una chiave API esistente da sola non abilita questa integrazione. Nell’Okta Admin Console, aggiungi un fornitore personalizzato di verifica dell’identità e compila i valori seguenti. Okta crea l’integrazione come identity provider di tipoIDV_STANDARD con protocollo ID_PROOFING, quindi la referenzi da una regola di Account Management Policy.
Configura produzione e sandbox come integrazioni di verifica dell’identità separate, con le rispettive credenziali.
Usa gli endpoint sopra per entrambe.
Il client secret è obbligatorio anche se il flusso usa PKCE.
Una chiave API denominata creata separatamente non può sostituire la chiave API primaria dell’applicazione per questa integrazione.
Fornisci a Didit il tuo URL di callback in modo che venga registrato sul tuo client.
Okta lo costruisce come
{yourOktaOrgUrl}/idp/identity-verification/callback.
Configurare Auth0
Auth0 non ha uno slot nativo per un fornitore IDV, quindi la verifica viene eseguita da un Action post-login che reindirizza l’utente allo stesso flusso. MemorizzaDIDIT_IDV_BASE, DIDIT_CLIENT_ID e DIDIT_CLIENT_SECRET come segreti dell’Action, e registra https://{yourAuth0Domain}/continue come redirect URI presso Didit.
Auth0 aggiunge il proprio
state al redirect verso /authorize per poter riprendere il login. Didit adotta quello state e lo restituisce a /continue, ed è ciò che permette ad Auth0 di completare la transazione: non devi inserire lo state di Auth0 nel corpo della PAR, perché viene generato solo al momento del redirect.Memorizza il
code_verifier PKCE per ogni transazione di login (indicizzato con event.transaction.id), non in un unico campo app_metadata.
Se un utente riprova o esegue un login sovrapposto, un unico campo condiviso viene sovrascritto e lo scambio del token fallisce con invalid_grant.Errori
Gli errori seguono la RFC 6749 e la RFC 9126. Un’autenticazione del client non riuscita restituisce401 con {"error": "invalid_client"}; un request_uri o un codice di autorizzazione scaduto o già utilizzato restituisce 400 con invalid_request o invalid_grant.
I codici di autorizzazione, i valori request_uri e le sessioni di verifica sono tutti monouso.