Accesso senza password per app aziendali: magic link vs passkey

Cosa significa davvero “passwordless” per un'app aziendale

“Passwordless” non significa “niente sicurezza”. Significa che gli utenti non creano né ricordano una stringa segreta a lunga durata. Invece, il login viene approvato con qualcosa che possiedono (un dispositivo, una casella email, un numero di telefono) o con qualcosa integrato nel dispositivo (sblocco biometrico), solitamente supportato da una prova a breve termine come un link, un codice o una chiave crittografica.

Per le app aziendali l'obiettivo è pratico: eliminare i due problemi quotidiani più grandi delle password. Le persone le dimenticano e le resettano. E le riutilizzano, rendendo il phishing e il credential stuffing molto più efficaci. Questo si traduce in ticket al supporto, takeover di account e dipendenti frustrati che non riescono ad accedere agli strumenti di cui hanno bisogno.

I team di solito abbandonano le password perché cambia l'operatività:

• Meno richieste “reset password”
• Meno esposizione a pagine di phishing che rubano credenziali
• Onboarding più rapido (niente lezione sulle regole delle password il primo giorno)
• Accesso più pulito per collaboratori a breve termine o stagionali
• Accesso più coerente su web e mobile

Il passwordless introduce però nuovi modi di fallire. Se il login dipende dall'email, ritardi o filtraggi nello spam possono bloccare l'accesso nei momenti peggiori. Se dipende dal telefono, un dispositivo perso o un cambio numero può bloccare qualcuno. Se dipende da risorse condivise, come una casella condivisa o un telefono condiviso in reparto, è facile scivolare verso “account condivisi”, che danneggia i log di audit e l'offboarding.

La aspettativa da fissare presto è semplice: non esiste un metodo che vada bene per ogni utente, dispositivo e contesto di lavoro. La maggior parte delle app aziendali finisce per avere un metodo di accesso primario più un metodo di backup per il recupero.

Se stai costruendo uno strumento interno o un portale clienti in AppMaster, pianifica l'accesso come qualsiasi altra funzionalità core. Decidi chi sono i tuoi utenti, quali dispositivi usano e cosa il tuo team di supporto può realisticamente gestire quando qualcuno non riesce a fare login.

Panoramica rapida: magic link, codici OTP e passkey

“Passwordless login” di solito significa che gli utenti dimostrano di essere loro senza creare o ricordare una password. Le opzioni principali sono magic link, codici one-time (OTP) e passkey. Tutte e tre riducono il riuso delle password, ma si comportano in modo molto diverso nelle operazioni reali.

I magic link fanno accedere un utente tramite un link unico inviato alla sua email. Il link tipicamente funziona una volta sola e scade rapidamente. È comodo perché l'utente apre la posta e clicca. Il compromesso è che la casella email diventa il guardiano: se l'email è in ritardo, filtrata o l'utente è disconnesso dalla posta su quel dispositivo, l'accesso si blocca.

Gli OTP sono numeri brevi e a tempo che l'utente digita. Possono essere inviati via email, SMS o generati in un'app autenticatore. L'OTP via email ha la stessa dipendenza di deliverability dei magic link, ma funziona anche se l'utente non può aprire link. L'OTP via SMS può aiutare quando l'email è lenta, ma aggiunge costi ed è vulnerabile al takeover del numero di telefono.

Le passkey sono credenziali legate al dispositivo memorizzate su telefono, laptop o chiave hardware. L'utente conferma con impronta, riconoscimento facciale o PIN del dispositivo. È spesso l'esperienza più fluida una volta configurata e resiste al phishing meglio di link o codici. La difficoltà è il recupero: le persone perdono dispositivi, cambiano telefono o usano postazioni condivise.

Una configurazione ibrida comune è:

• Passkey come accesso principale su dispositivi noti
• OTP via email o SMS come fallback per nuovi dispositivi e recovery
• Reset tramite helpdesk amministrativo per casi limite (dipendenti terminati, caselle condivise)

Se stai costruendo uno strumento interno in una piattaforma come AppMaster, tratta l'accesso come parte sicurezza e parte carico di supporto. Il metodo “migliore” è quello che i tuoi utenti riescono a completare in modo affidabile, anche nel loro peggior lunedì mattina.

Compromessi di sicurezza da considerare

La domanda chiave di sicurezza è semplice: cosa può realisticamente rubare un attaccante e quanto facilmente può convincere un dipendente reale a consegnarglielo?

