API WebAuthn Signal: Aggiornare ed eliminare le passkey lato client

L'ecosistema delle passkey è in continua evoluzione. Per facilitare questo cambiamento, lo standard WebAuthn sottostante si evolve rapidamente. Le nuove funzionalità nascono spesso da una spiegazione tecnica su GitHub e poi, dopo un'adeguata discussione, si trasformano in una pull request per lo standard. Di recente, questa pull request è stata aggiunta alla bozza dello standard come API WebAuthn Signal. In questo articolo, vedremo:

• Perché è necessaria l'API WebAuthn Signal: quali casi d'uso supporta l'API WebAuthn Signal?
• Come funziona l'API WebAuthn Signal: come funziona esattamente l'API WebAuthn Signal? Quali sono le raccomandazioni per le Relying Party?

Al momento dell'aggiornamento di questo post, a gennaio 2025, l'API WebAuthn Signal è abilitata di default a partire da Chrome 132 ed era precedentemente nota come Reporting API, prima di essere rinominata per evitare conflitti con un'altra API con lo stesso nome.

L'API WebAuthn Signal risponde a casi d'uso specifici legati alla gestione delle passkey lato client. In particolare, aiuta a mantenere sincronizzate le informazioni tra la Relying Party (RP) e gli autenticatori che fanno parte dei sistemi operativi lato client. Esistono i seguenti importanti casi d'uso:

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Quando viene creata una passkey, questa include diverse informazioni: user.id, user.name e user.displayName. La passkey stessa è identificata tramite il Credential ID univoco.

• user.id: è un identificatore univoco che rappresenta l'account a cui è collegata la passkey. Questo user.id è fondamentale perché viene utilizzato per l'effettiva corrispondenza tra la passkey e l'account dell'utente.
• user.name e user.displayName: sono metadati utilizzati esclusivamente a scopo di visualizzazione nell'interfaccia utente.

L'illustrazione seguente mostra una tipica e semplice struttura di database che spiega quali informazioni verrebbero solitamente memorizzate in ciascun campo:

È importante capire che, sebbene user.name (spesso un indirizzo email) e user.displayName (un nome più amichevole e leggibile) aiutino l'utente a identificare il proprio account nell'interfaccia di selezione, la vera associazione tra una passkey e un account è mantenuta tramite user.id e il Credential ID:

• Un account può avere più passkey, ma ogni passkey è identificata in modo univoco e associata all'account tramite user.id.
• Ogni passkey ha un Credential ID univoco generato dall'autenticatore.

Un problema sorge quando user.name, che può essere un indirizzo email, cambia. Attualmente, non esiste un meccanismo per aggiornare questa modifica direttamente sull' autenticatore lato client. user.name può cambiare per vari motivi, ad esempio quando un utente aggiorna il proprio indirizzo email. Nonostante questa modifica nei metadati dell'account lato server, il vecchio user.name continuerà ad apparire nell'interfaccia di selezione delle credenziali, il che può creare confusione per gli utenti.

La soluzione alternativa a questo problema è creare una nuova passkey con user.name aggiornato e lo stesso user.id, per poi sovrascrivere la passkey esistente. Tuttavia, questo approccio è scomodo per diverse ragioni:

1. Ridondanza: ogni user.id può avere una sola passkey per ogni ID di Relying Party, il che significa che la vecchia passkey deve essere sostituita con una nuova, un passaggio in più.
2. Esperienza utente: gli utenti non capiranno perché devono creare una nuova passkey. Questo è il motivo per cui questa soluzione alternativa non è molto diffusa.
3. Complessità: gestire la creazione e la sostituzione delle passkey solo per aggiornare i metadati è una complessità non necessaria.

Indirizzi email, numeri di telefono e altri identificatori possono cambiare regolarmente. Senza un metodo diretto per aggiornare user.name e user.displayName sull'autenticatore, gli utenti potrebbero riscontrare un problema persistente in cui vedono e devono selezionare una passkey associata al loro vecchio indirizzo email. Questa situazione compromette l'esperienza fluida che le passkey mirano a fornire. L'API WebAuthn Signal si propone di risolvere questo problema consentendo alle Relying Party di segnalare aggiornamenti ai metadati delle passkey senza richiedere la creazione di nuove. Prima di spiegare come implementare l'API Signal, esploreremo il secondo importante caso d'uso che affronta.

Become part of our Passkeys Community for updates & support.

Join

Un altro caso d'uso fondamentale è l'eliminazione delle passkey sull'autenticatore lato client. Con il tempo, gli utenti possono revocare le credenziali tramite l'elenco di gestione delle passkey o eliminare i propri account, e diventa necessario assicurarsi che queste credenziali vengano rimosse dall'autenticatore lato client per evitare che appaiano nelle future interfacce di selezione delle credenziali (UI condizionale / compilazione automatica delle passkey).

