adidas が条件付き作成と Signal API を使用してパスキーの導入と信頼性を高めた方法

Christopher Kokott
Christopher Kokott
LinkedIn
Yu Tsuno
Yu Tsuno
LinkedIn

小文字の adidas のワードマークの上に、象徴的な 3 本のストライプが入った黒い adidas のロゴ。

組織やデベロッパーがユーザーをパスワードからパスキーに移行する際には、大きなハードルがあります。パスキーは重要なセキュリティ アップグレードですが、手動作成プロセスでは摩擦が生じることがよくあります。大量の e コマース環境では、わずかな遅延でも購入までの流れが妨げられ、カート放棄につながる可能性があるため、一瞬の遅延も重要になります。また、ログインエラーやユーザーの不満を防ぐには、サーバーとユーザーのデバイス間で認証情報の状態を同期しておくことが不可欠です。

adidas はまさにこのような課題に直面していました。主な目標は、ログイン プロセスから摩擦を取り除き、ウェブ、アプリ、デバイスのプラットフォーム全体でエクスペリエンスを簡素化することでした。セキュリティは引き続き最優先事項ですが、プロダクト チームはパスキーによる登録とログインのフローを可能な限りシームレスにすることに注力しました。

これらの課題に対処するため、adidas は Conditional Create を実装してパスワード ユーザーをパスキーに自動的にアップグレードし、Signal API を実装して認証情報を一貫性のある状態に保ちました。また、必要に応じてクロスドメインでの使用をサポートするために、関連するオリジン リクエストもデプロイしました。

結果

パスキーの作成を自動化し、認証情報の健全性を維持するという adidas の戦略は、導入とログインの信頼性の両面で、すぐに測定可能な成果をもたらしました。

  • 高い導入率: パスキー ログイン プロセスを導入して以来、adidas はパスキーの作成率で全体として 47% を達成しています。これには、自動の条件付き作成と、登録またはログイン フローでユーザーがオプトインを求められたときにユーザーが開始したオプトインの両方が含まれます。特にモバイル デバイスでの導入率が高く、コンバージョン率は 52% でした（パソコンでは 34%）。
  • 条件付き作成を使用したアップグレードの加速: adidas は、明示的なプロンプト以外にも、既存のパスワード ユーザーをバックグラウンドでシームレスにアップグレードすることで、手動でのユーザー操作を必要とせずに、パスキーの作成数を 8% 増加させました。
  • ほぼ完璧なログインの信頼性: パスキーは、ログインが開始されると 99% を超える成功率を達成しました。これは、adidas の過去のパスワード成功率 70% と比較して、大幅なセキュリティ強化です。過去のパスワード成功率は、入力ミスや認証情報の忘れなどのヒューマン エラーによって低下することがよくありました。
  • 摩擦とエラーを最小限に抑える: Signal API をデプロイしてデバイスとサーバーの認証情報を自動的に同期することで、adidas は PASSKEY_NOT_FOUND エラーをログイン試行の 0.3% 未満に抑えることに成功しました。これにより、孤立したパスキーによるユーザーの不満を効果的に解消しました。

    47 %

    パスキーの作成率

    8 %

    条件付き作成を使用したパスキー作成の増加

    >99 %

    パスキーによるログインの成功率（開始後）

    <0.3 %

    孤立したパスキーのエラー率

adidas が問題を解決した方法

アディダスは、これらの課題に次のように対処しました。

1. 条件付き作成で導入を加速する

ユーザーがパスキーをシームレスに導入できるように、adidas は条件付き作成を実装しました。この機能を使用すると、ユーザーがパスワード マネージャーに保存されているパスワードでログインしたときに、ウェブサイトでパスキーが自動的に作成されます。成功率を最大限に高めるため、システムはログインが成功した直後に API を呼び出し、システムがパスワードの使用を最近のものとして認識できるようにします。

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

adidas は、この機能をユーザーの環境を最初に検証するカスタム ロジックと統合しました。具体的には、条件付き作成機能がブラウザでサポートされているかどうかをチェックします。また、過去 6 か月間にパスキーの作成を 3 回スキップしたユーザーに対しては、プロンプトが表示されないようにすることで、ユーザーの設定が尊重されます。

環境が互換性がある場合、ユーザー認証が成功するとすぐに、システムはバックグラウンドでパスキーの作成を試みます。このタイミングで実行することで、前提条件が満たされる可能性が高まります。重要なのは、実装が「フェイルオープン」の哲学で WebAuthn 例外を処理し、常にユーザー アクセスを優先することです。ブラウザが InvalidStateError を報告した場合（パスキーがすでに存在している可能性が高いことを示す）、システムはバックグラウンドでの作成を停止し、ユーザーをすぐにログインさせます。逆に、NotAllowedError が発生した場合（自動作成の特定の条件が満たされていない場合）、システムはこの状態を検出し、ユーザーを「パスキー コレクタ」画面に誘導して、手動設定プロセスを案内します。adidas は、これらの技術的な制約とユーザーの行動を区別することで、パスキーのアップグレードの推進がログイン エクスペリエンスを中断するのではなく、向上させることを保証しています。

adidas のウェブサイトに表示される「次回からパスキーでログイン」というプロンプト。生体認証またはパスコードを使用して、より迅速かつ安全にログインするためのパスキーの作成をユーザーに促しています。
「パスキー コレクタ」画面。

2. Signal API で信頼性を確保する

