Il problema risolto dalle richieste di origine correlate
Le passkey sono associate a un sito web specifico e possono essere utilizzate solo per accedere al sito web per cui sono state create.
Questo valore è specificato nell'ID della terza parte (ID RP), che per le passkey create per il dominio example.com potrebbe essere www.example.com
o example.com
.
Sebbene gli ID RP impediscano l'utilizzo delle passkey come singola credenziale per l'autenticazione ovunque, creano problemi per:
- Siti con più domini: gli utenti non possono utilizzare la stessa passkey per accedere su diversi domini specifici per paese (ad esempio
example.com
eexample.co.uk
) gestiti dalla stessa azienda. - Domini con nome del brand: gli utenti non possono utilizzare la stessa credenziale su diversi domini utilizzati da un singolo brand (ad esempio
acme.com
eacmerewards.com
). - App mobile: spesso le app mobile non hanno un proprio dominio, il che rende difficile la gestione delle credenziali.
Esistono soluzioni alternative basate sulla federazione delle identità e altre basate su frame, ma in alcuni casi sono scomode. Le richieste di origine correlate rappresentano una soluzione.
Soluzione
Con le richieste di origine correlate, un sito web può specificare le origini autorizzate a utilizzare il proprio ID RP.
In questo modo, gli utenti possono riutilizzare la stessa passkey su più siti che gestisci.
Per utilizzare le richieste di origine correlate, devi pubblicare un file JSON speciale in un URL specifico https://{RP ID}/.well-known/webauthn
. Se example.com
vuole consentire alle origini aggiuntive di utilizzarlo come ID RP, deve pubblicare il seguente file in https://example.com/.well-known/webauthn:
{
"origins": [
"https://example.co.uk",
"https://example.de",
"https://example-rewards.com"
]
}
La volta successiva che uno di questi siti effettua una chiamata per la creazione di passkey (navigator.credentials.create
) o l'autenticazione (navigator.credentials.get
) che utilizza example.com
come ID RP, il browser noterà un ID RP che non corrisponde all'origine richiedente. Se il browser supporta le richieste di origine correlata, cerca prima un file webauthn
in https://{RP ID}/.well-known/webauthn
. Se il file esiste,
il browser controlla se l'origine che effettua la richiesta è inclusa nella lista consentita in quel
file. In questo caso, passa ai passaggi di creazione o autenticazione della passkey.
Se il browser non supporta le richieste di origine correlate, viene generato un errore SecurityError
.
Supporto browser
- Chrome: supportato a partire da Chrome 128.
- Safari: supportato a partire dalla versione beta 3 di macOS 15 e su dispositivi mobili dalla versione beta 3 di iOS 18.
- Firefox: In attesa di posizione.
Come configurare le richieste di origine correlate
La seguente demo utilizza l'esempio di due siti, https://ror-1.glitch.me
e https://ror-2.glitch.me
.
Per consentire agli utenti di accedere con la stessa passkey su entrambi i siti, utilizza le richieste di origine correlate per consentire a ror-2.glitch.me
di utilizzare ror-1.glitch.me
come ID RP.
Demo
https://ror-2.glitch.me implementa le richieste di origine correlate per utilizzare ror-1.glitch.me come ID RP, quindi sia ror-1
che ror-2
utilizzano ror-1.glitch.me
come ID RP quando creano una passkey o si autenticano con essa.
Abbiamo anche implementato un database di passkey condivise su questi siti.
Osserva la seguente esperienza utente:
- Puoi creare una passkey e autenticarti con essa su
ror-2
, anche se il suo ID RP èror-1
(e nonror-2
). - Dopo aver creato una passkey su
ror-1
oror-2
, puoi autenticarti sia suror-1
che suror-2
. Poichéror-2
specificaror-1
come ID RP, effettuare una richiesta di creazione o autenticazione della passkey da uno di questi siti equivale a effettuare la richiesta su ror-1. L'ID RP è l'unico elemento che lega una richiesta a un'origine. - Una volta creata una passkey su
ror-1
oror-2
, può essere compilata automaticamente da Chrome sia suror-1
sia suror-2
. - Una credenziale creata su uno di questi siti avrà un ID RP pari a
ror-1
.
Visualizza codice:
- Consulta il file
./well-known/webauthn
configurato nella base di codice ror-1. - Visualizza le occorrenze di
RP_ID_ROR
nel codice base di ror-2.
Passaggio 1: implementa un database dell'account condiviso
Se vuoi che i tuoi utenti possano accedere con la stessa passkey su site-1
e site-2
, implementa un database dell'account condiviso tra questi due siti.
Passaggio 2: configura il file JSON .well-known/webauthn nel sito 1
Per prima cosa, configura site-1.com
in modo che consenta a site-2.com
di utilizzarlo come ID RP. Per farlo, crea il file JSON webauthn:
{
"origins": [
"https://site-2.com"
]
}
L'oggetto JSON deve contenere una chiave denominata origins il cui valore è un array di una o più stringhe contenenti origini web.
Limitazione importante: massimo 5 etichette
Ogni elemento di questo elenco verrà elaborato per estrarre l'etichetta del dominio di primo livello più un sottodominio (eTLD+1).
Ad esempio, le etichette eTLD+1 di example.co.uk
e example.de
sono entrambe
example
. Tuttavia, l'etichetta eTLD+1 di example-rewards.com
è example-rewards
.
In Chrome, il numero massimo di etichette è 5.
Passaggio 3: pubblica il file JSON .well-known/webauthn nel sito 1
Poi, pubblica il file JSON in site-1.com/.well-known/webauthn
.
Ad esempio, in Express:
app.get("/.well-known/webauthn", (req, res) => {
const origins = {
origins: ["https://site-2.com"],
};
return res.json(origins);
});
Qui utilizziamo Express res.json
, che imposta già il valore corretto di content-type
('application/json'
).
Passaggio 4: specifica l'ID RP desiderato in site-2
Nel codice base site-2
, imposta site-1.com
come ID RP ovunque necessario:
- Al momento della creazione delle credenziali:
- Imposta
site-1.com
come ID RP nella creazione delle credenzialioptions
che vengono passate alla chiamatanavigator.credentials.create
frontend e in genere generate lato server. - Imposta
site-1.com
come ID RP previsto, mentre esegui le verifiche delle credenziali prima di salvarlo nel database.
- Imposta
- Al termine dell'autenticazione:
- Imposta
site-1.com
come ID RP nell'autenticazioneoptions
che vengono passati alla chiamata frontendnavigator.credentials.get
e tipicamente generati lato server. - Imposta
site-1.com
come ID RP previsto da verificare sul server, mentre esegui le verifiche delle credenziali prima di autenticare l'utente.
- Imposta
Risoluzione dei problemi
Altre considerazioni
Condividere le passkey su siti e app mobile
Le richieste di origine correlate consentono agli utenti di riutilizzare una passkey su più siti. Per consentire agli utenti di riutilizzare una passkey su un sito web e un'app mobile, utilizza le seguenti tecniche:
- In Chrome: Digital Asset Links. Scopri di più all'indirizzo Aggiungere il supporto per i link ai asset digitali.
- In Safari: Domini associati.
Condividere le password tra i siti
Le richieste di origine correlate consentono agli utenti di riutilizzare una passkey su più siti. Le soluzioni per condividere le password tra i siti variano in base al gestore delle password. Per Gestore delle password di Google, utilizza Link asset digitali . Safari ha un sistema diverso.
Ruolo dei gestori delle credenziali e degli agenti utente
Questo argomento va oltre il tuo ambito come sviluppatore del sito, ma tieni presente che, a lungo termine, l'ID RP non deve essere un concetto visibile all'utente nell'agente utente o nel gestore delle credenziali utilizzato dagli utenti. Gli agenti utente e i gestori delle credenziali devono invece mostrare agli utenti dove sono state utilizzate le loro credenziali. L'implementazione di questa modifica richiederà del tempo. Una soluzione temporanea potrebbe essere quella di mostrare sia il sito web attuale sia il sito di registrazione originale.