Vai al contenuto principale
Authentication è una novità: didit_auth dipende dalla release. Le coordinate di distribuzione, le versioni e le firme delle funzioni richiamabili non sono confermate in questa sede. Non installare un pacchetto ipotizzato né usare l’SDK di verifica dell’identità come SDK di Authentication.

​
Prepara l’applicazione

  1. Verifica che Authentication sia attivo per la tua applicazione Didit e copia dalla console l’origine di accesso della tua applicazione (https://<slug>.auth.didit.me, oppure <slug>.sandbox.auth.didit.me per il sandbox).
  2. Registra un URL di callback esatto, supportato dalla tua applicazione e dal runtime. Verifica la proprietà dei link dell’app; non dare per scontato che vengano accettati schemi URL personalizzati arbitrari.
  3. Tieni separate la configurazione di sandbox e quella di produzione, inclusa la gestione dei callback e le credenziali memorizzate.
  4. Scegli la mappatura stabile della persona prima di collegare la verifica o il monitoraggio.
Configura e testa separatamente i link di callback su iOS e Android. Il wrapper di Authentication è separato da didit_sdk, che gestisce la verifica.

​
Implementa il flusso ospitato

Apri il browser di autenticazione nativo del sistema con l’URL {origin}/sign-in. Fornisci un state casuale nuovo, una sfida PKCE S256 e il tuo redirect_uri registrato. Conserva il verifier nella tua app solo per quel tentativo. La guida rapida JavaScript mostra il protocollo sottostante; nel codice nativo usa la crittografia e la gestione degli URL della piattaforma, non gli oggetti globali del browser. Al callback, verifica lo state, la durata della transazione e la destinazione del callback prima di scambiare il codice monouso tramite token/. Usa il verifier originale e l’URI di redirect esatto. Annullare o chiudere il browser non equivale a un accesso riuscito. Memorizza i refresh token nell’archivio protetto della piattaforma nativa; mai in un file di preferenze non cifrato, nei dati di analytics o nei log dei crash. Verifica la sessione corrente usando GET session/ con il Bearer token dell’utente finale. Serializza il refresh, sostituisci entrambi i token insieme e cancella lo stato specifico dell’utente dopo la disconnessione. Per il contratto della richiesta e il comportamento di riutilizzo del refresh, consulta token e JWKS.

​
Anteprima della release SDK nativo

I moduli nativi di Authentication sono previsti per offrire accesso, accesso alla sessione corrente, recupero dei token, disconnessione e step-up, con segnali automatici del dispositivo. Passkey native e archiviazione protetta dei token fanno parte di quella release. Le API del wrapper seguiranno i contratti di piattaforma pubblicati; non copiare argomenti del costruttore o firme dei metodi ipotizzate a partire da un esempio di progettazione. Finché il modulo non sarà rilasciato, mantieni disattivato il suo adapter oppure usa un’implementazione sottoposta a revisione del protocollo ospitato per la tua applicazione abilitata. Non pubblicizzare una guida rapida nativa di Authentication funzionante basandoti solo sull’installazione del pacchetto.

​
Collega verifica e monitoraggio

Il tuo backend deriva vendor_data dalla persona autenticata. Crea le sessioni di verifica o emette i token di monitoraggio con ambito limitato per quella persona. Restituisci alla tua app solo la credenziale di sessione o il token con ambito limitato; la chiave API resta sul server. Usa l’SDK Flutter di verifica quando ti serve la verifica dell’identità. Segui l’invio delle transazioni con l’SDK per il supporto al monitoraggio sulla tua piattaforma. Tratta separatamente le decisioni su accesso, verifica e transazioni.

​
Verifica l’integrazione

Testa il ritorno all’app dopo un avvio a freddo, le transizioni in background e in primo piano, l’annullamento del browser, un callback non corrispondente, il riutilizzo di un codice, la scadenza dei token, il refresh concorrente, la MFA, la disconnessione e l’accesso con un altro utente. Testa la registrazione e l’accesso con passkey sui dispositivi supportati, una volta disponibile quella release. Un controllo eseguito solo sul dispositivo resta non verificato finché non viene eseguito sulla piattaforma di destinazione.
Ultima modifica il 7 novembre 2026