Consenti il riutilizzo delle passkey sui tuoi siti con richieste di origini correlate

Maud Nalpas

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 è specificato nell'ID relying party (RP ID), che per le passkey create per il dominio example.com potrebbe essere www.example.com o example.com.

Sebbene gli RP ID 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 a diversi domini specifici per paese (ad esempio example.com e example.co.uk) gestiti dalla stessa azienda.
• Domini brandizzati: gli utenti non possono utilizzare le stesse credenziali su domini diversi utilizzati da un singolo brand (ad esempio acme.com e acmerewards.com).
• App mobile: le app mobile spesso non hanno un proprio dominio, il che rende difficile la gestione delle credenziali.

Esistono soluzioni alternative basate sulla federazione delle identità e altre basate sugli iframe, ma in alcuni casi sono scomode. Le richieste di origine correlate offrono una soluzione.

Soluzione

Con richieste di origine correlate, un sito web può specificare le origini autorizzate a utilizzare il suo RP ID.

In questo modo, gli utenti possono riutilizzare la stessa passkey su più siti gestiti.

Per utilizzare le richieste di origine correlate, devi pubblicare un file JSON speciale a un URL specifico https://{RP ID}/.well-known/webauthn. Se example.com vuole consentire alle origini aggiuntive di utilizzarlo come RP ID, deve pubblicare il seguente 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 effettua una chiamata per la creazione di passkey (navigator.credentials.create) o l'autenticazione (navigator.credentials.get) che utilizza example.com come RP ID, il browser noterà un RP ID che non corrisponde all'origine richiedente. Se il browser supporta le richieste di origine correlate, cerca prima un file webauthn all'indirizzo https://{RP ID}/.well-known/webauthn. Se il file esiste, il browser verifica se l'origine che effettua la richiesta è presente nella allowlist. In caso affermativo, procede con i passaggi di creazione o autenticazione della passkey.

Se il browser non supporta le richieste di origine correlate, genera un SecurityError.

Supporto browser

Le richieste di origine correlate sono supportate su Chrome e Safari. A partire da gennaio 2026, Firefox sta ancora valutando la funzionalità. Puoi monitorare il suo stato nel problema relativo alla posizione degli standard Mozilla.

Configurare le richieste di origine correlate

La seguente demo utilizza 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 RP ID.

Demo

https://ror-2.glitch.me implementa le richieste di origine correlate per utilizzare ror-1.glitch.me come RP ID, quindi sia ror-1 che ror-2 utilizzano ror-1.glitch.me come RP ID durante la creazione di una passkey o l'autenticazione con essa. Abbiamo anche implementato un database di passkey condiviso su questi siti.

Osserva la seguente esperienza utente:

• Puoi creare una passkey e autenticarti con essa su ror-2, anche se il suo RP ID è ror-1 (e non ror-2).
• Dopo aver creato una passkey su ror-1 o ror-2, puoi autenticarti con essa sia su ror-1 che su ror-2. Poiché ror-2 specifica ror-1 come RP ID, effettuare una richiesta di creazione o autenticazione di una passkey da uno di questi siti equivale a effettuare la richiesta su ror-1. L'RP ID è l'unica cosa che lega una richiesta a un'origine.
• Dopo aver creato una passkey su ror-1 o ror-2, Chrome può compilarla automaticamente sia su ror-1 che su ror-2.
• Una credenziale creata su uno di questi siti avrà un RP ID di ror-1.

Visualizza il codice:

• Consulta il file /.well-known/webauthn configurato nella codebase ror-1.
• Consulta le occorrenze di RP_ID_ROR nella codebase ror-2.

Passaggio 1: implementare un database di account condiviso

Se vuoi che i tuoi utenti possano accedere con la stessa passkey su site-1 e site-2, implementa un database di account condiviso tra questi due siti.

Passaggio 2: configurare il file JSON .well-known/webauthn in site-1

Innanzitutto, configura site-1.com in modo che consenta a site-2.com di utilizzarlo come RP ID. Per farlo, crea il file JSON webauthn:

{
    "origins": [
        "https://site-2.com"
    ]
}

L'oggetto JSON deve contenere una chiave denominata origini 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 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: pubblicare il file JSON .well-known/webauthn in site-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, stiamo utilizzando express res.json, che imposta già il corretto content-type ('application/json');

Passaggio 4: specificare l'RP ID in site-2

Nella codebase site-2, imposta site-1.com come RP ID ovunque sia necessario:

• Al momento della creazione delle credenziali:
  • Imposta site-1.com come RP ID nella creazione delle credenziali options che vengono passate alla chiamata frontend navigator.credentials.create e in genere generate lato server.
  • Imposta site-1.com come RP ID previsto, mentre esegui le verifiche delle credenziali prima di salvarle nel database.
• Al momento dell'autenticazione:
  • Imposta site-1.com come RP ID nelle options di autenticazione passate alla chiamata frontend navigator.credentials.get e in genere generate lato server.
  • Imposta site-1.com come RP ID previsto da verificare sul server, mentre esegui le verifiche delle credenziali prima di autenticare l'utente.

Risoluzione dei problemi

Altre considerazioni

Condividere le passkey tra 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ù su Aggiungere il supporto per Digital Asset Links.
• 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 la condivisione delle password tra i siti variano a seconda dei gestori delle password. Per il Gestore delle password di Google, utilizza Digital Asset Links . Safari ha un sistema diverso.

Ruolo dei gestori delle credenziali e degli user agent

Questo va oltre il tuo ambito di sviluppatore di siti, ma tieni presente che a lungo termine l'RP ID non dovrebbe essere un concetto visibile all'utente nello user agent o nel gestore delle credenziali che utilizzano i tuoi utenti. Gli user agent e i gestori delle credenziali dovrebbero invece mostrare agli utenti dove sono state utilizzate le loro credenziali. L'implementazione di questa modifica richiederà tempo. Una soluzione temporanea consiste nel visualizzare sia il sito web attuale sia il sito di registrazione originale.