--- url: 'https://www.corbado.com/it/blog/webauthn-origini-correlate-passkey-cross-domain' title: 'Origini Correlate WebAuthn: Guida alle Passkey Cross-Domain' description: 'Scopri come le Related Origin Request di WebAuthn abilitano le passkey su più domini. Guida completa all''implementazione con esempi pratici.' lang: 'it' author: 'Vincent Delitz' date: '2025-10-31T14:41:12.679Z' lastModified: '2026-03-25T10:06:01.854Z' keywords: 'origini correlate, webauthn origini correlate, related origin request, passkey cross-domain, .well-known/webauthn, ROR' category: 'WebAuthn Know-How' --- # Origini Correlate WebAuthn: Guida alle Passkey Cross-Domain ## 1. Introduzione: Abbattere i confini digitali per le passkey Le passkey sono il nuovo standard per un'[autenticazione](https://www.corbado.com/it/blog/come-passare-autenticazione-completamente-passwordless) sicura e intuitiva. Basate sugli standard FIDO/WebAuthn, sfruttano la crittografia a chiave pubblica per offrire una resistenza intrinseca al [phishing](https://www.corbado.com/glossary/phishing) e al [credential stuffing](https://www.corbado.com/glossary/credential-stuffing), migliorando notevolmente la [sicurezza](https://www.corbado.com/it/blog/come-abilitare-passkey-su-android) 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](https://www.corbado.com/it/blog/come-abilitare-passkey-su-android), 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](https://www.corbado.com/glossary/phishing). Sebbene sia una potente funzionalità di [sicurezza](https://www.corbado.com/it/blog/come-abilitare-passkey-su-android), 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](https://www.corbado.com/blog/x-twitter-passkeys) in X. Un utente che aveva creato una passkey su [twitter](https://www.corbado.com/blog/x-twitter-passkeys).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](https://developer.chrome.com/blog/passkeys-updates-chrome-129) per consentire a un insieme di domini fidati di condividere una singola passkey, creando un'esperienza di [autenticazione](https://www.corbado.com/it/blog/come-passare-autenticazione-completamente-passwordless) unificata e fluida nell'intero ecosistema digitale di un brand. Questo approfondimento esplora le basi tecniche delle [ROR](https://www.corbado.com/blog/webauthn-related-origins-cross-domain-passkeys), fornisce una guida pratica alla loro implementazione e analizza le loro implicazioni strategiche per l'architettura di [autenticazione](https://www.corbado.com/it/blog/come-passare-autenticazione-completamente-passwordless) moderna. L'introduzione delle [ROR](https://www.corbado.com/blog/webauthn-related-origins-cross-domain-passkeys) segna una significativa maturazione dello standard WebAuthn. Le specifiche iniziali davano priorità alla definizione dei [principi crittografici e di sicurezza fondamentali](https://www.w3.org/TR/webauthn-3/), con il legame stretto tra una credenziale e un ID di [Relying Party](https://www.corbado.com/glossary/relying-party) (rpID) come caposaldo del suo design anti-[phishing](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/webauthn-related-origins-cross-domain-passkeys) è 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](https://www.corbado.com/blog/webauthn-related-origins-cross-domain-passkeys) 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](https://github.com/w3c/webauthn/wiki/Explainer:-Related-origin-requests). ## 2. Il problema di fondo: Relying Party ID e Origin Scoping di WebAuthn Per apprezzare appieno l'eleganza della soluzione delle [Related Origin Request](https://www.corbado.com/blog/webauthn-related-origins-cross-domain-passkeys), è 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](https://www.corbado.com/glossary/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. ### 2.1 Origine web e Same-Origin Policy 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**](https://developer.mozilla.org/en-US/docs/Web/Security/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. ### 2.2 Relying Party ID (rpID) Nell'ecosistema WebAuthn, il "[Relying Party](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/webauthn-related-origins-cross-domain-passkeys), 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](https://www.corbado.com/glossary/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. ## 3. La soluzione: come funzionano le Related Origin Request Il meccanismo delle [Related Origin Request](https://www.corbado.com/blog/webauthn-related-origins-cross-domain-passkeys) 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](https://www.corbado.com/blog/webauthn-errors). 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](https://www.corbado.com/blog/how-to-enable-passkeys-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. ## 4. Guida pratica all'implementazione delle origini correlate 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. ### 4.1 Lato server: Autorizzare le origini con .well-known/webauthn Il server che ospita l'rpID primario è responsabile della pubblicazione della allowlist delle origini correlate. #### 4.1.1 Posizione e formato del file 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`. #### 4.1.2 Struttura 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. ```json { "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`). ### 4.2 Lato client: Invocare un rpID condiviso 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](https://www.corbado.com/glossary/clientdatajson) per ogni richiesta, assicurandosi che corrisponda a una delle origini correlate autorizzate. Questa verifica dell'origine è il meccanismo primario di protezione dal phishing. ## 5. Raccomandazione: scegliere ROR per esperienze di brand unificate, OIDC per un vero SSO **Le Related Origin Requests (ROR) e i protocolli di identità federata (OIDC/SAML) risolvono problemi diversi.** Le ROR non sostituiscono il [Single Sign-On](https://www.corbado.com/blog/passkeys-single-sign-on-sso), ma lo completano, affrontando un caso d'uso specifico e circoscritto. ### 5.1 Quando usare le Related Origin Request 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. ### 5.2 Quando usare il Federated Login (OIDC/SAML) 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](https://www.corbado.com/blog/passkeys-single-sign-on-sso) federato, oppure utilizzare le ROR per una singola applicazione multi-dominio. La scelta deve basarsi sull'architettura, non sul metodo di autenticazione. ## 6. Considerazioni strategiche per l'architettura delle passkey 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. ### 6.1 Comprendere il limite di 5 label 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](https://www.corbado.com/it/blog/migliori-pratiche-creazione-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". ### 6.2 Strategie di implementazione: Greenfield vs. Sistemi esistenti 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. ## 7. Esempi pratici: come i grandi brand implementano le origini correlate 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): ### 7.1 L'implementazione di Microsoft Microsoft utilizza le ROR per la sua [infrastruttura](https://www.corbado.com/passkeys-for-critical-infrastructure) di autenticazione. La configurazione effettiva su `login.microsoftonline.com` include: ```json // 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. ### 7.2 L'implementazione di Shopify [Shopify](https://www.corbado.com/blog/shopify-passkeys) implementa le ROR per unificare l'autenticazione su domini selezionati: ```json // https://shopify.com/.well-known/webauthn { "origins": ["https://shopify.com", "https://shop.app"] } ``` Questa configurazione consente a [Shopify](https://www.corbado.com/blog/shopify-passkeys) di collegare la sua piattaforma principale con la sua app Shop, dimostrando un approccio mirato alle origini correlate. ### 7.3 L'implementazione di Amazon Amazon ha un file piuttosto esteso: ```json // 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](https://www.corbado.com/it/blog/provider-passkey) unificata sui domini regionali utilizzando il dominio primario `.com` come rpID. ### 7.4 Modelli di implementazione e best practice 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 ## 8. Supporto dei browser e considerazioni sulla sicurezza 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. ### 8.1 Modello di sicurezza 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](https://www.corbado.com/passkeys-for-critical-infrastructure) che serve questo file è di fondamentale importanza. ### 8.2 Supporto di browser e piattaforme Le Related Origin Request sono una funzionalità della specifica [WebAuthn Level 3](https://www.corbado.com/blog/passkeys-prf-webauthn). Il supporto dei browser ha iniziato a essere distribuito alla fine del 2024: | **Sistema Operativo** | **Browser / Piattaforma** | **Supporto Versione** | **Stato** | | --------------------- | ------------------------- | --------------------- | ----------------- | | Android | Chrome, Edge | 128+ | ✅ Supportato | | Chrome OS | Chrome, Edge | 128+ | ✅ Supportato | | iOS / iPadOS | Tutti i browser (Safari) | iOS 18+ | ✅ Supportato | | macOS | Chrome, Edge | 128+ | ✅ Supportato | | macOS | Safari | Safari 18 (macOS 15+) | ✅ Supportato | | Ubuntu | Chrome, Edge | 128+ | ✅ Supportato | | Windows | Chrome, Edge | 128+ | ✅ Supportato | | Tutte le piattaforme | Firefox | Non supportato | ⚠️ Usare fallback | **Fatti chiave:** - **Chrome e Edge:** Hanno aggiunto il supporto ROR nella versione 128 (agosto 2024) - **Safari:** Ha aggiunto il supporto ROR in [Safari 18](https://www.corbado.com/blog/ios-18-passkeys-automatic-passkey-upgrades), disponibile su macOS 15 e [iOS 18](https://www.corbado.com/blog/ios-18-passkeys-automatic-passkey-upgrades) (settembre 2024) - **Firefox:** Attualmente non supporta le ROR; è necessario rilevare la funzionalità e implementare flussi di fallback ### Rilevamento della funzionalità e 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. ## 9. Come Corbado può aiutare 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. ### 9.1 Implementazione ROR semplificata 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 ### 9.2 Sicurezza e conformità di livello enterprise 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 ### 9.3 Supporto alla migrazione e all'integrazione 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](https://www.corbado.com/passkeys-for-critical-infrastructure) di autenticazione esistente ### 9.4 Per iniziare 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](https://www.corbado.com/contact) per discutere le tue esigenze specifiche e le tempistiche. ## 10. Conclusione: Un futuro senza interruzioni per le passkey multi-dominio 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](https://www.corbado.com/blog/webauthn-related-origins-cross-domain-passkeys) 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](https://www.corbado.com/blog/passkeys-single-sign-on-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](https://www.corbado.com/blog/ios-18-passkeys-automatic-passkey-upgrades)+, con strategie di fallback disponibili per i browser più vecchi tramite flussi identifier-first. ### Punti chiave 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](https://www.corbado.com/blog/passkeys-single-sign-on-sso) tra applicazioni disparate. Funzionalità come le Related Origin Request sono vitali per il continuo slancio del movimento [passwordless](https://www.corbado.com/it/blog/come-passare-autenticazione-completamente-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.