--- term: 'Autenticazione senza password' seoTitle: 'Autenticazione senza password: passkey, magic link, WebAuthn' headline: 'Che cos''è l''autenticazione senza password?' slug: autenticazione-senza-password category: auth-security shortDefinition: 'L''autenticazione senza password è un modello di accesso che verifica l''identità con una chiave sul dispositivo o la biometria, non con un segreto memorizzato.' relatedTerms: - multi-factor-authentication-mfa - oauth-2-social-login - json-web-token-jwt - identity-access-management-iam contrastsWith: - multi-factor-authentication-mfa aboutTerms: - 'Passkeys' - 'WebAuthn' - 'Magic Links' faq: - question: 'Che cos''è l''autenticazione senza password in parole semplici?' answer: 'Accedere senza digitare una password: l''identità si dimostra con qualcosa che si possiede – un dispositivo che custodisce una chiave crittografica, una casella di posta, una chiave di sicurezza – oppure con qualcosa che si è, tramite la biometria che lo sblocca. La proprietà che la definisce: non esiste alcun segreto condiviso da rubare, riutilizzare o sottrarre con il phishing.' - question: 'L''autenticazione senza password è più sicura delle password?' answer: 'Contro gli attacchi che guidano davvero le violazioni – phishing, credential stuffing, riuso, forza bruta – in modo netto, perché non c''è alcun segreto da rubare lato server né da estorcere a un utente. Non è inattaccabile: i codici si possono intercettare, i dispositivi si rubano e percorsi di recupero deboli minano anche le porte d''ingresso più robuste.' - question: 'Che cosa sono le passkey e come funzionano?' answer: 'Credenziali FIDO costruite su WebAuthn. In fase di registrazione il dispositivo crea una coppia di chiavi e invia al sito solo la chiave pubblica; all''accesso il dispositivo firma la sfida del sito dopo uno sblocco locale con biometria o PIN. La credenziale è legata al dominio reale, quindi un sito sosia ottiene una firma che non vale nulla: è qui che nasce la resistenza al phishing.' - question: 'Qual è la differenza tra passkey sincronizzate e passkey legate al dispositivo?' answer: 'Le passkey sincronizzate sono copie cifrate end-to-end distribuite tramite un credential manager: sopravvivono alla perdita del dispositivo e rendono facile il recupero, al prezzo di fidarsi dell''account di sincronizzazione. Le chiavi legate al dispositivo non lasciano mai l''hardware: garanzia massima, nessuna copia di recupero. Le indicazioni federali attuali accettano le passkey sincronizzate ai livelli di garanzia più comuni.' - question: 'I magic link sono sicuri?' answer: 'Più sicuri delle password per la maggior parte delle persone, e sicuri esattamente quanto la casella di posta in cui arrivano – l''e-mail è il vero authenticator, ed è per questo che le linee guida del NIST non accettano l''e-mail come authenticator fuori banda. L''igiene: token monouso, scadenza breve, generazione casuale, link solo in HTTPS.' - question: 'Senza password è la stessa cosa dell''MFA?' answer: 'No, e l''inquadramento popolare a scelta secca è falso: l''MFA aggiunge fattori, l''autenticazione senza password rimuove quello memorizzato – e una passkey sbloccata con la biometria è entrambe le cose insieme: possesso del dispositivo più l''inerenza che lo sblocca, autenticazione a più fattori in un solo gesto e senza password da nessuna parte.' - question: 'Che cosa succede se si perde il dispositivo?' answer: 'Le passkey sincronizzate si ripristinano tramite il credential manager; quelle legate al dispositivo no, per progetto. La disciplina: registrare almeno due authenticator su dispositivi separati, conservare codici di recupero offline e ricordare che un fallback debole – un OTP via e-mail dietro una passkey – riduce silenziosamente l''intero account alla forza del fallback.' - question: 'Come si aggiunge l''accesso senza password a un''app?' answer: 'Come un''aggiunta, non come un salto nel vuoto: mantenere l''accesso esistente, offrire passkey o magic link come percorso preferito, registrare un fallback già in fase di configurazione e declassare la password più tardi. Per WebAuthn conviene usare una libreria server open source mantenuta per la verifica della cerimonia, invece di scrivere a mano i controlli della sfida e dell''origin.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'W3C Web Authentication (WebAuthn) Level 3' url: 'https://www.w3.org/TR/webauthn-3/' - name: 'FIDO Alliance — Passkeys' url: 'https://fidoalliance.org/passkeys/' - name: 'NIST SP 800-63B — Digital Identity Guidelines: Authentication' url: 'https://pages.nist.gov/800-63-4/sp800-63b.html' - name: 'CISA — Implementing Phishing-Resistant MFA' url: 'https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf' - name: 'Passwordless authentication — Wikipedia' url: 'https://en.wikipedia.org/wiki/Passwordless_authentication' cta: title: 'Senza password, a una Cloud Function di distanza' text: 'Costruisci l''accesso con magic link su Back4app usando Cloud Code – generazione del token, e-mail ed emissione della sessione lato server – oppure collega qualsiasi provider di OTP e di passkey tramite gli adapter di autenticazione personalizzata di Back4app.' linkText: 'Inizia gratis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-10-14' translationKey: passwordless-authentication --- **L'autenticazione senza password è un modello di accesso che verifica l'identità con una chiave sul dispositivo o la biometria, non con un segreto memorizzato.** Nel linguaggio dei fattori: rimuove il "qualcosa che si sa" e autentica con il "qualcosa che si ha" e il "qualcosa che si è" – e nelle varianti più robuste non esiste alcun segreto condiviso: il server archivia una chiave pubblica, la chiave privata non lascia mai il dispositivo, e non c'è nulla da sottrarre con il phishing, da provare in massa o da violare in blocco. Le password sopravvivono non perché siano buone, ma perché sono installate; l'autenticazione senza password è la migrazione che è finalmente in corso su larga scala. ## Punti chiave | Domanda | Risposta | | --- | --- | | Lo scambio | Fuori il fattore di conoscenza; dentro il fattore di possesso e l'inerenza | | Lo standard d'oro | Passkey (FIDO2/WebAuthn) – chiavi legate all'origin, resistenti al phishing | | Il gradiente onesto | Passkey > push/TOTP > magic link > SMS – ciascuno eredita qualcosa | | vs. MFA | Una falsa rivalità – una passkey sbloccata con la biometria *è* MFA, meno la password | | L'anello debole | Il recupero – un fallback più debole della porta d'ingresso diventa la porta | ## La cerimonia WebAuthn, demistificata Il macchinario dietro a ogni richiesta di passkey – due cerimonie, nessun segreto in transito: ```text REGISTRAZIONE ACCESSO 1 il server invia una sfida casuale 1 il server invia una nuova sfida 2 navigator.credentials.create() 2 navigator.credentials.get() 3 il dispositivo crea una coppia di 3 sblocco locale con biometria/PIN, chiavi; biometria o PIN la proteggono il dispositivo FIRMA la sfida 4 chiave pubblica → server; la chiave 4 il server verifica con la chiave privata non lascia il dispositivo pubblica archiviata → sessione emessa La credenziale è legata all'ORIGIN: un dominio sosia ottiene una firma che non si verifica da nessuna parte. È questa proprietà – non la biometria – a dare il significato di "resistente al phishing". ``` La rampa più dolce che la maggior parte delle app distribuisce per prima – i magic link, dove la casella di posta è il fattore: **JavaScript:** ```javascript // JavaScript / Node.js — Back4app JS SDK // Magic link via Cloud Code: possession of the inbox is the factor // 1 · Request: generates a single-use token, emails the link await Parse.Cloud.run('requestMagicLink', { email: 'ada@example.com' }); // 2 · The link opens the app with the token; exchange it for a session const { sessionToken } = await Parse.Cloud.run('redeemMagicLink', { token: tokenFromLink, // single-use, expires in 15 minutes }); await Parse.User.become(sessionToken); // logged in — no password exists ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK // Magic link via Cloud Code: possession of the inbox is the factor // 1 · Request: generates a single-use token, emails the link await ParseCloudFunction('requestMagicLink') .execute(parameters: {'email': 'ada@example.com'}); // 2 · The deep link opens the app with the token; exchange for a session final result = await ParseCloudFunction('redeemMagicLink') .execute(parameters: {'token': tokenFromLink}); // single-use, 15 min // Adopt the returned session token — logged in, no password exists ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK // Magic link via Cloud Code: possession of the inbox is the factor // 1 · Request: generates a single-use token, emails the link _ = try await Cloud.run(name: "requestMagicLink", parameters: ["email": "ada@example.com"]) // 2 · The universal link opens the app with the token; exchange for a session let result = try await Cloud.run(name: "redeemMagicLink", parameters: ["token": tokenFromLink]) try await User.become(sessionToken: result["sessionToken"] ?? "") // logged in — no password exists ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // Magic link via Cloud Code: possession of the inbox is the factor // 1 · Request: generates a single-use token, emails the link ParseCloud.callFunction>( "requestMagicLink", mapOf("email" to "ada@example.com")) // 2 · The deep link opens the app with the token; exchange for a session val result = ParseCloud.callFunction>( "redeemMagicLink", mapOf("token" to tokenFromLink)) // single-use, 15 min ParseUser.becomeInBackground(result["sessionToken"] as String) // logged in — no password exists ``` ## Passkey vs. magic link vs. OTP: i metodi, in classifica Ogni metodo senza password eredita la sicurezza di qualcosa – la tabella dice di che cosa: | Metodo | Fattore | Resistente al phishing? | Erede del rischio di | Storia del recupero | | --- | --- | --- | --- | --- | | **Passkey (sincronizzata)** | Possesso + inerenza | **Sì** – legata all'origin | L'account del credential manager | Si ripristina su più dispositivi | | **Chiave di sicurezza (legata al dispositivo)** | Possesso (+ inerenza) | **Sì** | Custodia fisica | Nessuna – conviene registrarne una di scorta | | Codice TOTP / authenticator | Possesso | No – i codici si possono rilanciare | Segreto di registrazione | Nuova registrazione | | Approvazione push | Possesso | No – e bombardabile | Attenzione dell'utente | Nuova registrazione | | Magic link | Possesso (casella di posta) | No | **L'account e-mail** | *È* il percorso di recupero | | Codice monouso via SMS | Possesso (numero) | No | L'operatore – SIM swap | Il più debole del gruppo | La linea che conta passa tra le prime due righe e il resto: codici, link e approvazioni possono essere tutti rilanciati attraverso un proxy di phishing attivo; [le firme legate all'origin no](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf) – la stessa linea di demarcazione tracciata nella [classifica dei metodi dell'articolo sull'MFA](/glossary/it/autenticazione-multifattore-mfa/), perché è la stessa linea. ```mermaid flowchart LR accTitle: Perché una passkey sconfigge un proxy di phishing accDescr: Con una passkey il dispositivo firma una sfida legata all'origin autentica, quindi un sito falso che rilancia l'accesso riceve una firma che non supera la verifica. Con un codice monouso la vittima può invece essere indotta a digitarlo nel sito falso, che lo rilancia con successo verso quello vero. V["Vittima"] -->|"digita il codice OTP"| F["Sito falso
(proxy)"] -->|"lo rilancia – funziona"| R["Sito vero"] V2["Vittima con passkey"] -->|"il dispositivo firma per
l'origin FALSA"| F2["Sito falso"] -.->|"firma non valida
sull'origin vera"| X["Fallisce"] ``` ## Sincronizzate o legate al dispositivo: il trade-off vero Le passkey si dividono in due modelli di custodia, e la differenza è policy, non pedanteria. Le **passkey sincronizzate** vivono in un credential manager e si replicano, cifrate end-to-end, su tutti i dispositivi di una persona – perdere il telefono diventa un non-evento, ed è per questo che l'adozione di massa si è finalmente mossa; lo scambio di fiducia è che l'account di sincronizzazione diventa il gioiello della corona, protetto dai propri flussi di recupero. Le **chiavi legate al dispositivo** (chiavi di sicurezza hardware, authenticator con attestazione aziendale) non lasciano mai l'hardware – la scelta a garanzia alta per gli amministratori e per gli accessi regolamentati, con "registrarne una di scorta" come intero piano di recupero. Le [indicazioni attuali del NIST](https://pages.nist.gov/800-63-4/sp800-63b.html) hanno chiuso la discussione per il grande pubblico: gli authenticator sincronizzati sono accettabili ai livelli di garanzia standard, mentre quelli legati al dispositivo restano riservati alla fascia più alta. ## Il problema del recupero, di nuovo L'autenticazione senza password affila la regola più antica dell'autenticazione: **un account è forte quanto il suo percorso di recupero più debole.** Un accesso con passkey e fallback via OTP sull'e-mail è, per un attaccante, un accesso via OTP sull'e-mail con qualche passaggio in più. Per una chiave legata al dispositivo non esiste alcun "reset" – per progetto – quindi la disciplina si sposta tutta all'inizio: registrare due o più authenticator su dispositivi separati in fase di configurazione, rilasciare codici di recupero offline, trattare i metodi di fallback come decisioni di sicurezza invece che come comodità per l'assistenza e fare della rimozione di un authenticator un evento con step-up, registrato e con allerta. I deployment che saltano questo passaggio lo reimparano attraverso il proprio help desk. ## Non contro l'MFA – una fusione L'inquadramento "senza password vs. MFA" delle pagine di confronto dei vendor è un falso binario. L'[MFA](/glossary/it/autenticazione-multifattore-mfa/) significa più *categorie* di fattori; senza password significa nessun segreto memorizzato. Una passkey sbloccata con l'impronta è **entrambe le cose**: possesso del dispositivo più inerenza al momento dello sblocco – autenticazione a più fattori in un solo gesto, con l'elemento soggetto a phishing cancellato invece che integrato. La conseguenza pratica: le organizzazioni non scelgono tra le due; passano da "password + secondo fattore" a "passkey", che è un punto strettamente più forte sulla stessa curva. ## Casi d'uso tipici - **Accesso ad app consumer** – le passkey come percorso promosso; i magic link come fallback a basso attrito. - **Commercio con visite ripetute** – dove l'attrito dell'accesso è ricavo misurabile, l'accesso in un solo gesto si guadagna lo stipendio. - **Accesso workforce** – authenticator resistenti al phishing come policy per gli amministratori e i ruoli a privilegio alto. - **Prodotti senza password dall'inizio** – onboarding via link e-mail o OTP, senza che un campo password venga mai distribuito. - **Momenti di step-up** – una cerimonia passkey come riautenticazione prima di pagamenti, cancellazioni ed esportazioni di chiavi. ## Conviene passare al senza password? Matrice decisionale | Situazione | Verso cui propendere | | --- | --- | | Nuova app consumer | Passkey + fallback magic link; niente campo password | | App esistente, base utenti ampia | Coesistenza: aggiungere le passkey come preferite, declassare le password dopo | | Account amministrativi o a privilegio alto | Solo metodi resistenti al phishing – passkey o chiavi hardware | | Pubblico su dispositivi condivisi o vecchi | Magic link / OTP con aspettative oneste | | Accesso regolamentato, a garanzia alta | Authenticator legati al dispositivo, attestazione, scorte registrate | | "Aggiungiamo sicurezza in questo sprint" | [MFA sull'accesso esistente](/glossary/it/autenticazione-multifattore-mfa/) adesso; senza password dopo | ## Limiti e trade-off - **La copertura non è universale.** Non tutti i siti, i browser e gli stack aziendali supportano ancora le passkey; le password restano come impalcatura di compatibilità, ed è per questo che la coesistenza batte la migrazione a salto nel vuoto. - **L'ecosistema tiene le chiavi.** Le passkey sincronizzate delegano la custodia ai credential manager delle piattaforme – una dipendenza di disponibilità e di fiducia che si eredita invece di gestirla in proprio. - **Il recupero è il progetto vero.** La cerimonia più forte con un percorso di reset debole è teatro; vanno messe in budget la UX della registrazione e la policy di fallback, non solo l'integrazione WebAuthn. - **Un senza password più debole resta più debole.** Magic link e SMS rimuovono la password senza aggiungere resistenza al phishing – un miglioramento, non la destinazione. - **I modelli di assistenza cambiano.** I ticket "password dimenticata" diventano ticket "dispositivo perso"; gli help desk hanno bisogno di procedure di verifica che non diventino il nuovo buco di social engineering. ## Autenticazione senza password su Back4app Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. Qui l'autenticazione senza password è un pattern che si compone dai mattoni della piattaforma, e le schede di codice mostrano quello canonico: un flusso magic link costruito con due funzioni di Cloud Code – `requestMagicLink` genera un token monouso a scadenza breve, lo archivia sull'utente e spedisce il link via e-mail; `redeemMagicLink` lo valida lato server e restituisce un [session token](/glossary/it/gestione-delle-sessioni/) che l'SDK adotta, così il client non maneggia credenziali in nessun momento. Oltre ai link, gli adapter di autenticazione personalizzata di Back4app innestano provider di OTP e di passkey nello stesso meccanismo `authData` che alimenta il [login social](/glossary/it/oauth-2-login-social/) – un solo oggetto utente, più metodi di accesso, collegabili e scollegabili per singolo utente, che è la disciplina del recupero (più metodi registrati) espressa come modellazione dei dati. Le sessioni restano revocabili dall'inizio alla fine: qualunque sia la cerimonia, la credenziale che emette si può uccidere nell'istante in cui qualcosa sembra sbagliato.