Configura l’accesso ospitato
Registra l’URL di callback esatto e l’origine web per la tua applicazione sandbox. Copia la sua origine di accesso (https://<slug>.sandbox.auth.didit.me) dalla console, come descritto nella panoramica. Questo esempio usa le API crittografiche del browser e richiede HTTPS, oppure localhost in sandbox: consulta sviluppo locale per sapere cosa registrare.
L’applicazione gestisce state e il verifier PKCE. L’accesso ospitato gestisce le schermate di password, email, passkey, telefono, SSO e MFA quando richiesta. In questo codice non va inserita nessuna chiave API.
auth.js
signIn() dal tuo pulsante di accesso. Nella pagina di callback registrata, chiama handleCallback() una sola volta, mostra uno stato di caricamento e visualizza il suo errore se l’operazione fallisce. Usa getSession() per l’utente corrente e signOut() per il logout. Il callback rimuove il proprio codice dalla barra degli indirizzi prima di inviare una richiesta.
Questo esempio minimale conserva i token in memoria e richiede un nuovo accesso dopo il ricaricamento della pagina o la scadenza del token di accesso. Per sessioni persistenti, usa il tuo backend e cookie sicuri, oppure implementa una rotazione dei refresh token serializzata. Non inserire mai i refresh token negli URL o nei log. Il controllo della sessione lato frontend serve solo alla presentazione; il tuo backend deve verificare il chiamante a ogni richiesta protetta.
Anteprima del rilascio dell’SDK di autenticazione
Il futuro nucleo@didit-protocol/auth espone createDiditAuth({publishableKey}), signIn(), handleRedirectCallback(), getSession(), getToken(), onAuthStateChange e signOut(), con vendorData sull’identità. È previsto che aggiunga segnali automatici del dispositivo e un punto di ingresso server con verifyToken().
La chiave pubblicabile è pk_live_ (applicazione di produzione) o pk_test_ (applicazione sandbox), seguita dalla codifica base64url, senza padding, dell’origine della tua applicazione.
L’SDK invia le proprie chiamate API a quell’origine.
La chiave è pubblica: identifica l’applicazione e non è un segreto.
Step-up e riautenticazione nell’anteprima
stepUp({ action, amount?, currency?, redirectUri? })chiamaPOST step-up/della tua applicazione per chiedere seactionrichiede una verifica dell’identità.actionpuò esserepayout,bankocontact, e un payout richiedeamount. Quando si applica una delle tue regole di step-up, reindirizza alla pagina di verifica restituita da Didit.handleStepUpCallback(url?)viene eseguito sulla pagina alla quale la persona torna. Legge?step_up=<id>, lo rimuove dalla barra degli indirizzi e legge l’esito conGET step-up/{id}/.reauthenticate({ method? })autentica di nuovo la stessa persona, nella pagina ospitata (method: "redirect", predefinito) oppure con una passkey (method: "passkey", solo nel dominio di accesso Didit della tua applicazione). Dopo aver completato la pagina ospitata, completa la riautenticazione conhandleRedirectCallback(). Se la completa un’altra persona, la chiamata viene rifiutata constep_up_user_mismatche la sessione originale resta attiva.
{ id, status, approved, rule, method }, dove status può essere not_required, pending, approved, review, declined o expired.
redirectUri ha come valore predefinito l’indirizzo di redirect del client e deve corrispondere esattamente a uno degli indirizzi di redirect registrati per la tua applicazione: quando è richiesto un controllo, Didit rifiuta qualsiasi altro indirizzo.
Prima che il tuo backend agisca su uno step-up, rileggilo con GET step-up/{id}/ e il token di accesso della persona, perché un risultato riportato dal browser può essere alterato.
Un accesso headless può anche restituire protection_required quando le regole di protezione della tua applicazione lo segnalano.
La persona lo completa poi con il codice che Didit le ha inviato via email (protection.verify({ code })) oppure con una passkey (protection.passkey()), e methods elenca quali dei due può usare.
Non installare una versione ipotizzata e non scrivere codice basato su opzioni di callback ipotizzate. Verifica gli export del pacchetto pubblicato, l’emittente e la configurazione delle chiavi prima di sostituire l’esempio ospitato. I metodi basati su password, codice via email, link magico, passkey, telefono, MFA, accesso social, step-up e agenti dipenderanno dall’API supportata da quel rilascio.
Aggiungi altri prodotti
Il tuo backend verifica il token di accesso (vedi token e JWKS) e legge il suovendor_data. Usa quel valore come vendor_data quando crei una sessione di verifica o generi un token di transazione. Un accesso riuscito non implica l’approvazione dell’utente da parte di nessuno dei due prodotti.
Prima di andare in produzione, testa registrazione, accesso di chi è già registrato, annullamento, state non corrispondente, codice riutilizzato, recupero password, MFA, scadenza e logout sulla tua applicazione sandbox attivata.