Defragmentare gli accessi interdominio

Eiji Kitamura

Le moderne architetture aziendali spesso si estendono su più domini distinti. Le organizzazioni mantengono ambienti dedicati per varie funzionalità, ad esempio brand.example per il marketing, service-app.example per il prodotto principale e support-portal.example per l'assistenza clienti. Idealmente, vuoi offrire un'esperienza di accesso Single Sign-On unificata quando gli utenti navigano tra queste proprietà. Tuttavia, i team di engineering spesso integrano questi domini utilizzando tecniche ad hoc che causano la frammentazione. Ciò interrompe la gestione delle credenziali integrate del browser interrompendo i flussi di compilazione automatica del gestore delle password e bloccando l'adozione delle passkey.

Se lo stesso account si estende su più domini, l'utente deve riconoscere che i domini appartengono alla stessa organizzazione e fornire le stesse credenziali quando esegue l'accesso. Nel peggiore dei casi, l'utente crea un account duplicato o fornisce la password a un sito web di phishing.

Scopri come utilizzare standard e soluzioni architetturali (come metadati, iframe multiorigine, federazione delle identità e consolidamento dei sottodomini) per risolvere la frammentazione dell'identità interdominio e offrire un percorso utente senza interruzioni.

Soluzioni alternative comuni

Le organizzazioni utilizzano diverse tecniche consolidate per mantenere un percorso interdominio. Sebbene questi metodi siano comuni, presentano ostacoli strutturali in quanto i browser applicano limiti di privacy e standard di sicurezza più rigorosi.

Richieste di recupero CORS

Quando i domini operano in modo indipendente, i frontend spesso si basano su richieste multiorigine fetch() indirizzate a un'API di autenticazione centralizzata, che può essere consentita in modo sicuro utilizzando la condivisione delle risorse tra origini (CORS). Poiché i browser spesso bloccano o limitano i cookie tra siti, gli sviluppatori possono progettare esplicitamente queste API per restituire token di autenticazione, come i token web JSON (JWT) all'interno dei payload JSON anziché basarsi sulle intestazioni Set-Cookie.

Condivisione del database degli account

Per unificare l'identità nel backend senza integrazioni frontend complesse, puoi centralizzare il datastore utente. Sebbene più domini eseguano l'autenticazione rispetto allo stesso database, le esperienze di accesso frontend rimangono separate. In questo modo, gli utenti devono ricordare quali domini hanno utilizzato le stesse credenziali, il che comporta una scarsa esperienza utente.

Problemi con gli accessi disgiunti

Sebbene le soluzioni alternative tecniche possano raggiungere la funzionalità di base, non offrono un percorso senza interruzioni. I flussi di accesso disgiunti introducono punti di attrito che compromettono sia l'usabilità sia la sicurezza.

Frammentazione del gestore delle password

Il punto di attrito più elevato è l'interruzione dei gestori delle password. I gestori delle password associano le credenziali memorizzate all'origine specifica in cui sono registrate. In questo modo, il browser non può offrire la compilazione automatica su domini diversi, anche se appartengono alla stessa organizzazione.

Quando un utente passa da un dominio con credenziali salvate a un nuovo dominio nella tua organizzazione, il gestore delle password non riconosce la relazione e non attiva la richiesta di compilazione automatica. In questo modo si crea un attrito di inserimento manuale. Gli utenti devono cercare le proprie credenziali, reimpostare la password o creare un account duplicato.

Poiché il gestore delle password non è affidabile in queste proprietà, gli utenti potrebbero abbandonare gli strumenti per questi siti. Invece, spesso creano password deboli e memorizzabili da riutilizzare altrove, il che peggiora la sicurezza complessiva della tua organizzazione.

Gateway di phishing

Questa interruzione funge da gateway di phishing. Il rifiuto di un gestore delle password di compilare automaticamente un dominio non riconosciuto è un meccanismo di difesa principale. Richiedendo agli utenti di inserire manualmente le credenziali su URL diversi, li addestri involontariamente a cadere vittime di attacchi di phishing.

Roadblock delle passkey

L'attrito aumenta quando utilizzi le passkey. L'architettura di sicurezza principale di WebAuthn associa crittograficamente le passkey in modo rigoroso a un ID RP (Relying Party) specificato.

