Origini Correlate WebAuthn: Guida alle Passkey Cross-Domain

Le passkey sono il nuovo standard per un'autenticazione sicura e intuitiva. Basate sugli standard FIDO/WebAuthn, sfruttano la crittografia a chiave pubblica per offrire una resistenza intrinseca al phishing e al credential stuffing, migliorando notevolmente la sicurezza e semplificando l'esperienza di login per gli utenti. Per le organizzazioni, questo si traduce in benefici aziendali tangibili: riduzione dei costi operativi legati al reset delle password e agli OTP via SMS, mitigazione dei rischi finanziari derivanti da frodi di account takeover e aumento dei ricavi grazie a tassi di conversione più elevati.

Tuttavia, uno dei maggiori punti di forza di WebAuthn in termini di sicurezza, la sua natura strettamente legata all'origine, crea una sfida significativa nel mondo reale per i brand globali e le aziende con un'impronta digitale diversificata. Per design, una passkey creata per un dominio web specifico è crittograficamente bloccata a quel dominio, un principio fondamentale che previene gli attacchi di phishing. Sebbene sia una potente funzionalità di sicurezza, porta a un'esperienza utente frammentata e confusa quando un singolo brand opera su più domini.

Un esempio lampante di questa sfida è il rebranding di Twitter in X. Un utente che aveva creato una passkey su twitter.com l'avrebbe trovata inutilizzabile su x.com, costringendo l'azienda a implementare reindirizzamenti macchinosi o a richiedere agli utenti di registrarsi di nuovo, creando un attrito che ostacola direttamente l'adozione. Questo non è un caso isolato. Grandi imprese come Amazon operano su numerosi domini di primo livello nazionali (ccTLD) come amazon.com, amazon.de e amazon.co.uk, tutti con lo stesso sistema di account utente. In un mondo pre-passkey, i gestori di password gestivano abilmente questa complessità, ma il comportamento predefinito di WebAuthn richiederebbe una passkey separata per ogni dominio, frustrando gli utenti e minando la promessa di un login senza interruzioni.

Per risolvere questo ostacolo critico all'adozione, il W3C ha introdotto una nuova funzionalità nello standard WebAuthn: le Related Origin Requests (ROR). Questo potente meccanismo fornisce un modo standardizzato e sicuro per consentire a un insieme di domini fidati di condividere una singola passkey, creando un'esperienza di autenticazione unificata e fluida nell'intero ecosistema digitale di un brand. Questo approfondimento esplora le basi tecniche delle ROR, fornisce una guida pratica alla loro implementazione e analizza le loro implicazioni strategiche per l'architettura di autenticazione moderna.

L'introduzione delle ROR segna una significativa maturazione dello standard WebAuthn. Le specifiche iniziali davano priorità alla definizione dei principi crittografici e di sicurezza fondamentali, con il legame stretto tra una credenziale e un ID di Relying Party (rpID) come caposaldo del suo design anti-phishing. Con l'avvento di implementazioni aziendali su larga scala da parte di aziende come Amazon e Google, l'attrito pratico causato da questa rigidità è diventato evidente. Questo attrito è un impedimento diretto al raggiungimento di un'elevata adozione da parte degli utenti, che è la misura definitiva del successo per qualsiasi progetto di passkey. Lo sviluppo delle ROR è una risposta diretta a questo feedback aziendale, dimostrando un'evoluzione pragmatica dello standard. Riconosce che, affinché un protocollo di sicurezza ottenga un successo diffuso, la sua usabilità deve adattarsi alle complesse realtà aziendali e alle strategie di branding delle organizzazioni che lo implementano.

Questa guida completa risponde a cinque domande cruciali per l'implementazione delle WebAuthn Related Origin Request:

