Vai al contenuto principale
Didit espone un server di autorizzazione OpenID Connect progettato appositamente per la verifica dell’identità delegata. Implementa il contratto che si aspetta il framework “bring your own identity verification vendor” (BYO IDV) di Okta: Pushed Authorization Requests (PAR, RFC 9126), il flusso del codice di autorizzazione con PKCE e un ID token che contiene un oggetto OpenID Connect 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

  1. La parte che fa affidamento invia la richiesta di autorizzazione a POST /par, includendo la sfida PKCE, state, nonce, il redirect_uri registrato, gli scope openid profile identity_assurance e i claim da verificare. Didit restituisce un request_uri monouso valido per 60 secondi.
  2. 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.
  3. Al termine, Didit valuta la decisione di verifica, confronta l’identità estratta con i claim inviati e riporta l’utente al redirect_uri della parte che fa affidamento con un code monouso e lo state originale.
  4. La parte che fa affidamento scambia il codice in POST /token con il proprio code_verifier e riceve un ID token firmato.

Richiesta dei claim

Invia i claim da confrontare nel parametro standard claims 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 array verified_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 tipo IDV_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. Memorizza DIDIT_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 restituisce 401 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.
Ultima modifica il 7 novembre 2026