Resistenza al phishing (chi viene ingannato)

Le passkey sono le più difficili da phishingare nell'uso normale perché il login è legato all'app o al sito reale e non si basa su un codice che puoi leggere e digitare in una pagina falsa. Gli OTP (SMS o autenticatore) sono i più facili da ottenere via social-engineering perché gli utenti sono addestrati a condividerli sotto pressione. I magic link stanno nel mezzo: molte persone cliccano un link che sembra una email di accesso, specialmente se l'attaccante imita lo stile della tua email.

Una comparazione utile è chiedersi cosa serve all'attaccante:

• Magic link: accesso alla casella email dell'utente (o controllo dell'inoltro email)
• Email OTP: accesso alla casella email dell'utente
• SMS OTP: SIM swap, takeover dell'operatore o accesso al telefono e alle notifiche
• Passkey: accesso a un dispositivo fidato più un modo per superarne lo sblocco (o accesso all'account di sincronizzazione delle passkey)

Principi di sessione che riducono i danni

Anche un login forte può essere indebolito da una gestione delle sessioni approssimativa. Imposta questi default presto e mantienili coerenti su web e mobile:

• Vita breve per link/codici (minuti, non ore)
• Uso singolo e invalidazione dei link/codici precedenti quando se ne emette uno nuovo
• Revoca chiara (logout di tutte le sessioni, revoca di un dispositivo, rotazione dei token)
• Controlli extra per eventi rischiosi (nuovo dispositivo, nuova posizione, cambi di privilegi)

I flussi amministrativi e di supporto sono il rischio silenzioso. Se un operatore helpdesk può “semplicemente cambiare l'email” o “saltare la verifica” per sbloccare qualcuno, quella via verrà sfruttata. In un portale di approvazione finanziaria interno, per esempio, un attaccante ha bisogno di una sola chat di supporto convincente per farsi impostare una nuova email e quindi ricevere magic link. Richiedi passi di recovery registrati, separa i permessi di “supporto” da quelli di “overturn account”.

Deliverability email: il costo nascosto del login via email

Il login via email (magic link o codici) sembra semplice, ma la deliverability può diventare il costo operativo maggiore. Il ticket di supporto più comune non è “ho dimenticato la password.” È “non ho ricevuto l'email.”

Ritardi e email mancanti vengono di solito da filtri antispam, gateway aziendali e regole nella casella. Un magic link che arriva in ritardo di tre minuti non è solo fastidioso. Può generare richieste ripetute, lockout e utenti frustrati che iniziano a condividere screenshot della posta con il supporto.

La reputazione del mittente conta più di quanto la maggior parte delle squadre si aspetti. A grandi linee, il tuo dominio deve dimostrare che è autorizzato a inviare email di login e che i messaggi non sono stati alterati. Gli elementi classici sono SPF (chi può inviare), DKIM (firme del messaggio) e DMARC (cosa fare quando i controlli falliscono).

Anche con questi a posto, i pattern di invio possono comunque danneggiarti. Se un utente preme “invia di nuovo” cinque volte, puoi rapidamente sembrare uno spammer, specialmente quando molti dipendenti accedono nello stesso momento dopo una riunione o un cambio turno.

Rate limit e retry hanno bisogno di un piano. Rallenta i reinvio ripetuti senza intrappolare utenti legittimi. Una soluzione pratica include un breve cooldown per il reinvio, un timer visibile, un suggerimento “controlla lo spam” e un metodo fallback (come SMS OTP o passkey) per caselle bloccate. Registra rimbalzi, blocchi e tempi di consegna e mostra messaggi di errore utili al supporto che identifichino il problema.

Se stai costruendo uno strumento interno, il filtraggio aziendale è la vera prova. Un dipartimento potrebbe ricevere le email bene mentre un altro non ne vede mai. Piattaforme come AppMaster possono aiutarti a collegare i flussi email rapidamente, ma il lavoro a lungo termine è monitorare la consegna e progettare un fallback elegante così che “non ho ricevuto l'email” non diventi un'emergenza quotidiana.

SMS OTP: quando aiuta e quando danneggia

Gli OTP via SMS sembrano semplici: inserisci il numero, ricevi un SMS, digiti il codice. Questa semplicità può essere un vero vantaggio quando gli utenti non sono pronti per le passkey o quando l'email è inaffidabile.

Il primo problema è la consegna. Gli SMS non arrivano uniformemente tra paesi e operatori. Il roaming può ritardare o bloccare i messaggi, e alcuni telefoni aziendali filtrano mittenti sconosciuti. I cambi numero sono anche comuni. Gli utenti cambiano operatore, perdono la SIM o tengono un numero vecchio legato a un account di cui hanno ancora bisogno, e il “login rapido” si trasforma in ticket al supporto.

La sicurezza è la preoccupazione più grande. L'SMS prova il controllo di un numero, non di una persona. Questo crea problemi concreti:

• Attacchi di SIM swap possono reindirizzare i codici a un attaccante
• Piani familiari e dispositivi condivisi possono esporre i messaggi ad altri
• Numeri riciclati possono permettere a un nuovo proprietario di ricevere codici per un account vecchio
• Le anteprime sul lock-screen possono mostrare codici a chiunque sia vicino
• I telefoni rubati spesso ricevono ancora SMS se la SIM è attiva

Costi e affidabilità contano, inoltre. Ogni tentativo di login può generare un messaggio a pagamento e molte squadre se ne accorgono solo dopo il lancio. I provider SMS e gli operatori hanno anche interruzioni. Quando i testi falliscono durante un cambio turno, il tuo help desk diventa il sistema di login.

Quindi quando ha senso l'SMS? Di solito come fallback, non come ingresso principale. Funziona bene per ruoli a basso rischio (per esempio accesso in sola lettura a una directory semplice), o come ultima risorsa di recovery quando l'utente non può usare email o passkey.

Un approccio pratico è riservare l'SMS al recovery e richiedere un controllo extra per azioni sensibili, come cambiare dettagli di pagamento o aggiungere un nuovo dispositivo.

Passkey nella vita reale: accesso fluido, recovery complicato

Le passkey sono fantastiche quando tutto va bene. Un utente tocca “Accedi”, conferma con Face ID o Touch ID (o digita un PIN del dispositivo) e entra. Non c'è password da sbagliare, né codice da copiare, e il phishing è molto più difficile.

I problemi emergono nel giorno peggiore, non in quello migliore. Un telefono viene perso. Un laptop viene sostituito. Qualcuno arriva con un dispositivo nuovo e non può accedere al vecchio. Con le passkey, “ho dimenticato la password” diventa “come dimostro che sono io senza il dispositivo che lo dimostra?”

L'uso su più dispositivi è anche più complicato di quanto sembri. Le passkey possono sincronizzarsi dentro un ecosistema, ma molte squadre sono miste: iOS e Android, laptop Windows, Mac condivisi o dispositivi di contractor. I dispositivi condivisi sono particolarmente ostici perché di solito non vuoi una passkey salvata su un chiosco o su un computer di turno.

Una policy pratica bilancia velocità e recovery:

• Consenti più passkey per utente (telefono di lavoro + telefono personale, o telefono + laptop)
• Chiedi agli utenti di aggiungere una seconda passkey durante l'onboarding, non dopo
• Mantieni almeno un metodo fallback (magic link via email verificata o OTP in stile autenticatore)
• Fornisci un flusso di recovery assistito dall'amministratore per account aziendali (con log di audit)
• Definisci regole per dispositivi condivisi (usa sessioni a breve durata, non passkey salvate)

Esempio: un caposquadra del magazzino usa un tablet condiviso. Le passkey sono perfette sul telefono personale, ma sul tablet condiviso potresti richiedere una sessione a breve durata più un secondo fattore. Se costruisci l'app in AppMaster, tratta questo come requisito di prodotto presto così puoi modellare recovery, auditing e reset admin basati sui ruoli insieme al flusso di accesso.

Passo dopo passo: scegliere un metodo di accesso per la tua app

Inizia con chi accede e cosa fanno. Un dipendente con un laptop gestito può usare le passkey comodamente, mentre un contractor su dispositivi condivisi potrebbe aver bisogno di un codice one-time. La configurazione migliore è solitamente un metodo primario più un fallback, non tre opzioni che confondono tutti.

Procedi con queste domande in ordine:

• Chi sono i tuoi gruppi di utenti (dipendenti, clienti, admin, contractor) e quali dispositivi usano realmente?
• Qual è il tuo accesso primario e qual è il fallback quando il primario fallisce?
• Qual è il percorso di recovery se un utente perde il telefono, cambia email o non può accedere al dispositivo?
• Qual è il tuo “budget di abuso” (quanta rischio e carico di supporto puoi tollerare)?
• Cosa devi dimostrare dopo un incidente (log e tracce di audit)?

Poi imposta finestre temporali chiare. I magic link dovrebbero scadere rapidamente, ma non così in fretta che le persone non riescono a usarli. Gli OTP devono essere a breve durata, con cooldown per i reinvio per ridurre tentativi bruteforce e “spam dell'inbox”.

Decidi anche cosa succede dopo ripetuti fallimenti: blocco temporaneo, step-up verification o revisione manuale.

Il logging non è opzionale. Registra login riusciti, tentativi falliti (con ragione) e stato di consegna per email o SMS (inviato, rimbalzato, in ritardo). Questo rende visibili i problemi di deliverability e aiuta il supporto a rispondere “è arrivata?” senza indovinare.

Infine, scrivi lo script di supporto. Definisci come il personale verifica l'identità (per esempio ID dipendente più conferma del manager) e cosa è consentito cambiare (email, telefono, dispositivo). Se costruisci questo in AppMaster, mappa queste regole nei tuoi auth flow e processi aziendali presto così il recovery è coerente su web e mobile.

Scenario d'esempio: un portale interno con dispositivi misti

Immagina un portale operativo usato da 50 persone e alcuni contractor. Copre passaggi di turno, note sugli incidenti, richieste di inventario e approvazioni. La gente accede più volte al giorno, spesso muovendosi tra scrivanie, magazzini e furgoni.

I vincoli sono complicati, come nella maggior parte dei team reali. Alcuni ruoli usano alias email condivisi (per esempio capiservizio notturni che ruotano settimanalmente). Gli operatori sul campo a volte hanno copertura cellulare scarsa e alcune aree non hanno segnale. I manager usano per lo più iPhone e si aspettano un accesso rapido e familiare. I contractor vanno e vengono, quindi l'accesso deve essere facile da concedere e revocare.

Una configurazione pratica in questa situazione potrebbe essere:

• Passkey come default per i dipendenti (buon equilibrio tra velocità e resistenza al phishing)
• OTP via email come fallback quando l'utente è su un dispositivo nuovo o la passkey non è disponibile
• SMS solo per recovery e solo per un piccolo insieme di utenti che non possono accedere affidabilmente all'email (per limitare il rischio di SIM-swap e i costi)
• Account separati per ruoli condivisi invece di caselle condivise, con accesso basato sui ruoli dentro il portale
• Un percorso di recovery chiaro per “dispositivo perso” che termina con la reiscrizione di una nuova passkey

Perché funziona: i dipendenti ottengono accesso con un tap la maggior parte delle volte, mentre i fallback coprono i giorni complicati (telefono nuovo, laptop dimenticato, ricezione scarsa). I contractor possono restare su OTP via email, così non dipendi da passkey su dispositivi personali. Se costruisci il portale in AppMaster, è più semplice testare questa combinazione presto perché puoi collegare autenticazione e messaggistica rapidamente e poi aggiustare in base ai dati reali di supporto.

Dopo 30 giorni, il successo si vede in meno accessi bloccati (soprattutto per i manager), meno lamentele “non ho ricevuto l'email” perché l'OTP è principalmente di backup, e meno ticket di reset perché le passkey eliminano il ciclo “ho dimenticato la password”.

Errori comuni che generano ticket e rischio

La maggior parte dei rollout passwordless fallisce per ragioni banali: il login funziona in demo, poi gli utenti reali incontrano casi limite e il supporto si allaga.

Un problema frequente con i magic link è essere troppo permissivi. Se un link resta valido per ore (o giorni), o può essere usato più volte, diventa una chiave trasferibile. Le persone inoltrano email a un collega, aprono il link sul dispositivo sbagliato o ritrovano un link vecchio nella ricerca della posta. Finestre di validità strette e uso monouso riducono quel rischio e tagliano i ticket “perché sono entrato come un altro?”

Gli OTP generano confusione quando i reinvio sono illimitati. Gli utenti premono “invia di nuovo” cinque volte, il provider email vede un picco e le future email cominciano a finire nello spam. Poi gli utenti reinviano ancora, peggiorando la deliverability. Metti un cooldown breve, mostra un timer chiaro e limita i tentativi totali per ora.

Un'altra svista è non legare l'accesso al contesto giusto. Alcune app dovrebbero permettere “clicca il link sul telefono, continua sul laptop.” Altre no. Per strumenti interni sensibili, è più sicuro vincolare il magic link o il flusso OTP alla stessa sessione del browser che l'ha avviato, o richiedere una conferma extra quando il dispositivo cambia.

L'errore più costoso è saltare un vero percorso di recovery. Quando gli utenti perdono un telefono o cambiano dispositivo, i team improvvisano e gli admin cominciano ad approvare manualmente gli accessi in chat. Questo diventa rapidamente un problema di verifica dell'identità.

Una policy semplice per evitare il caos:

• Magic link monouso e a vita breve (minuti, non ore)
• Reinvi throttling e rate limit per utente e IP
• Regole chiare per il cambio dispositivo, con controlli step-up per ruoli sensibili
• Un flusso di recovery documentato (e log di audit) che non si basi su “chiedere all'admin”

Se costruisci in una piattaforma come AppMaster, tratta questi punti come requisiti di prodotto, non come ripensamenti. Modellano sia la postura di sicurezza sia il carico di supporto.

Checklist rapida prima del rilascio

Prima di lanciare l'accesso passwordless, fai un rapido controllo “ticket di supporto”. La maggior parte dei problemi non è crittografia. Sono problemi di tempo, consegna e recovery.

Inizia con i limiti temporali. Un magic link o un codice one-time dovrebbe scadere abbastanza in fretta da ridurre il rischio, ma non così velocemente che email lente, copertura cellulare debole o cambio dispositivo lo facciano fallire. Se scegli cinque minuti, testalo con ritardi reali nelle inbox e con persone vere.

Checklist pre-lancio:

• Imposta regole realistiche di scadenza per link e codici e mostra un errore chiaro quando scadono
• Aggiungi cooldown per i reinvio e regole di lockout e documentale per il team di supporto (quanti tentativi, quanto aspettare)
• Offri almeno due percorsi di recovery (per esempio passkey più OTP via email) così un telefono perso non blocca l'utente
• Registra una trail di audit: chi ha effettuato l'accesso, quando, quale metodo ha usato e lo stato di consegna (inviato, rimbalzato, in ritardo, fallito)
• Proteggi azioni admin e ad alto rischio con controlli più forti (ri-autenticazione per cambiare dati di pagamento, aggiungere admin, esportare dati)

Fai una piccola prova: chiedi a un collega di accedere con un dispositivo nuovo, con inbox piena e con modalità aereo, poi recuperare l'accesso dopo aver “perso” il dispositivo primario. Se quel percorso è confuso, gli utenti apriranno ticket.

Se costruisci l'app in AppMaster, pianifica dove registrare questi eventi (tentativi di accesso, esiti di consegna, prompt step-up) così il team può debuggare senza indovinare.

Passi successivi: pilota, misura e migliora senza rallentare

Tratta il passwordless come un cambiamento di prodotto, non come una casella da spuntare. Inizia con un piccolo pilota: un team, un metodo primario (per esempio passkey) e un fallback (per esempio OTP via email). Mantieni il gruppo abbastanza piccolo da poter parlare con le persone quando qualcosa si rompe, ma abbastanza grande da vedere pattern reali.

Decidi in anticipo cosa significa “funzionare” e monitoralo dal giorno uno. I segnali più utili sono semplici: fallimenti di consegna (email rimbalzate o in ritardo, SMS non ricevuti), tempo medio di login (dal tap all'ingresso nell'app), ticket di supporto e motivi principali, lockout e richieste di recovery, e abbandoni (utenti che iniziano il login ma non lo completano).

Poi aggiungi controlli in base a ciò che impari, non in base a cosa suona meglio sulla carta. Se i link email sono in ritardo, migliora la deliverability e accorcia la scadenza. Se l'SMS OTP viene abusato, aggiungi rate limit e controlli step-up. Se le passkey confondono su dispositivi condivisi, rendi evidente l'opzione “usa un altro metodo”.

Mantieni il loop stretto: rilascia un piccolo miglioramento ogni settimana e scrivi il motivo in linguaggio semplice. Per esempio, “Abbiamo ridotto la scadenza dei magic link da 30 a 10 minuti perché i link inoltrati hanno causato due takeover di account.”

Se stai costruendo l'app da solo, AppMaster può aiutarti a testare velocemente questi cambiamenti: crea schermate auth nell'UI builder, invia email o SMS con i moduli preconfezionati e controlla regole (rate limit, retry, recovery) nell'Editor dei Business Process senza riscrivere tutto.

Quando il pilota è stabile, espandi team dopo team. Mantieni il fallback finché i dati non mostrano che puoi rimuoverlo in sicurezza, non finché ti sembra il momento giusto.