1. Perché le passkey non funzionano su più domini? Comprendere il modello di sicurezza di WebAuthn legato all'origine e i suoi punti di attrito nel mondo reale
2. Come funzionano tecnicamente le Related Origin Request? Un'analisi approfondita del flusso di convalida del browser e del meccanismo URI .well-known
3. Cosa è necessario per implementare le ROR? Configurazione passo-passo lato server e client con esempi pratici di codice
4. Quando scegliere le ROR invece del login federato? Un quadro decisionale strategico che confronta le ROR con gli approcci OIDC/SAML
5. Come gestire la compatibilità dei browser e le considerazioni sulla sicurezza? Matrice di supporto attuale e best practice di sicurezza

Per ulteriori dettagli tecnici, consultare l'Explainer ufficiale delle WebAuthn Related Origin Request.

Per apprezzare appieno l'eleganza della soluzione delle Related Origin Request, è essenziale comprendere prima i concetti tecnici sottostanti che ne rendono necessaria l'esistenza: la Same-Origin Policy del web e le regole di scoping del Relying Party ID (rpID) di WebAuthn. Questi meccanismi sono fondamentali per la sicurezza web, ma creano proprio l'attrito che le ROR sono progettate per alleviare.

Un'"origine" web è un concetto di sicurezza critico definito dalla combinazione unica di protocollo (es. https), dominio (es. app.example.com) e porta (es. 443) da cui viene servito il contenuto. La Same-Origin Policy è un meccanismo di sicurezza applicato dai browser che limita il modo in cui uno script caricato da un'origine può interagire con una risorsa di un'altra. È un elemento importante della sicurezza web, che isola efficacemente documenti potenzialmente dannosi e impedisce a un sito web fraudolento, ad esempio, di leggere dati sensibili dalla sessione di webmail autenticata di un utente in un'altra scheda.

Nell'ecosistema WebAuthn, il "Relying Party" (RP) è il sito web o l'applicazione con cui un utente sta cercando di autenticarsi. Ogni passkey è crittograficamente legata a un Relying Party ID (rpID) al momento della sua creazione. L'rpID è un nome di dominio che definisce l'ambito e il confine di quella credenziale.

Per impostazione predefinita, l'rpID è il dominio effettivo dell'origine in cui viene creata la passkey. Le regole di scoping di WebAuthn consentono a un'origine di impostare un rpID che sia uguale al proprio dominio o a un suffisso di dominio registrabile. Ad esempio, uno script in esecuzione su https://www.accounts.example.co.uk può creare una passkey con un rpID di:

• www.accounts.example.co.uk (il dominio completo)
• accounts.example.co.uk
• example.co.uk

Questa flessibilità consente a una passkey creata su un sottodominio di essere utilizzata su altri sottodomini dello stesso dominio principale, il che è un modello comune e necessario. Tuttavia, le regole proibiscono severamente di impostare un rpID che non sia un suffisso. Lo stesso script su www.accounts.example.co.uk non potrebbe creare una passkey con un rpID di example.com, perché .com è un dominio di primo livello diverso.

Questo legame stretto serve a uno scopo importante: separare le credenziali per ambito di dominio. Una passkey creata per mybank.com non può essere utilizzata su phishing-site.com perché il sito dannoso non può rivendicare l'rpID legittimo di mybank.com. Il browser non presenterà nemmeno la passkey come opzione.

Tuttavia, l'rpID stesso non è il principale controllo anti-phishing. La protezione anti-phishing di WebAuthn deriva in realtà dalla verifica dell'origine nell'oggetto clientDataJSON. Durante ogni cerimonia WebAuthn, il browser crea un oggetto JSON contenente un contesto critico, inclusa l'esatta origine che ha avviato la richiesta. L'intero oggetto viene quindi firmato crittograficamente dalla chiave privata dell'autenticatore. Il server (Relying Party) DEVE verificare questa firma e, cosa cruciale, convalidare che il campo dell'origine nel clientDataJSON firmato corrisponda a un valore atteso e attendibile. Questa verifica dell'origine è ciò che previene gli attacchi di phishing.

