Wie adidas die Einführung und Zuverlässigkeit von Passkeys mit Conditional Create und der Signal API beschleunigt hat

Christopher Kokott

Yu Tsuno

Organisationen und Entwickler stehen vor einer großen Herausforderung, wenn sie Nutzer von Passwörtern auf Passkeys umstellen. Passkeys bieten zwar ein wichtiges Sicherheitsupgrade, der manuelle Erstellungsprozess kann jedoch oft zu Problemen führen. Im E-Commerce, wo es um große Mengen geht, zählt jede Sekunde, denn jede Verzögerung kann den Kaufprozess unterbrechen und dazu führen, dass der Einkaufswagen verlassen wird. Außerdem ist es wichtig, die Anmeldedaten zwischen dem Server und dem Gerät des Nutzers zu synchronisieren, um Anmeldefehler und Frustration bei den Nutzern zu vermeiden.

adidas stand vor genau diesen Herausforderungen. Das Hauptziel war es, die Anmeldung zu vereinfachen und die Nutzerfreundlichkeit auf Web- und App-Plattformen sowie auf Geräten zu verbessern. Sicherheit hat weiterhin hohe Priorität, aber das Produktteam hat sich darauf konzentriert, die Registrierungs- und Anmeldevorgänge mit Passkeys so reibungslos wie möglich zu gestalten.

Um diese Herausforderungen zu meistern, hat adidas Conditional Create implementiert, um Nutzer mit Passwort automatisch auf Passkeys umzustellen, und die Signal API, um Anmeldedaten konsistent zu halten. Außerdem haben sie Related Origin Requests (Anfragen mit ähnlichem Ursprung) implementiert, um bei Bedarf die domainübergreifende Nutzung zu unterstützen.

Ergebnisse

Die Strategie von adidas, die Erstellung von Passkeys zu automatisieren und die Anmeldedaten zu schützen, führte zu sofortigen, messbaren Ergebnissen sowohl bei der Einführung als auch bei der Zuverlässigkeit der Anmeldung:

• Hohe Akzeptanzrate:Seit der Einführung der Anmeldung mit Passkeys hat adidas eine Gesamtrate von 47% bei der Erstellung von Passkeys erreicht. Dazu gehören sowohl die automatische bedingte Erstellung als auch die vom Nutzer initiierte Einwilligung, wenn er während der Registrierung oder Anmeldung dazu aufgefordert wird. Die Akzeptanz war auf Mobilgeräten besonders hoch. Hier lag die Conversion-Rate bei 52 % (im Vergleich zu 34% auf Computern).
• Beschleunigte Upgrades mit „Conditional Create“:Neben expliziten Aufforderungen konnte adidas die Anzahl der Passkey-Erstellungen um 8% steigern, indem bestehende Nutzer mit Passwörtern nahtlos im Hintergrund aktualisiert wurden, ohne dass Nutzer manuell eingreifen mussten.
• Nahezu perfekte Anmeldezuverlässigkeit:Passkeys haben eine Erfolgsrate von über 99 % erzielt, sobald eine Anmeldung initiiert wurde. Das ist eine erhebliche Sicherheitsverbesserung im Vergleich zur bisherigen Erfolgsrate von 70 % bei Passwörtern bei adidas, die oft durch menschliche Fehler wie Tippfehler oder vergessene Anmeldedaten reduziert wurde.
• Weniger Reibung und Fehler:Durch die Bereitstellung der Signal API zum automatischen Synchronisieren von Geräte- und Serveranmeldedaten konnte adidas die PASSKEY_NOT_FOUND-Fehler auf weniger als 0, 3% der Anmeldeversuche reduzieren. Dadurch wurde das Problem verwaister Passkeys für Nutzer effektiv behoben.

47 _%

Rate der Passkey-Erstellung

8 _%

Steigerung der Passkey-Erstellung durch „Conditional Create“

>99 _%

Erfolgsrate bei der Anmeldung mit Passkey nach dem Start

<0,3 _%

Fehlerrate für verwaiste Passkeys

So hat adidas das Problem gelöst

So hat adidas diese Herausforderungen gemeistert:

1. Einführung mit „Bedingte Erstellung“ beschleunigen