In questo modo si crea una "trappola per l'ID RP". Una passkey registrata su brand.example non è utilizzabile su service-app.example perché il browser nega l'accesso interdominio. Per evitare di chiedere agli utenti di registrare passkey distinte per ogni sito, devi consolidare queste proprietà in un unico ID RP.

Approcci consigliati

Per stabilire la continuità dell'identità, devi abbandonare le integrazioni di accesso ad hoc e adottare standard architetturali riconosciuti:

• Utilizza i file di configurazione dei metadati: ospita i file di metadati come Digital Asset Links e Related Origin Requests, per stabilire una catena di attendibilità crittografica. In questo modo è possibile condividere facilmente credenziali e passkey su domini e app mobile diversi. Questo approccio è una correzione silenziosa e a basso costo per la frammentazione dell'identità che non richiede una riarchitettura complessa dell'infrastruttura web esistente.
• Utilizza gli iframe multiorigine: incorpora un' origine di autenticazione centralizzata come iframe all'interno di una parte autorizzata per collegare le credenziali e le passkey salvate su siti diversi. Questo approccio utilizza i criteri delle autorizzazioni e i cookie partizionati per consentire un'esperienza di accesso senza interruzioni e in contesto, mantenendo al contempo limiti di sicurezza rigorosi tramite CSP e messaggi tra documenti.
• Segui la federazione delle identità standard: adotta protocolli standard di settore come OpenID Connect per centralizzare l'autenticazione su un dominio del provider di identità (IdP) dedicato. In questo modo, il percorso di accesso viene formalizzato tramite reindirizzamenti sicuri, sostituendo le integrazioni fragili con una soluzione proprietaria affidabile e scalabile.
• Consolida i sottodomini: esegui la transizione ai sottodomini in una root comune. In questo modo è possibile condividere facilmente le sessioni tramite cookie con caratteri jolly e la continuità delle passkey nell'intero dominio registrabile. Molti gestori delle password possono riconoscere il dominio root condiviso e suggerire automaticamente le credenziali salvate nei sottodomini correlati.

Utilizza i file di configurazione dei metadati

Una delle sfide principali dell'identità interdominio è la frammentazione delle credenziali salvate. I gestori delle password trattano domini e app diversi come entità completamente isolate, il che impedisce loro di compilare automaticamente le credenziali salvate in una proprietà in un'altra.

Per risolvere la frammentazione, puoi configurare il comportamento dei gestori delle password anziché modificare la struttura del sito web. Ospitando file di configurazione dei metadati specifici, le organizzazioni possono affermare crittograficamente che domini e applicazioni diversi appartengono alla stessa organizzazione. In questo modo, i sistemi operativi, i browser e i gestori delle password possono riconoscere questa relazione e collegare automaticamente il contesto dell'identità, condividendo password e passkey tra le tue proprietà. Questo approccio è necessario anche per condividere password e passkey basate sul web con le applicazioni mobile, anche se i domini web sono consolidati.

Utilizza due file di configurazione diversi per assicurarti di coprire piattaforme ed ecosistemi diversi:

• Gestore delle password di Google su Android e Chrome: ospita un Digital Asset Links (DAL) file JSON all'indirizzo /.well-known/assetlinks.json per stabilire una relazione di attendibilità verificabile tra le app e i siti web associati di un'organizzazione. Questa attendibilità consente i link diretti nelle app e la condivisione delle credenziali senza interruzioni, in cui le password salvate sul web vengono compilate automaticamente nei siti web associati (anche se la condivisione delle passkey su più domini web richiede comunque le richieste di origine correlate). Scopri di più nella guida alla condivisione delle credenziali senza interruzioni.

• Password Apple su iOS e Safari: ospita un file AASA (Apple App Site Association) all'indirizzo /.well-known/apple-app-site-association per stabilire la catena di attendibilità crittografica necessaria per collegare gli stati delle password Apple tra le app iOS e Safari. Per supportare gli ecosistemi di terze parti, puoi dichiarare questi domini associati in modo centralizzato utilizzando un repository di crowdsourcing. In questo modo, anche gli strumenti indipendenti (come 1Password, che inserisce esplicitamente questo repository) riconoscono il contesto dell'identità condivisa. Per scoprire di più sull'associazione di siti e app Apple, leggi Supportare i domini associati.