Con le Related Origin Request, lo scoping dell'rpID viene allentato, consentendo a bar.com di rivendicare legittimamente l'rpID di foo.com dopo che il browser ha convalidato il file .well-known/webauthn, ma il requisito di verifica dell'origine rimane invariato. Il clientDataJSON riporterà comunque fedelmente l'origine come bar.com. Il server su foo.com riceve questi dati firmati, li verifica e vede che la richiesta proviene da bar.com. Il server deve quindi controllare che bar.com sia un'origine correlata attesa prima di accettare l'autenticazione. Questo dimostra un approccio a più livelli che consente una maggiore flessibilità senza sacrificare il principio fondamentale della verifica dell'origine.

Il meccanismo delle Related Origin Request introduce un modo elegante e standardizzato per i domini di dichiarare pubblicamente una relazione di fiducia allo scopo di condividere le passkey. Sfrutta un modello web consolidato — l'URI /.well-known/ — per creare una "allowlist" verificabile e leggibile automaticamente che i browser possono consultare.

Il concetto di base è semplice: un dominio che funge da rpID primario e canonico per un insieme di siti correlati può ospitare un file JSON speciale a un URL standardizzato e "well-known": https://{rpID}/.well-known/webauthn. Questo file funge da manifesto pubblico, elencando esplicitamente tutte le altre origini ufficialmente autorizzate a creare e utilizzare passkey con quell'rpID primario.

Il flusso di convalida del browser viene attivato ogni volta che incontra una mancata corrispondenza tra l'origine corrente e l'rpID richiesto:

1. Un utente su un sito "correlato", come https://example.co.uk, avvia un'operazione di passkey (creazione o autenticazione) in cui il codice lato client specifica un dominio diverso come rpID, ad esempio example.com.
2. Il browser rileva questa discrepanza. Con le vecchie regole, ciò comporterebbe immediatamente un SecurityError.
3. Con il supporto ROR, il browser, prima di fallire, effettua una richiesta HTTPS GET sicura all'URL well-known dell'rpID rivendicato: https://example.com/.well-known/webauthn. Questa richiesta viene effettuata senza credenziali utente (come i cookie) e senza un header referrer per proteggere la privacy dell'utente e prevenire il tracciamento.
4. Il browser riceve la risposta JSON dal server. Analizza il file e controlla se l'origine corrente (https://example.co.uk) è presente nell'array origins all'interno dell'oggetto JSON.
5. Se l'origine viene trovata nella allowlist, l'operazione WebAuthn può procedere utilizzando example.com come rpID valido. Se l'origine non viene trovata, o se il file è mancante o malformato, l'operazione fallisce come sarebbe successo in precedenza.

La scelta di utilizzare un URI /.well-known/ è deliberata e allinea le ROR con gli standard web consolidati per la scoperta di servizi e la convalida del controllo del dominio. Questo percorso URI, definito dalla RFC 8615, è già utilizzato da numerosi protocolli critici, tra cui l'acme-challenge per l'emissione di certificati SSL di Let's Encrypt e assetlinks.json per collegare i siti web alle applicazioni Android. Adottando questa convenzione, il W3C sfrutta un modello che implica intrinsecamente la proprietà del dominio. Per inserire un file in questo percorso specifico e standardizzato, è necessario avere il controllo amministrativo del server web per quel dominio. Ciò fornisce una prova di controllo semplice ma efficace, rendendo verificabile la dichiarazione di fiducia. Quando il proprietario di example.com serve un file che elenca example.co.uk come origine correlata, è un'affermazione verificabile. Questo approccio nativo del web è molto più semplice e robusto delle alternative considerate e respinte durante il processo di standardizzazione, come l'uso di chiavi crittografiche per firmare le autorizzazioni (RP Keys) o identificatori casuali non basati su dominio (RP UUIDs). Le ROR fondano la relazione di fiducia nel modello di controllo del dominio esistente e ben compreso del web.

L'implementazione delle Related Origin Request richiede modifiche coordinate sia lato server, per autorizzare le origini, sia lato client, per invocare l'rpID condiviso. Questa sezione fornisce i dettagli pratici di codice e configurazione necessari per abilitare un'esperienza passkey unificata sui tuoi domini.