Damit Nutzer Passkeys problemlos verwenden können, hat adidas Conditional Create implementiert. Mit dieser Funktion kann eine Website automatisch einen Passkey erstellen, wenn sich ein Nutzer mit einem Passwort anmeldet, das in seinem Passwortmanager gespeichert ist. Um eine möglichst hohe Erfolgsrate zu erzielen, ruft das System die API unmittelbar nach einer erfolgreichen Anmeldung auf, damit die Verwendung des Passworts als aktuell erkannt wird.

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

adidas hat diese Funktion in eine benutzerdefinierte Logik integriert, die zuerst die Umgebung des Nutzers validiert. Das System prüft insbesondere, ob die Funktion „Conditional Create“ vom Browser unterstützt wird. Das System berücksichtigt auch die Nutzereinstellungen und unterdrückt die Aufforderung, wenn der Nutzer die Erstellung von Passkeys in den letzten sechs Monaten bereits dreimal übersprungen hat.

Wenn die Umgebung kompatibel ist, versucht das System, den Passkey im Hintergrund zu erstellen, unmittelbar nach der erfolgreichen Nutzerauthentifizierung. Durch diesen Zeitpunkt wird die Wahrscheinlichkeit erhöht, dass die Voraussetzungen erfüllt sind. Wichtig ist, dass bei der Implementierung WebAuthn-Ausnahmen nach dem „Fail-Open“-Prinzip behandelt werden, um den Nutzerzugriff immer zu priorisieren. Wenn der Browser einen InvalidStateError meldet, was darauf hindeutet, dass wahrscheinlich bereits ein Passkey vorhanden ist, stoppt das System die Hintergrundgenerierung und meldet den Nutzer sofort an. Wenn umgekehrt ein NotAllowedError auftritt, was bedeutet, dass die spezifischen Bedingungen für die automatische Erstellung nicht erfüllt wurden, erkennt das System diesen Zustand und leitet den Nutzer zu einem Bildschirm mit der Bezeichnung Passkey Collector weiter, um ihn durch einen manuellen Einrichtungsprozess zu führen. Durch die Unterscheidung zwischen diesen technischen Einschränkungen und Nutzerverhalten sorgt adidas dafür, dass die Umstellung auf Passkeys die Anmeldung verbessert und nicht unterbricht.

2. Zuverlässigkeit mit der Signal API sicherstellen

Wenn Nutzer ihre Anmeldedaten auf verschiedenen Geräten verwalten, kann es zu Inkonsistenzen kommen. Ein Passkey kann beispielsweise vom Server gelöscht werden, bleibt aber auf dem Gerät des Nutzers erhalten. Um Anmeldefehler zu vermeiden, die durch diese „Phantom“-Anmeldedaten verursacht werden, hat adidas die Signal API implementiert. Mit dieser API kann der Server den Status von Anmeldedaten an den Passkey-Anbieter signalisieren.

adidas verwendet alle drei verfügbaren Signal API-Methoden, um diese Konsistenz aufrechtzuerhalten. Anstatt zu raten, welche Anmeldedaten entfernt werden sollen, ordnet adidas bestimmte Ereignisse im Nutzerlebenszyklus dem entsprechenden API-Aufruf zu:

• Registrierungsfehler:Wenn ein Passkey auf dem Client erstellt wird, die Registrierung im Backend jedoch fehlschlägt, verwendet adidas signalUnknownCredential, um die verwaisten Anmeldedaten sofort zu entfernen.
• Ungültige Anmeldungen:Wenn ein Nutzer versucht, sich mit einem widerrufenen oder veralteten Passkey anzumelden, signalisiert signalUnknownCredential dem Anbieter, ihn auszublenden.
• Nutzerverwaltung:Wenn ein Nutzer einen Passkey explizit in seinen Kontoeinstellungen entfernt, synchronisiert signalAllAcceptedCredentials die Zulassungsliste. So wird sichergestellt, dass der gelöschte Passkey nicht mehr angeboten wird.
• Kontoaktualisierungen:Wenn ein Nutzer seine E-Mail-Adresse oder seinen Nutzernamen ändert, aktualisiert signalCurrentUserDetails die Metadaten auf dem Gerät, damit sie mit dem Server übereinstimmen.

// 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
    });
  }
}

:

