このページは Cloud Translation API によって翻訳されました。

FedCM によるシームレスでプライベートなユーザー認証: Seznam の実装

複数の業界のリーダーは、すべてのユーザーに優れたエクスペリエンスを提供しながらプライバシーを保護することの重要性を理解しています。妥協のないユーザーエクスペリエンスとプライバシーの提供に専念している Seznam は、Federated Credential Management（FedCM）の統合に成功しました。

対象となるプロフィール: FedCM のメリットを享受できる企業

さまざまなドメインの組織が FedCM をソリューションに統合しています。フェデレーション ID 管理用に設計された FedCM の主なメリットは、ID プロバイダ（IdP）がログインエクスペリエンスの向上に利用できることです。e コマースサービスプロバイダや決済プロバイダ（多くは ID プロバイダも兼ねています）も、FedCM の実装を通じてユーザーエクスペリエンスを改善できる機会を見出しています。

Seznam

Seznam は、チェコ共和国の人口の 90% にリーチするヨーロッパのテクノロジー企業であり、ID プロバイダです。ソーシャル、知識、コンテンツのハブとして機能します。Seznam は、パートナーのプラットフォームで運営されているオンラインストアの顧客が Seznam アカウントを使用してログインできるように、FedCM を採用しました。

FedCM を導入したことで、Seznam はパートナーのネットワークでのユーザーログイン率を大幅に向上させ、ユーザーエクスペリエンスを改善し、サードパーティ Cookie の利用可否に関係なく一貫した ID フローを実現しました。

目的

Seznam が FedCM の実装を選択した理由は、次のようなメリットがあると考えたからです。

FedCM はエンドユーザーを念頭に置いて設計されており、IdP に提供される情報をユーザーが管理できるようになっています。これは、ユーザーに安全でプライベートな環境を提供するという Seznam のビジョンに沿ったものです。
FedCM は、OAuth 2.0 標準を使用する Seznam の既存のログインエクスペリエンスと互換性のある、ブラウザの組み込み機能です。
FedCM は、ID 連携に対するプライバシーを重視したアプローチとして設計されています。たとえば、ユーザーが RP にアクセスしたという事実は、ユーザーがログインを選択した場合にのみ IdP と共有されます。これは、持続可能なビジネスに関する Seznam の見解と一致しています。

実装の詳細

Seznam は、既存の OAuth ソリューションの上にレイヤとして FedCM を実装しました。このアーキテクチャでは、FedCM フローを使用して、IdP から RP に OAuth 認可コードを安全に送信します。

FedCM トークンが IdP 側で OAuth 認証コードと交換される FedCM フローを示すシーケンス図 — OAuth と統合された FedCM フロー。図のコードをご覧ください。

実装の労力

Seznam は、FedCM の実装は簡単で、既存のアプローチと一致していると述べています。API の調査と実装には 1 か月かかり、2 人のデベロッパーの作業が必要でした。FedCM の本番環境への導入には 2 か月もかかりませんでした。このプロセスは反復的で、API の慎重な調査にかなりの時間を費やしました。

課題

早期導入企業として、Seznam はいくつかの課題を特定し、API の成熟に役立つ貴重なフィードバックを提供しました。

複数の ID プロバイダのサポート

Seznam は、FedCM が複数の ID プロバイダをサポートしていることに注目しました。この機能により、パートナーの RP で Seznam アカウントと Google アカウントのどちらかを選択できるようになります。しかし、Seznam が FedCM の実装に初めて取り組んだとき、この機能は実装の初期段階にあり、デベロッパーはオリジントライアルに登録し、トークンを使用してユーザー向けにこの機能を有効にする必要がありました。そのため、Seznam は Chrome Stable でこの機能がリリースされるまで待つことにしました。

この機能は Chrome 136 以降で利用可能で、デベロッパーは複数の ID プロバイダのサポートを構成できます。たとえば、Seznam と Google の両方の ID プロバイダをサポートするには、IdP は 1 回の get() 呼び出しに両方のプロバイダを含めることができます。RP も同様に、個別に含めることができます。

  // Executed on the RP's side:
    const credential = await navigator.credentials.get({
      identity: {
        providers: [
          {
            // IdP1: Seznam's config file URL
            configURL: 'https://szn.cz/.well-known/web-identity',
            clientId: '123',
          },
          {
            // Also allow Google Sign-in
            configURL: 'https://accounts.google.com/gsi/fedcm.json',
            clientId: '456',
          },
        ],
      },
    });

Seznam は、この機能をソリューションの一部として組み込むことを表明しています。また、FedCM チームは、複数の get() 呼び出しをサポートする複数の SDK のサポートを実装しています。

プライベート DNS

Seznam は、テスト段階でネットワーク構成に関する課題に直面しました。テスト IdP サーバーはプライベートネットワーク内にあり、プライベート DNS 経由でのみアクセス可能でした。この設定は、サービスが一般公開される前の内部テスト環境や開発環境でよく使用されます。

ただし、この設定には問題があります。well-known ファイルは eTLD+1 から提供される必要がありますが、プライベート開発ドメインは Public Suffix List に登録されていないため、ブラウザは開発ドメインでホストされている well-known ファイルを取得するリクエストを送信しません。

login.idp.example: 本番環境ドメインの例。
idp.example/.well-known/web-identity: 本番環境の既知のファイルの例。
login.dev.idp.example: 開発ドメインの例。
login.dev.idp.example/.well-known/web-identity: 開発環境の既知のファイルの例。