Il server che ospita l'rpID primario è responsabile della pubblicazione della allowlist delle origini correlate.

Il file di autorizzazione deve essere posizionato nel percorso esatto /.well-known/webauthn relativo alla radice del dominio dell'rpID primario. È fondamentale che questo file sia servito alle seguenti condizioni:

• Protocollo: Deve essere servito su HTTPS.
• Content-Type: L'header della risposta HTTP Content-Type deve essere impostato su application/json.
• Estensione del file: L'URL non deve includere un'estensione .json. Il percorso corretto è /webauthn, non /webauthn.json.

Il file deve contenere un singolo oggetto JSON con una chiave, origins, il cui valore è un array di stringhe. Ogni stringa nell'array è l'origine completa (protocollo, dominio e porta opzionale) che viene autorizzata.

{
    "origins": ["https://example.co.uk", "https://example.de", "https://example.fr"]
}

Esempio: Per un rpID di example.com, il file deve essere servito su https://example.com/.well-known/webauthn (nota: nessuna estensione .json).

Una volta che il server è configurato con il file .well-known/webauthn, tutti i domini correlati devono utilizzare in modo coerente lo stesso rpID condiviso nelle loro chiamate API WebAuthn. Questo coordinamento è fondamentale per il corretto funzionamento delle ROR.

Requisiti chiave di coordinamento:

1. Responsabilità del backend: Il server genera la sfida crittografica e specifica l'rpID condiviso sia nelle richieste di creazione di credenziali che in quelle di autenticazione
2. Responsabilità del frontend: Tutte le applicazioni client (example.com, example.co.uk, example.de) devono passare lo stesso rpID condiviso all'API navigator.credentials del browser
3. Gestione della configurazione: L'rpID condiviso deve essere trattato come un valore di configurazione globale critico applicato in modo coerente su tutti i siti correlati

Una configurazione errata anche su un solo sito — dove si imposta come predefinita la propria origine come rpID invece del valore condiviso — interromperà l'esperienza passkey unificata per gli utenti su quel dominio.

Importante: Il server DEVE verificare il campo origin nel clientDataJSON per ogni richiesta, assicurandosi che corrisponda a una delle origini correlate autorizzate. Questa verifica dell'origine è il meccanismo primario di protezione dal phishing.

Le Related Origin Requests (ROR) e i protocolli di identità federata (OIDC/SAML) risolvono problemi diversi. Le ROR non sostituiscono il Single Sign-On, ma lo completano, affrontando un caso d'uso specifico e circoscritto.

Le ROR sono appropriate per una singola applicazione logica distribuita su più domini correlati che condividono lo stesso database utenti:

• Un unico brand che opera su più TLD nazionali (es. amazon.com, amazon.de, amazon.co.uk)
• Tutti i domini condividono lo stesso sistema di autenticazione backend e database utenti
• Si vogliono evitare flussi basati su reindirizzamento e mantenere l'autenticazione contestuale a ogni dominio
• I domini rientrano nel limite di 5 label
• Gli utenti dovrebbero percepire tutti i domini come un unico servizio coeso

Cosa offrono le ROR: La stessa passkey funziona su tutti i domini correlati, eliminando la necessità per gli utenti di creare passkey separate per ogni sito regionale.

Usare i protocolli di identità federata per un vero Single Sign-On tra applicazioni distinte:

• Servizi multipli con database utenti o sistemi di identità separati
• Scenari aziendali in cui gli utenti necessitano di accesso a molte applicazioni diverse (Salesforce, Office 365, strumenti interni)
• Integrazione con applicazioni di terze parti
• È necessario un controllo centralizzato degli accessi, percorsi di audit e governance dell'identità
• Si supera il limite di 5 label per le origini correlate

Cosa offrono OIDC/SAML: Un'autenticazione centralizzata in cui gli utenti effettuano il login una sola volta presso un Identity Provider (IdP) e ottengono l'accesso a più Service Provider (SP) tramite token sicuri.