ユーザーがデバイス間で認証情報を管理していると、不整合が生じることがあります。たとえば、パスキーがサーバーから削除されても、ユーザーのデバイスには残っている可能性があります。adidas は、このような「ファントム」認証情報によるログインの失敗を防ぐため、Signal API を実装しました。この API を使用すると、サーバーは認証情報のステータスをパスキー プロバイダに通知できます。

adidas は、この一貫性を維持するために、利用可能な 3 つのシグナル API メソッドをすべて使用しています。削除する認証情報を推測するのではなく、adidas は特定のユーザー ライフサイクル イベントを適切な API 呼び出しにマッピングします。

  • 登録の失敗: クライアントでパスキーが作成されたものの、バックエンドへの登録に失敗した場合、adidas は signalUnknownCredential を使用して、孤立した認証情報を直ちに削除します。
  • 無効なログイン: ユーザーが取り消されたパスキーまたは古いパスキーでログインしようとすると、signalUnknownCredential はプロバイダにそれを非表示にするよう通知します。
  • ユーザー管理: ユーザーがアカウント設定でパスキーを明示的に削除すると、signalAllAcceptedCredentials は許可リストを同期します。これにより、削除されたパスキーが提供されなくなります。
  • アカウントの更新: ユーザーがメールアドレスまたはユーザー名を変更すると、signalCurrentUserDetails はデバイスのメタデータを更新してサーバーと一致させます。
// 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
    });
  }
}
adidas アカウント設定の確認モーダル。ユーザーが特定のパスキーを削除できる。ログインに使用できなくなるという警告が表示される。
パスキーを削除するための確認モーダル。
Google パスワード マネージャーから、機能しなくなった「削除されたパスキー」を示す通知が表示され、Signal API によってユーザーのデバイスがサーバーと同期されている様子が示されています。
削除されたパスキーの Signal API 通知。

マルチマーケット アーキテクチャをさらにサポートするため、adidas は関連するオリジン リクエストを実装しました。ほとんどのユーザーはローカル マーケット（adidas.nl など）を利用しますが、この構成では、リージョン間を移動するユーザーが、単一の証明書利用者 ID（adidas.com）をターゲットにすることで、許可されたドメイン間でパスキーを再利用できます。

これを有効にするため、adidas はプライマリの Relying Party ID（RP ID）ドメインで webauthn 構成ファイルをホストしています。このファイルには、パスキーの登録と認証に adidas.com を使用することが許可されているオリジンの明示的な許可リストが含まれています。これらの関係を定義することで、ブラウザは、ある地域サイトで作成されたパスキーが別の地域サイトでも有効であることを確認し、世界中のユーザーにスムーズなエクスペリエンスを提供できます。

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

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

重要な点として、adidas は Digital Asset Links を使用して、Android モバイルアプリ内でシームレスなパスキー サポートも提供しています。アプリは認証に idp.adidas.com でホストされている WebView を使用しているため、Android アプリと Relying Party ID（adidas.com）の間に信頼関係を確立するために Digital Asset Links が必要でした。この検証により、アプリはウェブで使用されているのと同じパスキーにアクセスできるようになり、プラットフォーム間でスムーズで統一されたログイン エクスペリエンスが実現します。

これを実現するため、アディダスはそれぞれのウェブドメインで Digital Asset Links（assetlinks.json）ファイルをホストしています。このファイルは、Android アプリケーションとの暗号関連付けを公開で宣言します。同様に、iOS エコシステムをサポートするために、adidas は関連付けられたドメインを使用しています。apple-app-site-association ファイルをホストすることで、安全な接続を確立し、iOS アプリで安全にウェブビューでパスキーを使用できるようになります。

// 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
]
クライアント デバイスとターゲット サーバーの間で、関連オリジン リクエスト（ROR）とデジタル アセット リンク（DAL）を介して確立された信頼関係を示す技術的なシーケンス図。
関連するオリジン リクエストのシーケンス図
Android デバイスのシステムレベルのパスキー プロンプト。保存済みのパスキーを使用して adidas ID プロバイダにログインするようユーザーに求めている。
条件付きログイン
adidas モバイルアプリのログイン画面。認証を効率化するための専用の [パスキーで続行] ボタンが表示されています。
ID 優先

アディダスの今後の予定

自動アップグレードと adidas.fi および adidas.nl での同期された認証情報のライブという堅牢な基盤を基に、アディダスは 2026 年 4 月末までに、このシームレスな設定を他のすべてのグローバル市場に展開する予定です。また、adidas は即時メディエーションのオリジン トライアルをテストすることで、さらにスムーズなログイン エクスペリエンスを模索しています。今後、ユーザーがパスキーを使用して直接アカウントを作成できるようにする予定です。これにより、最初に別の方法で登録する必要がなくなります。また、ログインの 2 段階目でシステム パスキー ダイアログを直接呼び出す「スマート トリガー」についても調査しています。これにより、ユーザーが現在のデバイスでパスキーを利用できる可能性が高い場合に、余分なクリックが不要になります。

このたびの対応の目的

パスワードなしの認証への移行が成功するのは、ユーザー エクスペリエンスがシームレスに維持されている場合です。条件付き作成を実装すると、ユーザーの習慣を妨げることなく、パスワードから簡単に移行できます。関連オリジン リクエストを使用すると、これらのパスキーをドメイン間で共有し、ユーザーが 1 つのパスキーでエコシステム全体にシームレスにアクセスできるようにすることができます。最後に、これを Signal API と組み合わせることで、統合されたパスワードレス エクスペリエンスの信頼性とエラーのない状態を維持できます。

その他の情報