Per abilitare le passkey su domini web diversi e risolvere il problema delle passkey roadblock, gli sviluppatori possono ospitare un file ROR (Related Origin Requests) all'indirizzo /.well-known/webauthn. ROR dichiara esplicitamente i domini autorizzati a condividere in modo sicuro lo stesso ID RP della passkey. Per scoprire di più sulle richieste di origine correlate, leggi Consentire il riutilizzo delle passkey sui tuoi siti con le richieste di origine correlate.

• Vantaggi:
  • Correzione in background per gli utenti finali: funziona completamente in background, risolvendo automaticamente la frammentazione della compilazione automatica e stabilendo la continuità delle passkey a livello di sistema operativo o browser senza modifiche visibili all'esperienza utente.
  • Implementazione semplice: si tratta di una soluzione a basso costo che richiede solo l'hosting di file JSON statici. Non richiede la riarchitettura del backend o una logica di scambio di token complessa.
  • Mantiene l'infrastruttura esistente: puoi migliorare notevolmente il percorso interdominio senza modificare il brand o consolidare i domini.
• Svantaggi:
  • Vincoli della piattaforma: le piattaforme in genere applicano limiti rigorosi alle richieste di origine correlate. Ad esempio, Chrome limita un singolo ID RP a un massimo di 5 etichette eTLD+1 associate. Ad esempio, example.co.uk e example.de condividono la stessa etichetta eTLD+1 example; tuttavia, example-rewards.com utilizza un'etichetta example-rewards separata. Se gestisci un portafoglio di domini ampio o vario, questi limiti potrebbero non essere sufficienti.
  • Aumento della latenza operativa: la risoluzione dei file di metadati richiede un roundtrip di rete aggiuntivo, che aggiunge latenza quando il browser elabora l'autenticazione.

Utilizza gli iframe multiorigine

Se non puoi utilizzare l'approccio dei file di configurazione dei metadati a causa dei limiti di dominio delle richieste di origine correlate, gli elementi iframe multiorigine offrono un percorso solido e supportato dagli standard per risolvere le sfide di accesso interdominio.

Incorporando un'origine di autenticazione centralizzata (ad esempio, auth.brand.example) come iframe all'interno di una parte autorizzata (ad esempio, brand.example), puoi interagire sia con i normali campi del modulo sia con le API moderne. Per le password, il gestore delle credenziali del browser associa le azioni di compilazione automatica all'origine dell'iframe (auth.example). In questo modo, gli utenti possono accedere alle proprie credenziali centralizzate senza interruzioni su siti diversi.

Per le passkey, la finestra principale deve concedere l'accesso all'iframe utilizzando il framework dei criteri delle autorizzazioni, consentendo all'iframe di richiamare WebAuthn per l'autenticazione rispetto all' ID RP della propria origine. In entrambi i flussi, CSP (Content Security Policy) è utile per proteggere gli utenti da attacchi come clickjacking e cross-site scripting. Una volta eseguita l'autenticazione, la sessione viene stabilita con un cookie partizionato e il token viene trasmesso in modo sicuro alla finestra principale utilizzando postMessage().

• Vantaggi:
  • Credenziali centralizzate: evita la frammentazione delle credenziali. Un'unica origine centralizzata gestisce sia le password salvate sia un ID RP della passkey unificato, consentendo a domini distinti di condividere queste credenziali senza dover consolidare i domini.
  • Autenticazione contestuale: l'intero flusso di accesso, sia che si tratti di compilare automaticamente una password o di verificare con una passkey, avviene senza interruzioni nel contesto della pagina principale, evitando reindirizzamenti federati che causano interruzioni.
  • Resistenza alle protezioni dal monitoraggio: questo approccio funziona correttamente anche con protezioni dal monitoraggio tra siti rigorose utilizzando i cookie partizionati.
• Svantaggi:
  • Vincoli di implementazione: questa architettura richiede engineering specializzato. Richiede un CSP rigoroso (frame-ancestors) per limitare l'incorporamento ai domini principali attendibili e impedire il clickjacking, la configurazione dei criteri delle autorizzazioni HTTP per abilitare l'API WebAuthn e la messaggistica tra documenti sicura e convalidata (postMessage()) per mitigare gli attacchi di spoofing dell'origine e CSRF. Scopri le best practice in Passkey all'interno degli iframe.

