Samuele D'Arenzo

Digital Product Designer

AI Solutions Designer

CRM & Web App Developer

UI / UX Designer

Marketing Manager

Human Resource Manager

Sales & Business Development Manager

Procurement & Supplier Manager

Samuele D'Arenzo

Digital Product Designer

AI Solutions Designer

CRM & Web App Developer

UI / UX Designer

Marketing Manager

Human Resource Manager

Sales & Business Development Manager

Procurement & Supplier Manager

Blog Post

Passkey nei siti web: WebAuthn, UX e recupero account

Agosto 24, 2026 Sviluppo Web
Passkey nei siti web: WebAuthn, UX e recupero account

La decisione chiave

Le passkey nei siti web eliminano il segreto condiviso, ma non eliminano il bisogno di progettare l’intero percorso di accesso.

  • WebAuthn protegge la credenziale privata sul dispositivo e consegna al server soltanto la chiave pubblica.
  • Registrazione, accesso e gestione devono restare comprensibili anche su un nuovo dispositivo.
  • Il recupero account deve essere resistente quanto il login, altrimenti diventa la scorciatoia più debole.

Le passkey nei siti web permettono di accedere con lo sblocco già configurato sul dispositivo, per esempio PIN o biometria, senza digitare una password. Sembrano un cambiamento semplice nell’interfaccia, ma coinvolgono browser, backend, provider di credenziali, sessioni e assistenza.

Per una PMI o un servizio digitale, il vantaggio arriva quando questa architettura riduce attrito e rischio nello stesso momento. Se l’utente cambia telefono, usa un computer condiviso o perde tutti gli accessi, il sistema deve continuare a offrire un percorso chiaro senza riaprire la porta al phishing.

Passkey nei siti web: cosa cambia con WebAuthn

Durante la registrazione, il dispositivo genera una coppia di chiavi. La chiave privata resta protetta dall’autenticatore o dal provider di passkey; il sito riceve quella pubblica. Al login, il server invia una challenge monouso e verifica la firma restituita dal dispositivo.

Sito e backend

Conservano la chiave pubblica

Generano la challenge e verificano firma, origine e identificatore del sito.

Dispositivo

Protegge la chiave privata

Autorizza l’uso della credenziale con lo sblocco locale senza inviare dati biometrici al sito.

La guida MDN dedicata alle passkey distingue le due operazioni centrali: navigator.credentials.create() registra la credenziale e navigator.credentials.get() autentica l’utente. WebAuthn richiede inoltre un contesto HTTPS, come documenta la Web Authentication API.

Un flusso affidabile in quattro passaggi

Verifica

Conferma l’identità con un metodo adeguato prima di consentire la creazione di una nuova passkey.

Registra

Il backend genera una challenge monouso; browser e autenticatore creano la credenziale associata al dominio.

Autentica

Il server controlla firma, challenge, origine e RP ID prima di aprire la sessione.

Gestisci

L’utente può nominare, riconoscere e revocare le proprie credenziali e riceve una notifica quando ne viene aggiunta una.

Il recupero account decide la sicurezza reale

Una passkey resistente al phishing può essere aggirata da un recupero basato soltanto sulla password. Conviene permettere più credenziali per lo stesso account, distinguere quelle sincronizzate da quelle legate a un dispositivo e definire una procedura verificabile per chi perde tutti gli accessi.

Punto debole

Recupero più facile del login

Una password o una verifica minima permettono di aggiungere una nuova credenziale senza un controllo proporzionato.

Controllo coerente

Recupero osservabile e verificabile

Riautenticazione, notifiche, tempi di attesa e assistenza gestiscono le eccezioni senza indebolire il sistema.

La guida di web.dev sulla registrazione delle passkey raccomanda di non autorizzare una nuova credenziale dopo una verifica basata esclusivamente sulla password. Questo controllo si collega alla gestione della superficie d’attacco web: autenticazione, sessioni, email di recupero e assistenza appartengono allo stesso percorso.

UX: far trovare la passkey quando serve

Nel punto di accesso conviene parlare di sblocco del dispositivo, non di chiavi crittografiche. La FIDO Alliance pubblica linee guida UX per registrazione, accesso, gestione e comunicazione. Tra le opzioni disponibili c’è l’autofill condizionale, che permette al browser di proporre una passkey compatibile nello stesso campo usato per username o password.

Quattro decisioni da chiudere prima del rollout
Area Decisione Segnale di problema
Attivazione Quando proporre la creazione Richiesta improvvisa senza contesto
Accesso Autofill, pulsante e uso da altro dispositivo L’utente non trova la credenziale disponibile
Recupero Prove richieste e tempi di ripristino Il fallback è meno sicuro del login
Gestione Nome, data, dispositivo e revoca Credenziali invisibili o non revocabili

Dal pilot alla produzione senza salti

Pilot

Prova i casi reali

Copri passkey sincronizzate, chiavi di sicurezza, più credenziali e accesso da un altro dispositivo.

Osserva

Misura gli attriti

Rileva completamento, abbandoni, errori per dispositivo e richieste di recupero.

Estendi

Riduci il ruolo delle password

Allarga il rollout soltanto quando gestione e assistenza reggono le eccezioni.

Il rilascio può iniziare offrendo la passkey dopo un accesso riuscito. Questa fase permette di correggere etichette, errori e recupero prima di rendere la nuova modalità centrale. Sicurezza e usabilità vengono così verificate sullo stesso processo, invece di essere trattate come due progetti separati.

Vuoi introdurre le passkey senza creare nuovi punti deboli?

Posso aiutarti a mappare login, backend, recupero account e test cross-device, così il rollout parte da requisiti verificabili e da un’esperienza comprensibile.

Valutiamo il flusso di autenticazione

Taggs:
Write a comment