La necessità di questa funzionalità si presenta in diversi scenari:

1. Passkey eliminata tramite le impostazioni dell'account: quando una credenziale non è più valida, ad esempio dopo che un utente l'ha eliminata esplicitamente tramite le impostazioni dell'account:

Dal punto di vista dell'utente, è difficile capire che un'eliminazione nelle impostazioni del proprio account, in una finestra di dialogo come quella sopra, non comporti la rimozione della passkey su questo client.

2. Eliminazione dell'account: quando un utente elimina il proprio account, tutte le passkey associate dovrebbero essere rimosse.
3. Policy di sicurezza: le Relying Party possono avere policy di sicurezza che richiedono la revoca delle credenziali dopo periodi di inattività o a causa di problemi di sicurezza rilevati.

Senza un metodo diretto per eliminare le passkey lato client, queste credenziali obsolete o non valide continuano a ingombrare l'interfaccia di selezione, generando confusione. Gli utenti potrebbero vedere e tentare di utilizzare passkey non più valide, con conseguenti tentativi di autenticazione falliti e una scarsa esperienza utente.

L'implementazione dell'API WebAuthn Signal comporta diversi passaggi e considerazioni per garantire che la funzionalità sia integrata in modo corretto e sicuro. L'API Signal consente alle Relying Party (RP) di aggiornare o eliminare le credenziali passkey sull'autenticatore lato client. Questa sezione delinea le considerazioni e i passaggi chiave per l'implementazione.

Nell'implementare l'API WebAuthn Signal, è fondamentale tenere a mente le seguenti considerazioni:

• Tutela della privacy: l'API WebAuthn Signal è progettata per tutelare la privacy dell'utente, uno dei pilastri di WebAuthn. Ciò significa che non viene fornito alcun feedback alla RP sull'avvenuta elaborazione della modifica richiesta. L'API opera silenziosamente per prevenire qualsiasi potenziale fuga di informazioni sullo stato delle credenziali.

• Disponibilità dell'autenticatore: l'efficacia dell'API WebAuthn Signal dipende dalla disponibilità dell'autenticatore. Ciò include sia la disponibilità fisica (ad es. la presenza di una chiave di sicurezza) sia il supporto software (ad es. la compatibilità del browser e del sistema operativo). Il browser può eseguire azioni solo se l'autenticatore è accessibile e supporta le operazioni necessarie senza richiedere l'autenticazione biometrica.

• Restrizioni di dominio: l'API garantisce che solo la Relying Party associata a un dominio specifico possa richiedere modifiche alle credenziali relative a quel dominio. Si tratta di una misura di sicurezza per prevenire modifiche non autorizzate da parte di terzi.

• Credential ID come chiave: quando si fa riferimento alle passkey, il Credential ID è la chiave primaria utilizzata dall'API WebAuthn Signal. Questo ID identifica in modo univoco la passkey sull'autenticatore lato client. L'API consente alle RP di modificare i metadati associati alle passkey o di segnalare che a determinate passkey non si dovrebbe più accedere, ma solo tramite il Credential ID. Nel caso in cui un autenticatore non conosca un Credential ID specifico, lo ignorerà silenziosamente.

Queste considerazioni sono essenziali per comprendere gli aspetti più importanti del corretto funzionamento dell'API WebAuthn Signal.

L'API WebAuthn Signal fornisce un meccanismo semplificato per le Relying Party (RP) per aggiornare i metadati associati alle passkey sugli autenticatori lato client. Ciò è particolarmente importante per garantire che gli utenti vedano informazioni accurate e aggiornate nell'interfaccia di selezione delle credenziali senza dover creare inutilmente nuove passkey. Ecco come l'API lo rende possibile:

Aggiornamento dei metadati con signalCurrentUserDetails(options)

Il metodo signalCurrentUserDetails(options) nell'API Signal è specificamente progettato per l'aggiornamento dei metadati delle passkey. Questo metodo consente alle RP di fornire i valori correnti per user.name e user.displayName.

Ecco come funziona il processo (vedi anche lo standard WebAuthn Level 3).

1. Struttura del metodo: il metodo signalCurrentUserDetails(options) include rp.id, user.id e i valori aggiornati per user.name e user.displayName.

PublicKeyCredential.signalCurrentUserDetails({
    rpId: "example.com",
    userId: "aabbcc", // user handle, base64url.
    name: "New user name",
    displayName: "New display name",
});

