Data di pubblicazione: 8 settembre 2025
I leader del settore in più settori comprendono l'importanza di proteggere la privacy e al contempo offrire un'ottima esperienza utente. Seznam si impegna a offrire un'esperienza utente e una privacy senza compromessi e ha integrato correttamente Federated Credential Management (FedCM).
Aziende che traggono vantaggio da FedCM
Organizzazioni di diversi domini integrano FedCM nelle loro soluzioni. Poiché FedCM è progettato per la gestione federata delle identità, i provider di identità (IdP) sono i suoi principali beneficiari. Lo utilizzano per offrire un'esperienza di accesso migliorata. Anche i fornitori di servizi di e-commerce e i fornitori di servizi di pagamento, molti dei quali fungono anche da provider di identità, identificano opportunità per migliorare l'esperienza utente tramite FedCM.
Seznam
Seznam è un'azienda tecnologica e un provider di identità europeo che raggiunge il 90% della popolazione ceca. Funge da hub sociale, di conoscenza e di contenuti. Seznam ha adottato FedCM per consentire ai clienti dei negozi online che operano sulle piattaforme dei suoi partner di accedere utilizzando il proprio account Seznam.
Con FedCM, Seznam ha registrato un aumento significativo dei tassi di accesso degli utenti sulle reti partner, un miglioramento dell'esperienza utente e un flusso di identità coerente, indipendentemente dalla disponibilità dei cookie di terze parti.
Motivazione
Seznam ha scelto di implementare FedCM per diversi vantaggi riconosciuti:
- FedCM è progettato pensando all'utente finale, che ha il controllo sulle informazioni fornite all'IdP. Ciò è in linea con la visione di Seznam di un ambiente sicuro e privato per i suoi utenti.
- FedCM è una funzionalità integrata del browser ed è compatibile con l'esperienza di accesso esistente di Seznam, che utilizza lo standard OAuth 2.0.
- FedCM è un approccio alla federazione delle identità incentrato sulla privacy. Ad esempio, la visita dell'utente alla relying party (RP) viene condivisa solo con l'IdP se l'utente esegue l'accesso. Ciò è in linea con la visione di Seznam in merito alle attività sostenibili.
Dettagli di implementazione
Seznam ha implementato FedCM come livello sopra la sua soluzione OAuth esistente. In questa architettura, il flusso FedCM trasmette in modo sicuro un codice di autorizzazione OAuth dall'IdP alle RP.
Impegno di implementazione
Seznam ha trovato l'implementazione di FedCM semplice e in linea con il suo approccio esistente. La ricerca e l'implementazione dell'API hanno richiesto un mese e due sviluppatori. Ci sono voluti meno di due mesi per portare FedCM in produzione. Il processo è stato iterativo, con un tempo considerevole dedicato allo studio dell'API.
Sfide
In qualità di early adopter, Seznam ha identificato diverse sfide e fornito un feedback prezioso che ha contribuito a perfezionare l'API.
Supporto di più provider di identità
Seznam era interessato al supporto di FedCM per più provider di identità. Con questa funzionalità, l'obiettivo era consentire agli utenti di scegliere tra Seznam o Account Google sui RP partner. Tuttavia, quando Seznam ha iniziato a implementare FedCM, la funzionalità era in una fase iniziale di implementazione e gli sviluppatori dovevano registrarsi per una prova dell'origine e utilizzare un token per abilitare la funzionalità per gli utenti. Per questo motivo, Seznam ha scelto di attendere la distribuzione della funzionalità nella versione stabile di Chrome.
La funzionalità è disponibile a partire da Chrome 136 e gli sviluppatori possono configurare il supporto per più provider di identità. Ad esempio, per supportare sia i provider di identità Seznam che Google, l'IdP può includere i due provider in una singola chiamata get() e l'RP può farlo in modo indipendente:
// Executed on the RP's side:
const credential = await navigator.credentials.get({
identity: {
providers: [
{
// IdP1: Seznam config file URL
configURL: 'https://szn.cz/.well-known/web-identity',
clientId: '123',
},
{
// Allow Google Sign-in
configURL: 'https://accounts.google.com/gsi/fedcm.json',
clientId: '456',
},
],
},
});
Seznam indica che questa funzionalità farà parte della sua soluzione. Inoltre, il team di FedCM sta implementando il supporto per più SDK, con il supporto per più chiamate get().
DNS privato
Durante la fase di test, Seznam ha riscontrato un problema relativo alla configurazione di rete. Il suo server IdP di test si trovava all'interno di una rete privata, accessibile solo tramite DNS privato. Questa configurazione è comune per gli ambienti di test e sviluppo interni prima dell'esposizione pubblica.
Tuttavia, questa configurazione comporta una sfida: poiché un file well-known deve essere pubblicato da un eTLD+1 e un dominio di sviluppo privato non è registrato nell'elenco dei suffissi pubblici, il browser non invierà richieste per recuperare il file well-known ospitato nel dominio di sviluppo:
login.idp.example: dominio di produzione di esempio.idp.example/.well-known/web-identity: filewell-knowndi esempio in produzione.login.dev.idp.example: dominio di sviluppo di esempio.login.dev.idp.example/.well-known/web-identity: filewell-knowndi esempio nell'ambiente di sviluppo.
Quando l'implementazione di FedCM è ospitata su un dominio privato, le richieste del browser al file well-known generano questo errore:
The fetch of the well-known file resulted in a network error: ERR_NAME_NOT_RESOLVED
Puoi risolvere questo errore attivando il flag #fedcm-without-well-known-enforcement di Chrome. Quando questo flag è attivato, il browser salta il recupero del file well-known a scopo di test. Scopri come attivare i flag di test in Chrome.
Divulgazione di informazioni personalizzata
Seznam voleva anche includere informazioni aggiuntive insieme al design iniziale della UI FedCM. La finestra di dialogo FedCM standard mostra all'utente un messaggio fisso che indica che dati specifici, in genere l'immagine del profilo, il nome e l'indirizzo email dell'utente, vengono condivisi con la RP.
Il team di FedCM ha incorporato il feedback e ha esteso l'API per consentire la personalizzazione dell'informativa presentata all'utente. Ad esempio, con la funzionalità Continua su, il fornitore di servizi di identità può reindirizzare l'utente a una pagina personalizzata per richiedere ulteriori informazioni o autorizzazioni. Le funzionalità Parametri personalizzati e Campi, supportate a partire da Chrome 132, consentono un'ulteriore personalizzazione.
Convalida dell'origine del componente attendibile
Il server IdP deve convalidare l'intestazione HTTP Origin in una richiesta FedCM in entrata per assicurarsi che la richiesta corrisponda all'origine che il RP ha preregistrato con l'IdP. In questo modo, la richiesta di asserzione dell'ID FedCM proviene da un RP autorizzato e non da un malintenzionato che utilizza client_id.
Seznam ha un caso particolare: quando i suoi partner RP si registrano su Seznam, non richiedono i dati di origine dell'RP. Ciò significa che l'origine del RP non può essere verificata.
L'integrazione FedCM di Seznam si basa su una soluzione OAuth esistente. Ha seguito il percorso alternativo di convalida sia di client_id che di client_secret per garantire che la soluzione rimanesse sicura senza controllare l'origine.
Dominio visibile agli utenti del provider di identità
L'infrastruttura di autenticazione degli utenti di Seznam opera principalmente sul dominio szn.cz, in cui sono ospitati gli endpoint IdP necessari per FedCM. Tuttavia, la sua identità aziendale principale e il dominio in cui gli utenti riconoscono e si fidano ampiamente dei suoi servizi sono seznam.cz.
La finestra di dialogo FedCM mostra il dominio di origine effettivo degli endpoint IdP: szn.cz. Gli utenti che conoscono il brand seznam.cz potrebbero essere confusi ed esitare quando viene chiesto loro di accedere con il dominio szn.cz, meno familiare, durante la procedura di accesso.
A partire da Chrome 141, FedCM non consente di visualizzare un dominio diverso da quello che ospita l'implementazione del fornitore di identità. Questa limitazione è una scelta di progettazione deliberata volta a garantire la trasparenza per gli utenti. Tuttavia, il team FedCM riconosce le sfide che questa limitazione potrebbe creare e sta discutendo potenziali aggiustamenti.
Impatto
Con l'API FedCM, Seznam ora può fornire flussi di autorizzazione con un solo tocco agli utenti partner. Ha evidenziato i vantaggi dell'esperienza utente di FedCM rispetto ad altri metodi di autenticazione.
Sebbene Seznam abbia notato un aumento significativo del coinvolgimento degli utenti sui siti web che hanno eseguito la transizione all'accesso FedCM, non ha eseguito un'analisi completa per isolare l'impatto diretto preciso da altri fattori. Prima dell'integrazione di FedCM, l'implementazione consentiva i pagamenti come ospite utilizzando indirizzi email sottoposti ad hashing con consenso per l'identificazione degli utenti. La difficoltà nell'esecuzione di un'analisi di questo tipo consisteva nello stimare se una conversione utente potesse essere attribuita a FedCM o se l'utente avrebbe completato un acquisto utilizzando il pagamento come ospite. L'ipotesi di Seznam suggerisce che la maggiore facilità d'uso di FedCM potrebbe aver contribuito a questo tasso di conversione più elevato.
Conclusione
Seznam ha implementato correttamente FedCM, fornendo un flusso di autorizzazione alternativo insieme alla sua soluzione OAuth esistente. Sebbene Seznam abbia dovuto affrontare alcune sfide relative al supporto del provider di identità, alle configurazioni DNS privato, alla personalizzazione del testo dell'informativa, alla convalida dell'origine della relying party e alla visualizzazione del dominio rivolta agli utenti, l'API è maturata dalla sua implementazione. Il team di FedCM ha incorporato il feedback di Seznam e di altri early adopter, consentendo di disporre di strumenti migliori per affrontare queste sfide. Come passaggio successivo, Seznam prevede di implementare il supporto di FedCM per più provider di identità.