In che modo adidas ha accelerato l'adozione e l'affidabilità delle passkey con Conditional Create e l'API Signal

Christopher Kokott
Christopher Kokott
Yu Tsuno
Yu Tsuno

Il logo adidas nero con le tre strisce iconiche sopra il wordmark adidas in minuscolo.

Le organizzazioni e gli sviluppatori incontrano un ostacolo significativo quando trasferiscono gli utenti dalle password alle passkey. Sebbene le passkey forniscano un aggiornamento della sicurezza fondamentale, il processo di creazione manuale può spesso introdurre attrito. In un ambiente e-commerce ad alto volume, ogni secondo di esitazione è importante, perché qualsiasi ritardo può potenzialmente interrompere il percorso di acquisto e portare all'abbandono del carrello. Inoltre, mantenere sincronizzati gli stati delle credenziali tra il server e il dispositivo dell'utente è essenziale per evitare errori di accesso e frustrazione per l'utente.

adidas ha affrontato queste stesse sfide. Il loro obiettivo principale era rimuovere le difficoltà dalla procedura di accesso e semplificare l'esperienza su piattaforme web e app e su dispositivi. Sebbene la sicurezza rimanga una priorità elevata, il team di prodotto si è concentrato sul rendere i flussi di registrazione e accesso il più semplici possibile con le passkey.

Per affrontare queste sfide, adidas ha implementato Conditional Create per eseguire automaticamente l'upgrade degli utenti con password alle passkey e l'API Signal per mantenere le credenziali coerenti. Inoltre, hanno implementato le richieste di origine correlata per supportare l'utilizzo cross-domain, se necessario.

I risultati

La strategia di adidas di automatizzare la creazione di passkey e mantenere l'integrità delle credenziali ha prodotto risultati immediati e misurabili sia in termini di adozione che di affidabilità dell'accesso:

  • Tasso di adozione elevato:dal lancio della procedura di accesso con passkey, adidas ha raggiunto un tasso di creazione complessivo delle passkey del 47%. Ciò include sia la creazione condizionale automatica sia i consensi avviati dagli utenti quando richiesti durante i flussi di registrazione o accesso. L'adozione è stata particolarmente elevata sui dispositivi mobili, che hanno registrato un tasso di conversione del 52% (rispetto al 34% sui computer).
  • Aggiornamenti accelerati tramite la creazione condizionale: oltre ai prompt espliciti, adidas ha registrato un aumento dell'8% delle creazioni di passkey eseguendo l'upgrade degli utenti con password esistenti in background, senza richiedere l'intervento manuale dell'utente.
  • Affidabilità di accesso quasi perfetta: le passkey hanno registrato un tasso di successo superiore al 99% una volta avviato l'accesso. Si tratta di un importante aggiornamento della sicurezza rispetto al tasso di successo storico delle password di adidas del 70%, che spesso veniva ridotto da errori umani come errori ortografici o credenziali dimenticate.
  • Riduzione al minimo di problemi ed errori: implementando l'API Signal per sincronizzare automaticamente le credenziali del dispositivo e del server, adidas è riuscita a mantenere gli errori PASSKEY_NOT_FOUND al di sotto dello 0,3% dei tentativi di accesso. In questo modo è stata eliminata la frustrazione degli utenti causata dalle passkey orfane.

    47 %

    Tasso di creazione delle passkey

    8 %

    Aumento delle creazioni di passkey utilizzando la creazione condizionale

    >99 %

    Percentuale di successo dell'accesso con passkey una volta avviato

    <0,3 %

    Percentuale di errori di passkey orfane

Come adidas ha risolto il problema

Ecco come adidas ha affrontato queste sfide:

1. Accelerare l'adozione con la creazione condizionale

Per aiutare gli utenti ad adottare facilmente le passkey, adidas ha implementato la funzionalità Conditional Create. Questa funzionalità consente a un sito web di creare automaticamente una passkey quando un utente accede con una password memorizzata nel gestore delle password. Per garantire la massima percentuale di successo, il sistema chiama l'API immediatamente dopo un accesso riuscito, in modo che il sistema riconosca l'utilizzo della password come recente.

const cred = await navigator.credentials.create({
  publicKey: options,
  mediation: 'conditional' // Enables automatic passkey creation
});