Importante: Le passkey possono essere utilizzate con entrambi gli approcci. È possibile implementare le passkey presso un IdP centralizzato per un SSO federato, oppure utilizzare le ROR per una singola applicazione multi-dominio. La scelta deve basarsi sull'architettura, non sul metodo di autenticazione.

Sebbene le ROR siano una potente soluzione tecnica, la loro implementazione dovrebbe essere una decisione strategica ponderata. Architetti e product manager devono soppesare i benefici rispetto a modelli alternativi e comprenderne i limiti per costruire un sistema di autenticazione robusto e a prova di futuro.

Un vincolo chiave delle ROR è il "limite di label". Una "label" in questo contesto si riferisce al dominio di primo livello effettivo più un livello (eTLD+1), che è la parte registrabile di un nome di dominio. Ad esempio:

• shopping.com, shopping.co.uk e shopping.ca condividono tutti la singola label "shopping"
• myshoppingrewards.com introduce una nuova e distinta label: "myshoppingrewards"
• travel.shopping.com rientra ancora sotto la label "shopping"

La specifica WebAuthn Level 3 richiede che le implementazioni dei browser supportino un minimo di cinque label uniche nella lista origins. A partire dal 2025, nessun browser noto supporta più di questo minimo di cinque label. Pertanto, le organizzazioni dovrebbero progettare le loro implementazioni ROR tenendo presente questo limite rigido: considerare cinque come il massimo effettivo.

Questo limite è un meccanismo anti-abuso deliberato, progettato per prevenire un uso improprio. Impedisce a entità come i provider di hosting condiviso (es. wordpress.com) di creare una passkey universale che potrebbe funzionare su migliaia di sottodomini di clienti non correlati, il che minerebbe il modello di sicurezza.

Per la maggior parte delle organizzazioni, anche per i grandi brand multinazionali, questo limite di cinque label è sufficiente. Ad esempio, i vari TLD nazionali di Amazon (amazon.com, amazon.de, amazon.co.uk, ecc.) condividono tutti la label "amazon", lasciando disponibili quattro slot aggiuntivi per altri marchi del loro portafoglio come "audible" o "zappos".

La complessità dell'implementazione delle ROR dipende molto dal fatto che vengano introdotte in un sistema nuovo o adattate a uno esistente.

• Implementazioni Greenfield: Per i nuovi progetti, la strategia è semplice. Un singolo dominio canonico dovrebbe essere scelto come rpID condiviso fin dall'inizio (ad esempio, il dominio primario .com). Questo rpID dovrebbe poi essere utilizzato in modo coerente nella configurazione di tutti i siti web e le applicazioni correlate fin dal primo giorno.
• Implementazioni esistenti: Adattare le ROR a un sistema che ha già passkey distribuite con rpID diversi sui suoi domini è significativamente più complesso. Una migrazione diretta non è possibile, poiché le passkey esistenti sono permanentemente legate ai loro rpID originali. L'approccio raccomandato in questo scenario è implementare un flusso di login "identifier-first". All'utente viene prima chiesto di inserire il proprio username o email. Il backend esegue quindi una ricerca per determinare a quale rpID è associata la sua passkey esistente. Infine, l'utente viene reindirizzato all'origine corretta corrispondente a quell'rpID per completare la cerimonia di autenticazione. Dopo un login riuscito, può essere reindirizzato al suo sito originale. Si tratta di un'impresa architetturale considerevole che richiede un'attenta pianificazione e implementazione.

Comprendere come le aziende affermate implementano le Related Origin Request fornisce spunti preziosi per la propria strategia di implementazione. Di seguito sono riportati esempi basati su implementazioni reali (aggiornati a ottobre 2025):

Microsoft utilizza le ROR per la sua infrastruttura di autenticazione. La configurazione effettiva su login.microsoftonline.com include:

// https://login.microsoftonline.com/.well-known/webauthn
{
    "origins": ["https://login.microsoftonline.com", "https://login.live.com"]
}

