Vai al contenuto principale
Authentication è una novità: DiditAuth per iOS dipende dal rilascio. Le coordinate di distribuzione, le versioni e le firme richiamabili non sono confermate qui. 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 abilitato per la tua applicazione Didit e copia dalla console la sua origine di accesso (https://<slug>.auth.didit.me, oppure <slug>.sandbox.auth.didit.me per la sandbox).
  2. Registra un URL di callback esatto supportato dalla tua applicazione e dal runtime. Verifica la proprietà dei link delle app; non dare per scontato che vengano accettati schemi URL personalizzati arbitrari.
  3. Tieni separate la configurazione sandbox e quella di produzione, inclusa la gestione dei callback e le credenziali memorizzate.
  4. Scegli la tua mappatura stabile delle persone prima di collegare la verifica o il monitoraggio.
Per l’accesso ospitato usa la sessione di autenticazione di sistema. Pianifica insieme la gestione nativa delle passkey e il dominio della parte affidataria; una WebView non sostituisce il flusso di autenticazione di sistema.

​
Implementa il flusso ospitato

Apri una sessione del browser di autenticazione di sistema con l’URL {origin}/sign-in. Fornisci un state casuale nuovo, una challenge 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 le variabili globali del browser. Al callback, verifica lo state, la durata della transazione e la destinazione del callback prima di scambiare il codice monouso su token/. Usa il verifier originale e l’URI di reindirizzamento esatto. Annullare o chiudere il browser non equivale a un accesso riuscito. Memorizza i refresh token in un archivio credenziali protetto dalla piattaforma; mai in un file di preferenze in chiaro, né in strumenti di analisi o nei log dei crash. Verifica la sessione corrente con GET session/ usando 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 delle richieste e il comportamento di riutilizzo del refresh, consulta token e JWKS.

​
Anteprima dell’SDK nativo

I moduli nativi di Authentication sono previsti per offrire accesso, accesso alla sessione corrente, recupero dei token, disconnessione e autenticazione con aumento del livello di sicurezza, con segnali automatici del dispositivo. Le passkey native e l’archiviazione protetta dei token fanno parte di quella versione. Le API wrapper seguiranno i contratti di piattaforma pubblicati; non copiare argomenti del costruttore o firme di metodi ipotizzate da un esempio di progettazione. Finché il modulo non sarà rilasciato, lascia disabilitato il suo adattatore oppure usa un’implementazione revisionata 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 sessioni di verifica o genera token di monitoraggio con ambito limitato per quella persona. Restituisci all’app solo la credenziale di sessione o il token con ambito limitato; la chiave API resta sul server. Usa l’SDK di verifica per iOS quando ti serve la verifica dell’identità. Segui l’invio delle transazioni tramite SDK per il supporto al monitoraggio sulla tua piattaforma. Tratta separatamente l’accesso, la verifica e le decisioni sulle transazioni.

​
Verifica l’integrazione

Testa il ritorno a un’app avviata da zero, le transizioni tra background e foreground, l’annullamento nel browser, un callback non corrispondente, la riproduzione di un codice, la scadenza dei token, il refresh concorrente, MFA, la disconnessione e l’accesso come un altro utente. Testa la registrazione e l’accesso con passkey sui dispositivi supportati, una volta disponibile quella versione. Un controllo eseguibile solo su dispositivo resta non verificato finché non viene eseguito sulla piattaforma di destinazione.
Ultima modifica il 7 novembre 2026