Vai al contenuto principale
Authentication è una funzionalità nuova. Didit attiva il prodotto per la tua applicazione. Finché non viene attivato, ogni route di runtime di quell’applicazione restituisce 404. I pacchetti SDK di Authentication non sono ancora pubblicati, quindi usa il flusso ospitato e il contratto HTTP descritti in queste pagine.
Authentication consente ai tuoi clienti di accedere alla tua applicazione. È separata dall’accesso alla console di Didit o dalla creazione di un account sviluppatore Didit. È inoltre separata dalla verifica dell’identità di una persona. Usa Authentication da sola oppure combinala con Verifica dell’identità e Monitoraggio delle transazioni. Il login non approva una verifica e non autorizza un pagamento. Il tuo backend prende queste decisioni in base al risultato di ciascun prodotto.

​
Come funziona

Ogni applicazione ha la propria origine di accesso e il proprio emittente di token. Le applicazioni di produzione e sandbox sono separate: hanno origini, impostazioni e identità distinte. Il flusso è OAuth 2.0 con codice di autorizzazione e PKCE (solo S256):
  1. La tua app apre {origin}/sign-in con redirect_uri, state, code_challenge e code_challenge_method=S256.
  2. La pagina ospitata autentica o registra la persona con i metodi che hai abilitato, incluso eventuale secondo fattore obbligatorio.
  3. Il browser torna al tuo redirect_uri con code e state.
  4. La tua app scambia il codice in POST {origin}/token/ per ottenere un access token, un ID token e un refresh token.
Consulta token e JWKS per il contratto dei token e metodi di accesso per ciascun metodo.

​
Scegli la tua piattaforma

JavaScript

Accesso ospitato, callback, sessione e logout.

React

Stato lato client e viste applicative protette.

Next.js

Sessioni lato server, route di callback e cookie.

iOS

Browser di sistema e archiviazione sicura dei token.

Android

Autorizzazione tramite browser e callback dell’app.

React Native

Preparazione del wrapper nativo per l’autenticazione.

Flutter

Preparazione del wrapper nativo per l’autenticazione.

​
Prepara la tua applicazione

  1. Chiedi a Didit di attivare Authentication per la tua applicazione. Fai prima i test in un’applicazione sandbox.
  2. Registra i tuoi URL di reindirizzamento esatti (fino a 50) e i allowed_origins del browser (fino a 50) che chiamano l’API di runtime.
  3. Abilita i metodi di accesso che vuoi offrire. Didit ID Wallet è sempre attivo.
  4. Scegli le impostazioni di sessione e password (vedi sotto).
  5. Prova registrazione, accesso, recupero password, MFA, scadenza della sessione e logout prima di andare in produzione.
Una passkey appartiene alla sua origine. Se in seguito attivi un dominio personalizzato, le persone dovranno registrare di nuovo le proprie passkey.

​
URL di reindirizzamento

Didit reindirizza una persona solo verso un indirizzo che hai registrato. Registralo nella console, in Authentication > Security and sessions > Redirect URLs and allowed origins. Il redirect_uri di una richiesta di accesso deve corrispondere a un URL registrato carattere per carattere: schema, host, porta, percorso e query. Una porta diversa, una barra finale o una diversa maiuscola/minuscola indicano un indirizzo diverso. Wildcard, frammenti, credenziali nell’URL e schemi personalizzati vengono rifiutati. Se l’indirizzo non è registrato, Didit non reindirizza mai verso di esso. {origin}/sign-in risponde con 400 e con una pagina che indica cosa registrare e dove, mentre POST {origin}/authorize/ risponde con 400 {"error": "invalid_redirect_uri"}.

​
Sviluppo locale

Esegui i test sulla tua macchina con la tua applicazione sandbox:
  1. Registra il tuo callback con la sua porta, per esempio http://localhost:3000/auth/callback.
  2. Se il codice del browser chiama l’API di runtime, per esempio per scambiare il codice in POST {origin}/token/, aggiungi anche l’origine a Origini consentite: http://localhost:3000, senza percorso e senza barra finale.
  3. Avvia l’accesso sull’origine sandbox, https://<slug>.sandbox.auth.didit.me, con la tua chiave pk_test_....
localhost, 127.0.0.1 e [::1] sono indirizzi distinti, e lo è anche ogni porta. Registra ciascuno di quelli che usi. Le applicazioni di produzione non accettano mai http://. Prima di andare in produzione, registra il callback https:// di produzione sulla tua applicazione di produzione.

​
Impostazioni dell’applicazione

Puoi gestire queste impostazioni nella console oppure con una sessione di console autorizzata che abbia write:authentication.

​
Mantieni la stessa persona tra i prodotti

Ogni identità include un valore vendor_data. È l’external_id che hai fornito quando hai importato la persona, oppure l’ID identità di Didit in caso contrario. Compare nel token di accesso, nel token di identità e in GET session/. Usa lo stesso valore come vendor_data quando crei le sessioni di verifica e invii le transazioni. Gli eventi di autenticazione finiscono così sulla stessa persona nella console, insieme alle sue verifiche e alle sue transazioni. Vedi eventi e webhook. Ricava vendor_data sul tuo backend da un token verificato, mai da un campo del browser non controllato. Usa il prompt di integrazione condiviso per qualsiasi combinazione. Leggi protezione dai bot per i criteri applicati durante l’accesso.
Ultima modifica il 7 novembre 2026