Segui la federazione delle identità standard

L'adozione della federazione delle identità standard, come OpenID Connect, è un approccio solido e sostenibile per mantenere il sistema di account. Questo approccio formalizza il flusso di lavoro di autenticazione consolidandolo in un unico dominio del provider di identità (IdP) dedicato, ad esempio auth.brand.example. Con un protocollo stabilito, le applicazioni reindirizzano gli utenti a questo hub centrale per l'autenticazione prima di ricevere in modo sicuro un trasferimento di token per completare l'accesso al dominio di destinazione. Sebbene sia spesso associata agli accessi di terze parti (come Accedi con Google), la federazione standard è completamente valida e ampiamente utilizzata come soluzione proprietaria per sostituire le soluzioni alternative fragili.

• Vantaggi:
  • Linguaggio di engineering comune: gli sviluppatori non devono imparare o mantenere un protocollo specifico e personalizzato; possono fare affidamento su conoscenze di settore consolidate e librerie complete. Sono disponibili anche soluzioni in pacchetto.
  • Affidabilità testata: i protocolli standard sono collaudati, sicuri e molto meno fragili delle implementazioni ad hoc.
  • Facilmente espandibile: se l'organizzazione deve federare con un nuovo servizio di terze parti o integrare un'acquisizione in un secondo momento, l'infrastruttura di identità è già attrezzata per fornire le credenziali.
  • Esperienza utente coerente: gli utenti riconoscono la pagina IdP centralizzata come l'origine autorevole del brand, chiarendo esattamente quando e dove sono richieste le credenziali.
• Svantaggi:
  • Elevato overhead di integrazione: lo sviluppo o la migrazione a un IdP centralizzato introduce un elevato overhead di integrazione e richiede competenze di sicurezza specializzate. Le organizzazioni devono investire nel refactoring sicuro di tutte le applicazioni connesse per supportare pattern sicuri basati sul reindirizzamento.
  • Reindirizzamenti che causano interruzioni: il flusso di autenticazione richiede il reindirizzamento degli utenti dal sito di origine a una pagina del provider di identità centralizzata, impedendo un'esperienza di accesso senza interruzioni e in contesto.

Consolida i sottodomini

Un altro approccio strutturale consiste nell'unificare tutti i domini spostando le proprietà digitali disparate sotto un dominio root registrabile comune (eTLD+1). Ciò comporta la transizione di domini separati come brand.example e service-app.example in sottodomini come www.brand.example e service.brand.example.

• Vantaggi:
  • Gestione unificata delle credenziali: i gestori delle password possono riconoscere il dominio root e trattare tutti i sottodomini come una singola voce, eliminando le richieste duplicate e l'inserimento manuale delle password.
  • Continuità delle passkey: gli sviluppatori possono definire in modo nativo l'ambito di un ID RP della passkey per il dominio registrabile, estendendo immediatamente il supporto delle passkey a tutti i sottodomini associati. In questo caso, un ID RP di brand.example funzionerà sia su www.brand.example sia su service.brand.example.
  • Condivisione delle sessioni senza sforzo: il consolidamento della struttura del dominio consente di condividere una singola sessione utilizzando i cookie con caratteri jolly (ad esempio, definendo l'ambito di un cookie su Domain=brand.example).
• Svantaggi:
  • Vincoli di branding e migrazione: questo approccio può imporre potenziali limiti di branding se la tua organizzazione impone domini di primo livello distinti. La migrazione è complessa e richiede un'attenta gestione dei reindirizzamenti HTTP e un'ampia correzione delle configurazioni multiorigine legacy.

Conclusione

Per ottenere la continuità dell'identità, devi passare dalle integrazioni di accesso ad hoc agli standard di autenticazione consolidati. Valutando i vincoli aziendali rispetto a queste pratiche consolidate, come la federazione, il consolidamento dei domini, gli iframe o i metadati, puoi eliminare l'attrito dell'esperienza utente e migliorare l'autenticazione nel tuo ecosistema.

Per scoprire di più sugli argomenti correlati, assicurati di seguire il nostro blog ed esplorare altre risorse nel portale delle identità di Chrome.