adidas ha integrato questa funzionalità con una logica personalizzata che convalida innanzitutto l'ambiente dell'utente. In particolare, il sistema controlla se la funzionalità di creazione condizionale è supportata dal browser. Il sistema rispetta anche le preferenze dell'utente sopprimendo la richiesta se l'utente ha già saltato la creazione della passkey tre volte negli ultimi sei mesi.

Se l'ambiente è compatibile, il sistema tenta di creare la passkey in background, subito dopo l'autenticazione dell'utente. Questo tempismo specifico aumenta la probabilità che i prerequisiti vengano soddisfatti. È importante sottolineare che l'implementazione gestisce le eccezioni WebAuthn con una filosofia "fail-open" per dare sempre la priorità all'accesso degli utenti. Se il browser segnala un InvalidStateError, che indica che probabilmente esiste già una passkey, il sistema interrompe la creazione in background e accede immediatamente per l'utente. Al contrario, se si verifica un NotAllowedError, ovvero se le condizioni specifiche per la creazione automatica non sono state soddisfatte, il sistema rileva questo stato e indirizza l'utente a una schermata "Raccolta passkey" per guidarlo in una procedura di configurazione manuale. Distinguendo tra questi vincoli tecnici e i comportamenti degli utenti, adidas garantisce che l'impegno per gli upgrade delle passkey migliori l'esperienza di accesso anziché interromperla.

Un prompt &quot;Accedi con una passkey la prossima volta&quot; sul sito web adidas, che incoraggia gli utenti a creare una passkey per accedere in modo più rapido e sicuro utilizzando la biometria o un passcode.
La schermata "Passkey Collector".

2. Garantire l'affidabilità con l'API Signal

Man mano che gli utenti gestiscono le proprie credenziali su più dispositivi, possono verificarsi incongruenze. Ad esempio, una passkey potrebbe essere eliminata dal server, ma rimanere sul dispositivo dell'utente. Per evitare errori di accesso causati da queste credenziali "fantasma", adidas ha implementato l'API Signal�. Questa API consente al server di segnalare lo stato delle credenziali al fornitore di passkey.

adidas utilizza tutti e tre i metodi dell'API Signals disponibili per mantenere questa coerenza. Anziché indovinare quali credenziali rimuovere, adidas mappa eventi specifici del ciclo di vita dell'utente alla chiamata API appropriata:

  • Errori di registrazione:quando viene creata una passkey sul client, ma la registrazione sul backend non va a buon fine, adidas utilizza signalUnknownCredential per rimuovere immediatamente la credenziale orfana.
  • Accessi non validi:se un utente tenta di accedere con una passkey revocata o obsoleta, signalUnknownCredential segnala al provider di nasconderla.
  • Gestione utenti:quando un utente rimuove esplicitamente una passkey nelle impostazioni dell'account, signalAllAcceptedCredentials sincronizza la lista consentita. In questo modo, la passkey eliminata non viene più offerta.
  • Aggiornamenti dell'account:quando un utente modifica la propria email o il proprio nome utente, signalCurrentUserDetails aggiorna i metadati sul dispositivo in modo che corrispondano a quelli del server.
// Detect authentication failure due to lack of the credential

if (result.status === 404) {
  if (PublicKeyCredential.signalUnknownCredential) {
    await PublicKeyCredential.signalUnknownCredential({
      rpId: "adidas.com",
      credentialId: "..." // base64url encoded credential ID
    });
  }
}
Una finestra modale di conferma nelle impostazioni dell&#39;account adidas che consente a un utente di rimuovere una passkey specifica, con un avviso che indica che non sarà più disponibile per l&#39;accesso.
Finestra modale di conferma per la rimozione di una passkey.
Una notifica di Gestore delle password di Google che indica una &quot;Passkey eliminata&quot; che non funziona più, a dimostrazione di come l&#39;API Signal mantiene sincronizzato il dispositivo dell&#39;utente con il server.
Notifica API Signal per una passkey eliminata.

Per supportare ulteriormente la propria architettura multicanale, adidas ha implementato le richieste di origine correlate. Sebbene la maggior parte degli utenti rimanga nel proprio mercato locale (ad esempio, adidas.nl), questa configurazione consente agli utenti che navigano tra le regioni di riutilizzare le passkey nei domini consentiti scegliendo come target un singolo ID relying party (adidas.com).