3. Zugriff mit Anfragen zu zugehörigen Ursprüngen und Digital Asset Links vereinheitlichen

Um die Architektur für mehrere Märkte weiter zu unterstützen, implementierte adidas Anfragen zum verwandten Ursprung. Die meisten Nutzer bleiben in ihrem lokalen Markt (z. B. adidas.nl). Mit dieser Konfiguration können Nutzer, die zwischen Regionen wechseln, Passkeys in zulässigen Domains wiederverwenden, indem sie auf eine einzelne Relying Party-ID (adidas.com) ausgerichtet sind.

Dazu hostet adidas eine webauthn-Konfigurationsdatei in der Domain der primären Relying Party-ID (RP-ID). Diese Datei enthält eine explizite Zulassungsliste von Ursprüngen, die adidas.com für die Registrierung und Authentifizierung von Passkeys verwenden dürfen. Durch die Definition dieser Beziehungen kann der Browser prüfen, ob ein auf einer regionalen Website erstellter Passkey für die Verwendung auf einer anderen Website gültig ist. So wird die Nutzung für globale Nutzer vereinfacht.

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

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

Wichtig ist, dass adidas auch nahtlose Passkey-Unterstützung in seinen Android-Apps über Digital Asset Links bereitgestellt hat. Da die Apps für die Authentifizierung eine WebView-Komponente verwenden, die auf idp.adidas.com gehostet wird, waren Digital Asset Links erforderlich, um eine vertrauenswürdige Beziehung zwischen der Android-App und der Relying Party-ID (adidas.com) herzustellen. Durch diese Bestätigung kann die App auf dieselben Passkeys zugreifen, die im Web verwendet werden. So wird eine reibungslose, einheitliche Anmeldung auf allen Plattformen ermöglicht.

Dazu hostet adidas eine Digital Asset Links-Datei (assetlinks.json) auf den entsprechenden Webdomains. In dieser Datei wird die kryptografische Zuordnung zu den Android-Anwendungen öffentlich deklariert. Um ihr iOS-Ökosystem zu unterstützen, verwendet adidas Associated Domains. Durch das Hosten einer apple-app-site-association-Datei stellen sie eine sichere Verbindung her, über die ihre iOS-App Passkeys in einer Webansicht sicher verwenden kann.

// 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
]

Wie geht es mit adidas weiter?

Auf der Grundlage automatischer Upgrades und synchronisierter Anmeldedaten auf adidas.fi und adidas.nl wird adidas diese nahtlose Einrichtung bis Ende April 2026 auf alle anderen globalen Märkte ausweiten. Außerdem testet adidas mit dem Ursprungstest für die sofortige Vermittlung noch reibungslosere Anmeldeverfahren. In Zukunft sollen Nutzer Konten direkt mit Passkeys erstellen können. Dadurch entfällt die aktuelle Anforderung, sich zuerst mit einer alternativen Methode zu registrieren. Das Team untersucht auch die Möglichkeit, das Systempasswortdialogfeld im zweiten Anmeldeschritt direkt aufzurufen. So ist kein zusätzlicher Klick erforderlich, wenn mit hoher Wahrscheinlichkeit davon ausgegangen wird, dass der Nutzer auf seinem aktuellen Gerät einen Passkey hat.

Warum ist das wichtig für Sie?

Die Umstellung auf die passwortlose Authentifizierung ist erfolgreich, wenn die Nutzererfahrung nahtlos bleibt. Durch die Implementierung von „Conditional Create“ können Sie Nutzer mühelos von Passwörtern weg migrieren, ohne ihre Gewohnheiten zu beeinträchtigen. Mit Anfragen für zugehörige Ursprünge können Sie diese Passkeys für Ihre Domains freigeben, sodass Nutzer mit einem einzigen Passkey nahtlos auf Ihr gesamtes Ökosystem zugreifen können. In Kombination mit der Signal API wird dafür gesorgt, dass Ihre einheitliche, kennwortlose Anmeldung zuverlässig und fehlerfrei bleibt.

Weitere Informationen

• Nutzern mit „Bedingtes Erstellen“ den Umstieg auf Passkeys erleichtern
• Passkeys mit der Signal API konsistent halten
• Passkeys mit Anfragen zu verknüpften Ursprüngen auf mehreren Websites wiederverwenden