Una passkey è una coppia di chiavi crittografiche legata a un dominio e custodita dal dispositivo: niente da memorizzare, niente da digitare, niente da rubare in blocco da un database. Per chi sviluppa, la buona notizia è che lo standard WebAuthn è ormai supportato da tutti i browser maggiori; quella meno buona è che l’integrazione tocca i punti più delicati del sistema: registrazione, login e recupero.
Il percorso meno doloroso parte dall’aggiunta, non dalla sostituzione: si offre la passkey come secondo metodo accanto alla password esistente, si misura l’adozione, e solo dopo si valuta quando proporla come default. Le librerie server mature ci sono per tutti i linguaggi principali e gestiscono le verifiche crittografiche; quello che resta a carico vostro è il flusso utente.
Attenzione alla terminologia nelle interfacce: gli utenti non sanno cosa sia una «credenziale WebAuthn». Le piattaforme hanno convergito sulla parola «passkey» e conviene usarla, insieme alle icone di sistema, senza inventare metafore nuove.
La passkey sincronizzata via cloud riduce il problema del dispositivo perso, ma non lo elimina: esiste sempre l’utente che cambia ecosistema o perde tutto insieme. Se il vostro flusso di recupero si riduce a «ti mandiamo un link via email», avete appena reintrodotto dalla finestra l’anello debole che avevate cacciato dalla porta. Serve almeno un secondo fattore reale per il reset, e un registro degli eventi di recupero che qualcuno guardi davvero.
Il consiglio finale è di misurare: percentuale di login con passkey, tassi di fallimento per piattaforma, ticket di supporto legati all’accesso. È l’unico modo per decidere quando spegnere le password — e per accorgersi in tempo se qualcosa nel flusso non funziona.
Prima di scrivere una riga di codice conviene fissare il principio che rende le passkey diverse da tutto ciò che le ha precedute: la credenziale è legata all’origine, e il browser firma solo se il dominio combacia.
«Una passkey non si può digitare nel sito sbagliato. È per questo che il phishing, semplicemente, smette di funzionare.»
dal dossier
Lato applicativo, registrare una credenziale è poco più di questo:
const cred = await navigator.credentials.create({
publicKey: {
challenge, // sfida monouso dal server
rp: { name: "MyDigitalMagazine" },
user: { id, name, displayName },
pubKeyCredParams: [{ type: "public-key", alg: -7 }]
}
});- 01Sync vs device-bound. Passkey sincronizzate (comode, legate all’ecosistema) o ancorate al dispositivo (più rigide, richieste nei contesti regolati).
- 02Recupero account. Il vero punto critico: se l’utente perde il dispositivo, il percorso di recupero non deve reintrodurre la password dalla finestra.
- 03Fallback e transizione. Convivenza coi metodi attuali finché la copertura non è completa, senza lasciare buchi.
Sara Conti
DATA PROTECTION E CYBERSECURITY · 3 DOSSIERScrive di identità digitale, crittografia e sicurezza applicata. Prima del magazine, sette anni da security engineer. (Firma di prova — eliminare prima del lancio.)
Commenti
4 — i migliori in evidenzaI commenti sono riservati ai lettori registrati. La discussione è moderata dalla redazione.
Rollout iniziato in azienda tre mesi fa: confermo, il punto critico è il recupero account, non l’autenticazione.
Articolo chiaro. Aggiungerei una nota sui password manager che ormai fanno da provider di passkey.


Finalmente un pezzo che spiega il recovery e non solo l’hype del login. La parte sul device-bound meriterebbe un approfondimento a parte.