Questo approccio conservativo consente la condivisione delle passkey tra i portali di login aziendali e consumer di Microsoft, mantenendo un perimetro di sicurezza mirato.

Shopify implementa le ROR per unificare l'autenticazione su domini selezionati:

// https://shopify.com/.well-known/webauthn
{
    "origins": ["https://shopify.com", "https://shop.app"]
}

Questa configurazione consente a Shopify di collegare la sua piattaforma principale con la sua app Shop, dimostrando un approccio mirato alle origini correlate.

Amazon ha un file piuttosto esteso:

// https://amazon.com/.well-known/webauthn
{
    "origins": [
        "https://www.amazon.com",
        "https://www.amazon.com.br",
        "https://www.amazon.com.mx",
        "https://www.amazon.ca",
        "https://www.amazon.co.uk",
        "https://www.amazon.de",
        "https://www.amazon.it",
        "https://www.amazon.es",
        "https://www.amazon.nl",
        "https://www.amazon.se",
        "https://www.amazon.sa",
        "https://www.amazon.pl",
        "https://www.amazon.com.tr",
        "https://www.amazon.fr",
        "https://www.amazon.com.au",
        "https://www.amazon.sg",
        "https://www.amazon.ae",
        "https://www.amazon.eg",
        "https://www.amazon.co.za",
        "https://www.amazon.in",
        "https://brandregistry.amazon.com",
        "https://sellercentral.amazon.com",
        "https://sellercentral.amazon.com.br",
        "https://sellercentral.amazon.com.mx",
        "https://sellercentral.amazon.ca",
        "https://sellercentral.amazon.co.uk",
        "https://sellercentral.amazon.de",
        "https://sellercentral.amazon.it",
        "https://sellercentral.amazon.es",
        "https://sellercentral.amazon.nl",
        "https://sellercentral.amazon.se",
        "https://sellercentral.amazon.sa",
        "https://sellercentral.amazon.pl",
        "https://sellercentral.amazon.com.tr",
        "https://sellercentral.amazon.fr",
        "https://sellercentral.amazon.com.au",
        "https://sellercentral.amazon.sg",
        "https://sellercentral.amazon.ae",
        "https://sellercentral.amazon.eg",
        "https://sellercentral.amazon.co.za",
        "https://sellercentral.amazon.in",
        "https://na.account.amazon.com",
        "https://vendorcentral.amazon.com",
        "https://vendorcentral.amazon.com.br",
        "https://vendorcentral.amazon.com.mx",
        "https://vendorcentral.amazon.ca",
        "https://vendorcentral.amazon.co.uk",
        "https://vendorcentral.amazon.de",
        "https://vendorcentral.amazon.it",
        "https://vendorcentral.amazon.es",
        "https://vendorcentral.amazon.nl",
        "https://vendorcentral.amazon.se",
        "https://vendorcentral.amazon.pl",
        "https://vendorcentral.amazon.com.tr",
        "https://vendorcentral.amazon.fr",
        "https://vendorcentral.amazon.com.au",
        "https://vendorcentral.amazon.co.za"
    ]
}

Questo modello consentirebbe a un brand di fornire un'autenticazione passkey unificata sui domini regionali utilizzando il dominio primario .com come rpID.

Questi esempi reali rivelano diversi modelli chiave:

1. Dominio primario come rpID: Tutte le aziende utilizzano il loro dominio primario .com come rpID canonico
2. Raggruppamento logico: Le origini sono raggruppate per funzione aziendale piuttosto che per architettura tecnica
3. Ambito conservativo: La maggior parte delle implementazioni rimane ben al di sotto del limite di 5 label, utilizzando tipicamente 3-4 origini
4. Strategia dei sottodomini: Molti utilizzano sottodomini del dominio primario per mantenere la coerenza del brand

Essendo uno standard web moderno, le ROR sono state progettate con la sicurezza come considerazione primaria e stanno vedendo un'adozione attiva da parte dei principali browser.