2. Aggiornamento dei metadati locali: cerca le credenziali disponibili localmente (sull'autenticatore) che corrispondono a rpId e userId. Per tutte le credenziali corrispondenti, l'autenticatore aggiornerà name e displayName della credenziale.

3. Tutela della privacy: il processo è progettato per tutelare la privacy. L'API Signal non fornisce feedback alla RP sull'avvenuto aggiornamento, prevenendo qualsiasi fuga di informazioni sullo stato delle credenziali.

4. Coerenza tra i dispositivi: eseguendo regolarmente i metodi signalCurrentUserDetails(options), le RP possono garantire che i metadati delle passkey rimangano coerenti tra i diversi dispositivi e piattaforme in cui l'utente può autenticarsi. Questo approccio riduce le possibilità che vengano visualizzate informazioni obsolete o errate nell'interfaccia di selezione delle credenziali.

Nello screenshot qui sopra, si può vedere come Google Chrome segnali un aggiornamento di questo tipo all'utente. L'API WebAuthn Signal è parte di Chrome 130 e può essere testata con Google Password Manager su desktop se il flag delle funzionalità web sperimentali è attivato.

L'API WebAuthn Signal fornisce meccanismi per le Relying Party (RP) per segnalare l'eliminazione delle passkey dagli autenticatori lato client. Ciò è essenziale per garantire che le credenziali obsolete o non valide non compaiano nell'interfaccia di selezione delle credenziali, mantenendo così un'esperienza utente snella e sicura. Esistono due metodi per eliminare le passkey localmente: signalUnknownCredential(options) e signalAllAcceptedCredentials(options). Il primo può essere utilizzato in situazioni in cui l'utente non è autenticato, mentre il secondo può essere utilizzato quando l'utente è autenticato. Pertanto, per motivi di privacy, quest'ultimo dovrebbe essere preferito.

Ecco come funzionano i due metodi:

1. Struttura del metodo: il metodo signalUnknownCredential(options) include rpId (ID della Relying Party) e credentialId (l'identificatore univoco della credenziale da eliminare).

PublicKeyCredential.signalUnknownCredential({
    rpId: "example.com",
    credentialId: "aabbcc", // credential id the user just tried, base64url
});

2. Chiamata del metodo: le RP chiamano questo metodo ogni volta che rilevano che una credenziale dovrebbe essere eliminata. Ciò potrebbe avvenire immediatamente dopo un tentativo di autenticazione con una credenziale non valida, durante l'eliminazione dell'account o quando un utente revoca una credenziale tramite le impostazioni dell'account.

3. Gestione del metodo: quando viene chiamato il metodo signalUnknownCredential(options), l'autenticatore lato client cerca di trovare le credenziali che corrispondono a rpId e credentialID specificati per l'omissione. A seconda delle capacità dell'autenticatore, la credenziale viene rimossa o viene impiegata una procedura specifica dell'autenticatore per nascondere la credenziale nelle future cerimonie di autenticazione.

1. Struttura del metodo: il metodo signalAllAcceptedCredentials(options) include rpId (ID della Relying Party), userId e un elenco di Credential ID validi allAcceptedCredentialIds (elenco di identificatori univoci delle credenziali che dovrebbero essere conservate).

PublicKeyCredential.signalAllAcceptedCredentials({
    rpId: "example.com",
    userId: "aabbcc", // user handle, base64url.
    allAcceptedCredentialIds: ["bb"],
});

2. Chiamata del metodo: le RP chiamano questo metodo ogni volta che rilevano che una credenziale dovrebbe essere eliminata e segnalano un elenco di credenziali valide. Questo metodo dovrebbe essere preferito a signalUnknownCredential(options) per eliminare le credenziali.

3. Gestione del metodo: quando viene chiamato il metodo signalAllAcceptedCredentials(options), l'autenticatore lato client confronta rpId e userId. L'autenticatore cerca tutte le credenziali locali che corrispondono a rpId e userId. Il risultato viene confrontato con allAcceptedCredentialIds. Se ci sono credenziali locali che non sono in allAcceptedCredentialIds, queste credenziali vengono rimosse localmente (o nascoste a seconda dell'autenticatore).

4. Rendere nuovamente visibili le credenziali: se una credenziale è stata solo nascosta (a seconda dell'autenticatore) e ora fa parte di allAcceptedCredentialIds, allora sarà di nuovo presente nelle future cerimonie di autenticazione.

5. Consigli utili:

   • Quando si utilizza signalAllAcceptedCredentials(options), è importante notare che gli autenticatori potrebbero non essere sempre connessi al momento dell'esecuzione di questo metodo. Di conseguenza, le Relying Party potrebbero considerare di eseguire signalAllAcceptedCredentials(options) periodicamente, ad esempio a ogni accesso, per garantire che tutte le credenziali siano aggiornate.
   • Le Relying Party devono prestare attenzione quando specificano l'elenco di ID delle credenziali (allAcceptedCredentialIds). Le credenziali non incluse in questo elenco potrebbero essere nascoste o rimosse dall'autenticatore, potenzialmente in modo irreversibile. Per evitare che credenziali valide vengano omesse per errore, è fondamentale assicurarsi che l'elenco sia completo. Se un ID di credenziale valido viene accidentalmente tralasciato, dovrebbe essere aggiunto nuovamente a signalAllAcceptedCredentials(options) il prima possibile per renderlo di nuovo visibile, supponendo che l'autenticatore lo supporti.
   • Ove possibile, gli autenticatori dovrebbero preferire nascondere temporaneamente le credenziali invece di rimuoverle permanentemente. Questo approccio può aiutare a facilitare il recupero se un ID di credenziale valido è stato accidentalmente omesso dalla Relying Party, consentendone il ripristino senza perdita permanente.

Nello screenshot qui sopra, si può vedere come Google Chrome segnali le eliminazioni. L'API WebAuthn Signal fa parte di Chrome 132 e può essere testata con Google Password Manager su desktop.

Per implementare efficacemente l'API WebAuthn Signal e garantire una sincronizzazione fluida dei metadati delle passkey tra gli autenticatori lato client, considerate le seguenti raccomandazioni:

• Tenete d'occhio gli aggiornamenti e l'implementazione effettiva dell'API WebAuthn Signal: rimanete informati sugli ultimi sviluppi e aggiornamenti relativi all'API Signal. L'API WebAuthn Signal è abilitata con Google Chrome 132, e sarà seguita da altri browser (ad es. anche Safari ha annunciato il supporto). Controllate regolarmente i progressi e gli aggiornamenti sull'API WebAuthn Signal per assicurarvi che la vostra implementazione sia in linea con gli standard e le pratiche più recenti. Aggiorneremo questo post in futuro; al momento si basa sulle informazioni disponibili al 14 gennaio 2025.
• Iniziate con l'approccio signalAllAcceptedCredentials(options) dopo ogni login andato a buon fine: questo approccio garantisce che tutti i metadati e gli ID delle credenziali vengano aggiornati con un unico metodo, semplificando il processo e mantenendo la coerenza tra dispositivi e piattaforme, disattivando al contempo le credenziali eliminate o obsolete.
• Messaggistica in tempo reale con signalUnknownCredential(options) per implementazioni su larga scala: considerate l'uso della messaggistica in tempo reale con il metodo signalUnknownCredential(options) in implementazioni su larga scala o quando è necessario un aggiornamento immediato. Questo metodo può migliorare l'efficienza e l'accuratezza della gestione delle credenziali, garantendo che le credenziali non valide o obsolete vengano prontamente rimosse dall'interfaccia di selezione.

Seguendo queste raccomandazioni, potrete implementare efficacemente l'API WebAuthn Signal una volta che sarà supportata, assicurando che i metadati delle passkey rimangano aggiornati e coerenti su tutti gli autenticatori lato client, fornendo così un'esperienza utente fluida e sicura per le passkey.

Lo standard WebAuthn è in continua evoluzione e si arricchisce di funzionalità mese dopo mese. L'introduzione dell'API WebAuthn Signal è un passo avanti significativo nella gestione dei metadati e delle eliminazioni delle passkey sugli autenticatori lato client. Questa API risponde ai casi d'uso cruciali di mantenere le informazioni sincronizzate tra le Relying Party (RP) e gli autenticatori, e di garantire che le passkey non valide o obsolete vengano rimosse, migliorando così l'esperienza utente.

• Perché è necessaria l'API Signal? L'API Signal è essenziale per aggiornare i metadati delle passkey e per eliminarle sugli autenticatori lato client. Risolve i problemi legati a informazioni user.name e user.displayName obsolete, che possono creare confusione quando le credenziali vengono presentate nell'interfaccia di selezione. Inoltre, aiuta a mantenere un'interfaccia di selezione delle credenziali pulita e sicura rimuovendo le passkey revocate o eliminate.
• Come funziona l'API Signal? L'API Signal funziona consentendo alle RP di chiamare metodi sullo stato attuale delle credenziali, inclusi aggiornamenti ai metadati e la segnalazione dell'eliminazione delle passkey. Queste segnalazioni vengono elaborate dall'autenticatore lato client, garantendo che le informazioni presentate agli utenti siano accurate e aggiornate. L'API è progettata per tutelare la privacy e opera senza fornire feedback alla RP sul successo degli aggiornamenti.

Man mano che lo standard WebAuthn si evolve, beneficia dei diversi interessi dei suoi partecipanti, che spingono avanti diverse parti dello standard. Tenere d'occhio questi sviluppi è fondamentale per rimanere aggiornati con le ultime migliorie e per garantire che le implementazioni rimangano allineate con le più recenti best practice e standard. La community di WebAuthn continua a promuovere l'innovazione, rendendo l'autenticazione più sicura e facile da usare.