Il problema relativo alle richieste di origini correlate
Le passkey sono legate a un sito web specifico e possono essere utilizzate solo per accedere al sito web per cui sono state create.
Questo valore è specificato nella parte base
ID (ID parte soggetta a limitazioni), che per le passkey create per il dominio example.com potrebbe essere www.example.com
o example.com
.
Mentre gli ID parte soggetta a limitazioni impediscono alle passkey di essere utilizzate come singola credenziale per con l'autenticazione ovunque, creano problemi per:
- Siti con più domini: gli utenti non possono utilizzare la stessa passkey per
accedere a diversi domini specifici del paese (ad esempio,
example.com
eexample.co.uk
) gestiti dalla stessa azienda. - Domini con brand: gli utenti non possono utilizzare le stesse credenziali su
diversi domini utilizzati da un singolo brand (ad esempio
acme.com
eacmerewards.com
). - App mobile: le app mobile spesso non hanno un dominio proprio, il che rende della gestione delle credenziali.
Esistono soluzioni alternative basate sulla federazione delle identità e altre basate ma in alcuni casi scomodi. Offerta Richieste di origini correlate per trovare una soluzione.
Soluzione
Con Richieste di origini correlate, un sito web può specificare le origini autorizzate a utilizzare il proprio ID parte soggetta a limitazioni.
In questo modo, gli utenti possono riutilizzare la stessa passkey su più siti che gestisci.
Per utilizzare le richieste di origine correlata, devi pubblicare un file JSON speciale in un
l'URL specifico https://{RP ID}/.well-known/webauthn
. Se example.com
vuole
consentire alle origini aggiuntive di usarlo come ID parte soggetta a limitazioni, dovrebbe pubblicare quanto segue
file all'indirizzo https://example.com/.well-known/webauthn:
{
"origins": [
"https://example.co.uk",
"https://example.de",
"https://example-rewards.com"
]
}
La prossima volta che uno di questi siti effettuerà una chiamata per creare una passkey
(navigator.credentials.create
) o autenticazione (navigator.credentials.get
)
che utilizza example.com
come ID parte soggetta a limitazioni, il browser noterà un ID parte soggetta a limitazioni che
non corrisponde all'origine richiedente. Se il browser supporta l'origine correlata
delle richieste, prima cerca una
webauthn
file all'indirizzo 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 questo caso, si passa alla procedura di creazione o autenticazione della passkey.
Se il browser non supporta le richieste di origini correlate, genera un SecurityError
.
Supporto browser
- Chrome: supportato a partire da Chrome 128.
- Safari: supportato a partire da macOS 15 beta 3 e su dispositivi mobili iOS 18 beta 3.
- Firefox: In attesa di posizione.
Come configurare le richieste di origini correlate
La demo seguente 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 usare ror-1.glitch.me
come ID della parte soggetta a limitazioni.
Demo
https://ror-2.glitch.me implementa le richieste di origine correlata per utilizzare ror-1.glitch.me come ID RP, quindi sia ror-1
sia ror-2
usano ror-1.glitch.me
come ID della parte soggetta a limitazioni al momento della creazione di una passkey o dell'autenticazione tramite questa.
Abbiamo anche implementato un database di passkey condiviso su questi siti.
Osserva la seguente esperienza utente:
- Puoi creare una passkey ed eseguire l'autenticazione con la passkey su
ror-2
, anche se il suo ID parte soggetta a limitazioni èror-1
(e nonror-2
). - Dopo aver creato una passkey su
ror-1
oror-2
, puoi autenticarla sia suror-1
sia suror-2
. Poichéror-2
specificaror-1
come ID della parte soggetta a limitazioni, effettuare una richiesta di creazione o autenticazione di una passkey da uno di questi siti è come effettuare la richiesta su ror-1. L'ID della parte soggetta a limitazioni è l'unica cosa che collega una richiesta a un'origine. - Dopo aver creato 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 parte soggetta a limitazioni pari a
ror-1
.
![Chrome esegue la compilazione automatica su entrambi i siti.](https://web.developers.google.cn/static/articles/webauthn-related-origin-requests/image/chrome-autofill.jpg?hl=it)
Visualizza il codice:
- Controlla il file
./well-known/webauthn
configurato nel codebase ror-1. - Visualizza le occorrenze di
RP_ID_ROR
nel codebase ror-2.
Passaggio 1: implementa un database di account condiviso
Se vuoi che i tuoi utenti possano accedere con la stessa passkey su
site-1
e site-2
, implementano un database dell'account condiviso tra questi
due siti.
Passaggio 2: configura il file JSON .well-known/webauthn in site-1
Innanzitutto, configura site-1.com
in modo che consenta a site-2.com
di usarlo come
ID parte soggetta a limitazioni. Per farlo, crea il tuo file JSON webauthn:
{
"origins": [
"https://site-2.com"
]
}
L'oggetto JSON deve contenere origini con nome chiave il cui valore sia un array di uno o più stringhe contenenti origini web.
Limitazione importante: massimo 5 etichette
Ogni elemento di questo elenco verrà elaborato per estrarre l'eTLD + 1 etichetta.
Ad esempio, l'eTLD + 1 etichette di example.co.uk
e example.de
sono entrambi
example
. Tuttavia, l'eTLD + 1 etichetta di example-rewards.com
è example-rewards
.
In Chrome, il numero massimo di etichette è 5.
Passaggio 3: pubblica il file JSON .well-known/webauthn in site-1
Quindi, pubblica il file JSON in site-1.com/.well-known/webauthn
.
Ad esempio, nel formato espresso:
app.get("/.well-known/webauthn", (req, res) => {
const origins = {
origins: ["https://site-2.com"],
};
return res.json(origins);
});
In questo caso utilizziamo il formato espresso res.json
, che imposta già
corretto content-type
('application/json'
);
Passaggio 4: specifica l'ID parte soggetta a limitazioni desiderato nel sito-2
Nel tuo codebase site-2
, imposta site-1.com
come ID parte soggetta a limitazioni ovunque necessario:
- Al momento della creazione delle credenziali:
- Imposta
site-1.com
come ID parte soggetta a limitazioni nella creazione delle credenzialioptions
che vengono passate anavigator.credentials.create
chiamata frontend e di solito generati lato server. - Imposta
site-1.com
come ID parte soggetta a limitazioni previsto, quando esegui la credenziale verifiche prima di salvarlo nel database.
- Imposta
- Dopo l'autenticazione:
- Imposta
site-1.com
come ID parte soggetta a limitazioni nell'autenticazioneoptions
passate alla chiamata di frontendnavigator.credentials.get
è generato generalmente lato server. - Imposta
site-1.com
come ID parte soggetta a limitazioni da verificare nella se esegui le verifiche delle credenziali prima di autenticare l'utente.
- Imposta
Risoluzione dei problemi
![Popup del messaggio di errore in Chrome.](https://web.developers.google.cn/static/articles/webauthn-related-origin-requests/image/error-file-not-found.jpg?hl=it)
![Popup del messaggio di errore in Chrome.](https://web.developers.google.cn/static/articles/webauthn-related-origin-requests/image/error-file-incorrect.jpg?hl=it)
Altre considerazioni
Condividi le passkey tra siti e app mobile
Le richieste di origini correlate consentono agli utenti di riutilizzare una passkey per più siti. Per consentire agli utenti di riutilizzare una passkey su un sito web e un'app mobile: utilizzare le seguenti tecniche:
- In Chrome: Asset digitale Link. Scopri di più all'indirizzo Aggiunta del supporto per Digital Asset Links.
- In Safari: Domini associati.
Condividere le password tra i siti
Le richieste di origini correlate consentono agli utenti di riutilizzare una passkey tra i siti. Le soluzioni per la condivisione delle password tra siti variano a seconda del gestore delle password. Per Gestore delle password di Google, usa Digital Asset Links . Safari ha un altro sistema.
Ruolo di gestori delle credenziali e user agent
Questo va oltre il tuo ambito come sviluppatore di siti, ma tieni presente che nei l'ID parte soggetta a limitazioni non deve essere un concetto visibile all'utente nello user agent o il gestore delle credenziali utilizzato dai tuoi utenti. Al contrario, user agent e credenziali i gestori devono mostrare agli utenti dove sono state utilizzate le loro credenziali. Questa modifica l'implementazione richiederà del tempo. Una soluzione temporanea consisterebbe nel visualizzare sia sito web attuale e quello originale di registrazione.