> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Autenticazione utenti finali: accesso, passkey e sessioni > Aggiungi con Didit l'accesso degli utenti finali con pagine ospitate, passkey, codici, social e SSO, collegato alla verifica dell'identità. > [!WARNING] > > 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. | Voce | Valore | | - | - | | Origine predefinita | `https://.auth.didit.me` per un'applicazione di produzione, `https://.sandbox.auth.didit.me` per un'applicazione sandbox. La console mostra la tua. Un dominio personalizzato verificato può sostituirla. | | Pagine ospitate | `/sign-in`, `/magic`, `/invite` e `/reset` su quell'origine. | | API di runtime | La stessa origine, per esempio `POST {origin}/token/` e `GET {origin}/session/`. | | Emittente | L'origine stessa. Il documento di discovery è disponibile in `{origin}/.well-known/openid-configuration`. | | Chiave pubblicabile | `pk_live_...` o `pk_test_...`. Identifica l'applicazione, non è un segreto. | 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](https://docs.didit.me/it/authentication/tokens-and-jwks.md) per il contratto dei token e [metodi di accesso](https://docs.didit.me/it/authentication/sign-in-methods.md) per ciascun metodo. ## Scegli la tua piattaforma > [card] [JavaScript](https://docs.didit.me/it/authentication/quickstarts/javascript.md) > > Accesso ospitato, callback, sessione e logout. > [card] [React](https://docs.didit.me/it/authentication/quickstarts/react.md) > > Stato lato client e viste applicative protette. > [card] [Next.js](https://docs.didit.me/it/authentication/quickstarts/nextjs.md) > > Sessioni lato server, route di callback e cookie. > [card] [iOS](https://docs.didit.me/it/authentication/quickstarts/ios.md) > > Browser di sistema e archiviazione sicura dei token. > [card] [Android](https://docs.didit.me/it/authentication/quickstarts/android.md) > > Autorizzazione tramite browser e callback dell'app. > [card] [React Native](https://docs.didit.me/it/authentication/quickstarts/react-native.md) > > Preparazione del wrapper nativo per l'autenticazione. > [card] [Flutter](https://docs.didit.me/it/authentication/quickstarts/flutter.md) > > 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](#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](https://docs.didit.me/it/authentication/sign-in-methods.md) 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. | Applicazione | Cosa puoi registrare | | - | - | | Produzione | URL `https://` | | Sandbox | URL `https://` e URL `http://` su `localhost`, `127.0.0.1` o `[::1]` | 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://.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`. | Impostazione | Valori | Predefinito | | - | - | - | | `session_lifetime` | `86400`, `604800`, `2592000`, `7776000` secondi | `2592000` (30 giorni) | | `idle_timeout` | `1800`, `7200`, `86400`, `604800` secondi | `86400` (1 giorno) | | `multiple_sessions` | `false` disconnette la persona dalle sue altre sessioni a ogni nuovo accesso | `true` | | `password_min_length` | `8`, `10`, `12`, `14` | `10` | | `revoke_on_password_change` | Termina ogni sessione dopo il reset della password | `true` | | `signup_policy` | `anyone`, `invited`, `allowed_domains` (con `allowed_email_domains`, fino a 100) | `anyone` | | `allow_subaddresses` | Accetta un `+` nella parte locale dell'email | `false` | | `post_logout_redirect_uri` | Dove la tua app invia la persona dopo la disconnessione | Vuoto | | `mfa_policy` | `optional`, `everyone`, `organization_admins` | `organization_admins` | | `sign_in_ui` | `hosted` oppure `own` | `hosted` | ## Mantieni la stessa persona tra i prodotti Ogni identità include un valore `vendor_data`. È l'`external_id` che hai fornito quando hai [importato](https://docs.didit.me/it/authentication/migration.md) 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](https://docs.didit.me/it/authentication/events-and-webhooks.md). Ricava `vendor_data` sul tuo backend da un token verificato, mai da un campo del browser non controllato. | Combinazione di prodotti | Cosa costruisci | | - | - | | Autenticazione | Accesso, validazione delle sessioni e disconnessione. | | Verifica dell'identità + Autenticazione | Avvia una verifica dopo l'accesso, quando la tua policy lo richiede, con il `vendor_data` del token. | | Monitoraggio delle transazioni + Autenticazione | Invia le transazioni per il `vendor_data` della persona che ha effettuato l'accesso. Gli eventi di accesso arrivano nella cronologia e nelle regole della stessa persona. | | Tutti e tre | Un `vendor_data` per persona. Gestisci separatamente la decisione di ciascun prodotto. | Usa il [prompt di integrazione condiviso](https://docs.didit.me/it/integration/integration-prompt.md) per qualsiasi combinazione. Leggi [protezione dai bot](https://docs.didit.me/it/authentication/bot-protection.md) per i criteri applicati durante l'accesso. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.