FedCM 実装がプライベートドメインでホストされている場合、ブラウザが well-known ファイルをリクエストすると、次のエラーが発生します。

The fetch of the well-known file resulted in a network error: ERR_NAME_NOT_RESOLVED

このエラーは、Chrome の #fedcm-without-well-known-enforcement フラグを有効にすることで解決できます。このフラグが有効になっている場合、ブラウザはテスト目的で well-known ファイルの取得をスキップします。Chrome でテストフラグを有効にする方法をご確認ください。

カスタム情報開示

注意: FedCM を ID プロバイダ（IdP）または Relying Party（RP）として使用する場合、ユーザーの端末機器に情報を保存したり、すでに保存されている情報にアクセスしたりすることになります。これは、欧州経済領域（EEA）と英国の ePrivacy 法の対象となるアクティビティであり、一般的にユーザーの同意が必要となります。ユーザーが明示的にリクエストしたオンラインサービスを提供するために FedCM の使用が厳密に必要であり、したがって同意要件の対象外となるかどうかを判断するのは、お客様の責任となります。詳しくは、プライバシーサンドボックスのプライバシー関連のコンプライアンスに関するよくある質問をご覧ください。

Seznam は、FedCM UI の初期設計に加えて、追加情報も表示したいと考えていることも明らかにしました。標準の FedCM ダイアログには、特定のデータ（通常はユーザーのプロフィール画像、名前、メールアドレス）が RP と共有されることを示す固定メッセージがユーザーに表示されます。

FedCM チームはフィードバックを取り入れ、ユーザーに表示される開示情報をカスタマイズできるように API を拡張しました。たとえば、Continue on 機能を使用すると、IdP はユーザーをカスタムページにリダイレクトして、追加の情報や権限をリクエストできます。Chrome 132 以降でサポートされているカスタムパラメータとフィールドの機能を使用すると、さらにカスタマイズできます。

FedCM 登録を続行するには、ユーザーが追加の権限（この場合は、ドライブファイルとカレンダーの予定の表示とダウンロード）を付与する必要があることを示す IdP ページ。 — ユーザーは、Parameters API を使用して、RP から ID アサーションエンドポイントに渡された追加の権限を確認して付与できます。

証明書利用者のオリジンの検証

IdP サーバーは、受信した FedCM リクエストの Origin HTTP ヘッダーを検証して、リクエストが RP が IdP に事前登録したオリジンと一致することを確認する必要があります。これにより、FedCM の ID アサーションリクエストが、client_id を使用する攻撃者ではなく、承認済みの RP から送信されていることが保証されます。

Seznam には、パートナー RP が Seznam に登録する際に、RP のオリジンデータをリクエストしないというコーナーケースがあります。つまり、RP のオリジンを確認できません。

Seznam の FedCM 統合は、既存の OAuth ソリューションの上に構築されています。このため、オリジンをチェックしなくてもソリューションの安全性を維持できるよう、両方の RP の client_id と client_secret を検証する代替パスが採用されました。

ID プロバイダのユーザー向けドメイン

Seznam のユーザー認証インフラストラクチャは主に szn.cz ドメインで動作しており、FedCM に必要な IdP エンドポイントがホストされています。ただし、主な企業 ID と、ユーザーがサービスを広く認識して信頼しているドメインは seznam.cz です。

FedCM ダイアログには、IdP エンドポイントの実際のオリジンドメイン（この場合は szn.cz）が表示されます。seznam.cz ブランドに慣れているユーザーは、ログインプロセス中にあまり馴染みのない szn.cz ドメインでログインするよう求められると、混乱して躊躇する可能性があります。

Chrome 141 以降では、FedCM で IdP 実装をホストしているドメインとは異なるドメインを表示することはできません。この制限は、ユーザーの透明性を確保することを目的とした意図的な設計上の選択です。ただし、FedCM チームは、この制限によって生じる可能性のある課題を認識しており、潜在的な調整について議論しています。

影響

FedCM API を使用することで、Seznam はパートナーのユーザーにシングルタップ認証フローを提供できるようになりました。他の認証方法と比較して、FedCM の UX が提供するメリットを強調しました。

Seznam は、FedCM ログインに移行したウェブサイトでユーザーエンゲージメントが大幅に増加したことを確認しましたが、他の要因から直接的な影響を正確に分離するための包括的な分析は実施していません。FedCM 統合の前は、ユーザー識別に同意済みのハッシュ化されたメールアドレスを使用して、ゲスト購入を許可する実装でした。このような分析を行ううえでの課題は、ユーザーのコンバージョンが FedCM に起因するものなのか、それともゲスト購入によって完了したのかを推定することでした。Seznam の仮説では、FedCM の使いやすさの向上により、コンバージョン率が向上した可能性があるとしています。

まとめ

Seznam は FedCM を実装し、既存の OAuth ソリューションに加えて代替の認証フローを提供することに成功しました。Seznam のデベロッパーは、ID プロバイダのサポート、プライベート DNS の設定、開示テキストのカスタマイズ、証明書利用者オリジンの検証、ユーザー向けのドメイン表示に関連する課題に直面しましたが、API は実装以降成熟しています。FedCM チームは、Seznam などの早期導入者からのフィードバックを取り入れ、これらの課題を解決するためのより優れたツールを開発しました。次のステップとして、Seznam は複数の ID プロバイダに対する FedCM のサポートを実装する予定です。