Le Related Origin Request non compromettono le garanzie anti-phishing fondamentali di WebAuthn. Il meccanismo è attentamente progettato per mantenere una solida postura di sicurezza:

• Verifica dell'origine: Come discusso, il browser include ancora la vera origine della richiesta nel clientDataJSON firmato. Il server del Relying Party DEVE verificare questa origine per garantire che la richiesta provenga da una fonte attesa, impedendo a un'origine correlata compromessa di impersonarne un'altra.
• Fetch sicuro: La richiesta del browser al file .well-known/webauthn viene effettuata tramite HTTPS. Inoltre, la specifica impone che questo fetch venga eseguito senza credenziali (es. cookie) e senza un header Referer. Ciò impedisce che la richiesta venga utilizzata per far trapelare informazioni sull'utente o per scopi di tracciamento cross-site.
• Sicurezza del server: Il file .well-known/webauthn stesso diventa un asset di sicurezza critico. Un utente malintenzionato che ottiene il controllo del server web che ospita l'rpID primario potrebbe potenzialmente modificare questo file per aggiungere il proprio dominio dannoso alla allowlist. Pertanto, la sicurezza dell'infrastruttura che serve questo file è di fondamentale importanza.

Le Related Origin Request sono una funzionalità della specifica WebAuthn Level 3. Il supporto dei browser ha iniziato a essere distribuito alla fine del 2024:

Fatti chiave:

• Chrome e Edge: Hanno aggiunto il supporto ROR nella versione 128 (agosto 2024)
• Safari: Ha aggiunto il supporto ROR in Safari 18, disponibile su macOS 15 e iOS 18 (settembre 2024)
• Firefox: Attualmente non supporta le ROR; è necessario rilevare la funzionalità e implementare flussi di fallback

Per le applicazioni che devono supportare browser più vecchi o Firefox, è necessario implementare una strategia di fallback:

1. Rilevamento della funzionalità: Verificare il supporto ROR utilizzando PublicKeyCredential.getClientCapabilities()
2. Flusso identifier-first: Richiedere username/email, cercare l'rpID associato all'utente, quindi reindirizzare all'origine appropriata per l'autenticazione
3. Degradazione graduale: Consentire agli utenti di creare passkey separate per dominio se le ROR non sono disponibili

Dati basati sulle matrici di supporto attuali a ottobre 2025.

L'implementazione delle Related Origin Request richiede un'attenta coordinazione tra più team tecnici e una profonda esperienza nei protocolli WebAuthn. La piattaforma di adozione delle passkey di Corbado elimina questa complessità fornendo soluzioni enterprise-ready per implementazioni di passkey multi-dominio.

Corbado gestisce la complessità tecnica delle Related Origin Request attraverso:

• Configurazione automatizzata: La nostra piattaforma genera e ospita automaticamente i file .well-known/webauthn richiesti con gli header di sicurezza e la formattazione JSON corretti
• Dashboard multi-dominio: Interfaccia di gestione centralizzata per la configurazione delle origini correlate su tutto il tuo portafoglio di domini
• Strumenti di convalida: Test e convalida integrati per garantire che la tua configurazione ROR funzioni correttamente su tutti i browser e le piattaforme

Oltre all'implementazione tecnica, Corbado fornisce il framework di sicurezza di cui le aziende hanno bisogno:

• Verifica dell'origine: Convalida automatica delle origini clientDataJSON per prevenire abusi sui domini correlati
• Log di audit: Tracciamento completo dell'utilizzo delle passkey su tutti i domini correlati per il monitoraggio della sicurezza e della conformità
• Risposta agli incidenti: Avvisi in tempo reale e risposte automatizzate per tentativi sospetti di autenticazione cross-domain

Per le organizzazioni con implementazioni di passkey esistenti, Corbado offre:

• Strumenti di migrazione legacy: Analisi automatizzata delle configurazioni rpID esistenti e raccomandazioni sul percorso di migrazione
• Flussi identifier-first: Componenti di login pre-costruiti che gestiscono scenari complessi multi-rpID durante i periodi di transizione
• Integrazione API: API RESTful e SDK che si integrano perfettamente con la tua infrastruttura di autenticazione esistente