Per attivare questa funzionalità, adidas ospita un file di configurazione webauthn nel proprio dominio ID Relying Party (RP ID) principale. Questo file contiene una lista consentita esplicita di origini autorizzate a utilizzare adidas.com per la registrazione e l'autenticazione con passkey. Definendo queste relazioni, il browser può verificare che una passkey creata su un sito regionale sia valida per l'utilizzo su un altro, offrendo un'esperienza senza problemi per gli utenti globali.

// https://www.adidas.com/.well-known/webauthn

{
  "origins": [
    "https://www.adidas.fi",
    "https://www.adidas.nl",
    // ... abridged (the full file lists 50+ regional domains)
  ]
}

È importante sottolineare che adidas ha fornito anche un supporto perfetto per le passkey all'interno delle sue app mobile per Android utilizzando Digital Asset Links. Poiché le app utilizzano una WebView ospitata su idp.adidas.com per l'autenticazione, sono stati necessari i Digital Asset Links per stabilire una relazione attendibile tra l'app per Android e l'ID Relying Party (adidas.com). Questa verifica consente all'app di accedere alle stesse passkey utilizzate sul web, creando un'esperienza di accesso fluida e unificata su tutte le piattaforme.

Per raggiungere questo obiettivo, adidas ospita un file Digital Asset Links (assetlinks.json) sui rispettivi domini web. Questo file dichiara pubblicamente l'associazione crittografica con le applicazioni Android. Analogamente, per supportare il proprio ecosistema iOS, adidas utilizza Associated Domains. Ospitando un file apple-app-site-association, stabiliscono una connessione sicura che consente alla loro app per iOS di utilizzare in modo sicuro le passkey in una visualizzazione web.

// https://www.adidas.fi/.well-known/assetlinks.json

[
  {
    "relation": [
      "delegate_permission/common.handle_all_urls",
      "delegate_permission/common.get_login_creds"
    ],
    "target": {
      "namespace": "android_app",
      "package_name": "com.adidas.app",
      "sha256_cert_fingerprints": [
        "B2:55:43:78:89:F6:F6:FD:BB:16:5C:43:EE:66:14:18:D4:E8:33:6D:3A:1F:68:86:C3:A8:7C:89:2B:51:45:96",
        "..."
      ]
    }
  },
  // ... abridged
]
Un diagramma di sequenza tecnica che mostra le relazioni di trust stabilite tramite le richieste di origine correlate (ROR) e i link Digital Asset Links (DAL) tra un dispositivo client e il server di destinazione.
Diagramma di sequenza delle richieste di origine correlate
Un prompt della passkey a livello di sistema su un dispositivo Android che chiede all&#39;utente di utilizzare la passkey salvata per accedere al provider di identità adidas.
Accesso condizionale
La schermata di accesso dell&#39;app mobile adidas con un pulsante dedicato &quot;Continua con la passkey&quot; per un&#39;esperienza di autenticazione semplificata.
Identificatore per primo

Quali sono i prossimi passi di adidas?

Grazie a una solida base di upgrade automatici e credenziali sincronizzate disponibili su adidas.fi e adidas.nl, adidas implementerà questa configurazione senza problemi in tutti gli altri mercati globali entro la fine di aprile 2026. Inoltre, adidas sta esplorando esperienze di accesso ancora più fluide testando la prova dell'origine di mediazione immediata. I piani futuri includono la possibilità per gli utenti di creare account direttamente con le passkey. In questo modo viene rimosso l'attuale requisito di registrazione con un metodo alternativo. Il team sta anche esaminando l'attivazione intelligente per richiamare direttamente la finestra di dialogo della passkey di sistema nel secondo passaggio dell'accesso. In questo modo non è necessario un clic aggiuntivo quando è molto probabile che l'utente abbia una passkey disponibile sul dispositivo attuale.

Perché è importante per te

Il passaggio all'autenticazione senza password ha esito positivo quando l'esperienza utente rimane fluida. Implementando la creazione condizionale, puoi eseguire la migrazione degli utenti dalle password senza interrompere le loro abitudini. Utilizzando le richieste di origine correlate, puoi condividere queste passkey tra i tuoi domini, consentendo agli utenti di accedere facilmente all'intero ecosistema con una sola passkey. Infine, l'accoppiamento con l'API Signal garantisce che l'esperienza unificata e senza password rimanga affidabile e priva di errori.

Scopri di più