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

Maud Nalpas

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 e example.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 e acmerewards.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. Le richieste di origine correlate rappresentano una soluzione.

Nota: gli ID delle parti soggette a limitazioni separano le credenziali tra diversi siti web, ma il phishing deriva in realtà dalla verifica dell'origine del sito web nel campo CollectedClientData.

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 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 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 origine correlate, viene generato un errore 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.

di Gemini Advanced.

Avviso :a partire da agosto 2024, le richieste di origini correlate non sono supportate in Firefox e getClientCapabilities non è ancora disponibile per rilevare la funzionalità mancante e implementare un di riserva. Se implementi le richieste di origine correlata, gli utenti Firefox non potranno creare Una passkey (o esegui l'accesso con questa) sui domini che intendono usare un altro sito come verranno visualizzati un ID RP e un SecurityError.

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

Nota: apri la demo in uno dei browser supportati.

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 condivise su questi siti.

Osserva la seguente esperienza utente:

• Puoi creare una passkey e autenticarti con essa su ror-2, anche se il relativo ID RP è ror-1 (e non ror-2).
• Dopo aver creato una passkey su ror-1 o ror-2, puoi autenticarla sia su ror-1 sia su ror-2. Poiché ror-2 specifica ror-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.
• Una volta creata una passkey su ror-1 o ror-2, può essere compilata automaticamente da Chrome sia su ror-1 sia su ror-2.
• Una credenziale creata su uno di questi siti avrà un ID RP pari a ror-1.

di Gemini Advanced.

Grazie alle richieste con origine correlata, gli utenti possono usare la stessa credenziale passkey sui protocolli ror-1 e ror-2. Inoltre, Chrome compilerà automaticamente le credenziali.

Visualizza il codice:

• Controlla il file ./well-known/webauthn configurato nel codebase ror-1.
• Visualizza RP_ID_ROR occorrenze nel codebase ror-2.

Nota: in questa demo, per semplicità, non viene eseguito alcun controllo della password sotto il cofano. La demo è incentrata sulle passkey.

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 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, le etichette eTLD+1 di example.co.uk e example.de sono entrambeexample. Tuttavia, l'eTLD + 1 etichetta di example-rewards.com è example-rewards. In Chrome, il numero massimo di etichette è 5.

Avviso: se l'elenco include troppe etichette (più di 5), gli elementi in eccesso verranno ignorati.

Passaggio 3: pubblica il file JSON .well-known/webauthn in site-1

Quindi, pubblica il file JSON in site-1.com/.well-known/webauthn.

Attenzione: il file deve essere pubblicato con un tipo di contenuto application/json e deve contenere un singolo oggetto JSON che elenca le origini consentite. Il formato corretto del file è: /.well-known/webauthn (non includere l'estensione .json).

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 credenziali options che vengono passate a navigator.credentials.create chiamata frontend e di solito generati lato server.
  • Imposta site-1.com come ID RP previsto, mentre esegui le verifiche delle credenziali prima di salvarlo nel database.
• Dopo l'autenticazione:
  • Imposta site-1.com come ID parte soggetta a limitazioni nell'autenticazione options passate alla chiamata di frontend navigator.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.

di Gemini Advanced.

Nota: cosa succede con origin? E la parte soggetta a limitazioni name? Nel codebase site-2, il valore origin previsto dovrebbe rimanere invariato (https://site-2.com), perché indica dove è prevista la richiesta da cui provengono. Il nome RP (rp.name) non viene utilizzato in pratica. Puoi lasciarlo vuoto.

Risoluzione dei problemi

Messaggio di errore in Chrome al momento della creazione delle credenziali. Questo errore viene generato se non è possibile trovare il file ".well-known/webauthn" all'indirizzo "https://{RP ID}/.well-known/webauthn".

di Gemini Advanced.

.

Messaggio di errore in Chrome al momento della creazione delle credenziali. Questo errore viene visualizzato se è possibile trovare il file ".well-known/webauthn", ma non viene indicata l'origine da cui stai tentando di creare la credenziale.

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 origine correlate consentono agli utenti di riutilizzare una passkey su più 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 dei gestori delle credenziali e degli agenti utente

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 potrebbe essere quella di mostrare sito web attuale e quello originale di registrazione.