Pronto a implementare le Related Origin Request per la tua organizzazione? Il team di esperti di Corbado può aiutarti a progettare e distribuire un'esperienza passkey unificata su tutto il tuo ecosistema digitale. Contatta il nostro team di soluzioni per discutere le tue esigenze specifiche e le tempistiche.

La promessa delle passkey risiede nella loro capacità di offrire un futuro che sia allo stesso tempo più sicuro e notevolmente più semplice per gli utenti. Tuttavia, affinché questo futuro diventi realtà su scala globale, lo standard deve adattarsi alle complessità architettoniche dei brand digitali moderni. L'attrito creato da passkey strettamente legate al dominio è stato un ostacolo significativo all'adozione per le organizzazioni con presenze online multi-sfaccettate.

Le WebAuthn Related Origin Request forniscono la soluzione standardizzata, sicura ed elegante a questo problema. Consentendo a una singola passkey di funzionare senza problemi su un insieme fidato di domini correlati, le ROR eliminano un importante punto di confusione e frustrazione per l'utente.

Questa guida ha affrontato cinque domande cruciali per l'implementazione delle WebAuthn Related Origin Request:

1. Perché le passkey non funzionano su più domini? Il modello di sicurezza di WebAuthn, legato all'origine, blocca crittograficamente le passkey a domini specifici per prevenire il phishing, ma questo crea attrito quando i brand operano su più domini come diversi TLD nazionali.
2. Come funzionano tecnicamente le Related Origin Request? Le ROR utilizzano un file standardizzato .well-known/webauthn per creare una allowlist verificabile di domini correlati, consentendo ai browser di convalidare l'uso di passkey cross-domain attraverso un processo di fetch HTTPS sicuro.
3. Cosa è necessario per implementare le ROR? L'implementazione richiede la configurazione lato server del file manifest .well-known/webauthn e il coordinamento lato client per utilizzare un rpID condiviso in modo coerente su tutte le origini correlate.
4. Quando scegliere le ROR invece del login federato? Usare le ROR per esperienze di brand unificate su domini correlati con database utenti condivisi; usare OIDC/SAML per un vero SSO tra applicazioni distinte o quando si supera il limite di 5 label.
5. Come gestire la compatibilità dei browser e le considerazioni sulla sicurezza? Le ROR sono supportate nei principali browser da Chrome/Firefox 128+, Safari su macOS 15+ e iOS 18+, con strategie di fallback disponibili per i browser più vecchi tramite flussi identifier-first.

Per i team tecnici e i product leader, i punti essenziali sono:

• Le ROR consentono un'esperienza passkey unificata per una singola applicazione logica distribuita su più domini, come quelli con diversi TLD nazionali o branding alternativi.
• L'implementazione richiede uno sforzo coordinato: un file .well-known/webauthn lato server deve essere pubblicato sul dominio dell'rpID primario e tutte le applicazioni lato client devono essere configurate per utilizzare lo stesso rpID condiviso.
• La decisione di utilizzare le ROR è strategica. È uno strumento eccellente per i suoi casi d'uso specifici, ma dovrebbe essere valutato rispetto a un'architettura di login federato più tradizionale (OIDC/SAML), specialmente in scenari che coinvolgono un vero Single Sign-On tra applicazioni disparate.

Funzionalità come le Related Origin Request sono vitali per il continuo slancio del movimento passwordless. Dimostrano un impegno da parte degli organismi di standardizzazione nell'affrontare le sfide di implementazione del mondo reale, garantendo che i benefici delle passkey — sicurezza senza pari e un'esperienza utente senza sforzo — siano accessibili anche alle organizzazioni più grandi e complesse. Man mano che questa funzionalità otterrà un supporto universale da parte dei browser, svolgerà un ruolo cruciale nell'abbattere le ultime barriere verso un internet veramente globale e senza password.