アドプライバシーQ&A

Federated Credential Management API (FedCM) の技術仕様：ポストCookie時代のID連携とプライバシー保護

Tags: FedCM, ID連携, Privacy Sandbox, ポストCookie, ウェブ標準, プライバシー保護

Federated Credential Management API (FedCM) とは何か、ポストCookie時代のID連携におけるその役割について解説します。

Federated Credential Management API (FedCM) は、クロスサイトトラッキングを可能にするサードパーティCookieに依存せずに、ウェブサイト（Relying Party, RP）がアイデンティティプロバイダー（Identity Provider, IdP）を通じてユーザー認証を行うための新しいウェブ標準APIです。これは、主要なブラウザによるサードパーティCookieの廃止が進む中で、ログインやID連携といったウェブの基本的な機能を持続可能な形で提供するために開発が進められています。

従来のID連携は、主にOAuthやOpenID Connectといったプロトコルを利用し、ユーザーの認証状態を維持するためにサードパーティCookieやローカルストレージなどを利用していました。しかし、ブラウザのプライバシー保護機能強化により、これらのストレージメカニズムが制限され、クロスサイトでの認証状態維持が困難になっています。FedCMは、ブラウザをIdPとRPの間の仲介役とすることで、サードパーティCookieに依存しない安全かつプライバシーに配慮したID連携フローを提供します。

FedCMの主要な技術仕様とAPI構成について詳細を説明します。

FedCMは、いくつかの主要な要素で構成されています。

  1. Relying Party (RP): ユーザーがログインしようとしているウェブサイトです。FedCM APIを呼び出します。
  2. Identity Provider (IdP): ユーザーのアカウント情報を管理し、認証を行うサービスです。FedCMで定義される特定のHTTPエンドポイントを提供する必要があります。
  3. Browser: RPとIdPの間で情報のやり取りを仲介し、ユーザーインターフェースを表示します。

FedCMの基本的なフローは以下のようになります。

  1. RPのウェブサイトで、ログインが必要な場面で navigator.credentials.get() メソッドを呼び出します。この際、IdPのオリジンや提供する認証フローに関する情報（identity オプション）を指定します。
  2. ブラウザは、ユーザーが過去にそのIdPを利用してRPにログインしたことがあるか、また現在IdPにログインしているかなどを確認します。
  3. ブラウザは、ユーザーにFedCMのログインUIを表示します。このUIはブラウザによって提供され、ユーザーはどのIdPアカウントでRPにログインするかを選択できます。これにより、IdPやRPがユーザーのログイン操作を直接トラッキングすることを防ぎます。
  4. ユーザーがアカウントを選択し同意すると、ブラウザは指定されたIdPのHTTPエンドポイントにフェッチリクエストを送信し、IdPから認証コードやIDトークンなどのクレデンシャルを取得します。
  5. IdPは、ブラウザからのリクエストに応じてクレデンシャルを返却します。この通信はブラウザを介して行われ、RPは直接IdPと通信せず、ブラウザからクレデンシャルを受け取ります。
  6. ブラウザは取得したクレデンシャルをRPの navigator.credentials.get() 呼び出しの結果として返します。
  7. RPは受け取ったクレデンシャル（例えばIDトークン）を自身のバックエンドに送信し、検証後にユーザーのログインを完了させます。

FedCMに関連する主なAPIやエンドポイントは以下の通りです。

これらのエンドポイントを介した通信は、ブラウザによって厳密に制御され、不要なユーザー情報の漏洩を防ぐように設計されています。

FedCMがプライバシー保護にどのように寄与するか、技術的観点から考察します。

FedCMの設計思想は、サードパーティCookieに依存しないクロスサイトID連携を実現しつつ、ユーザーのプライバシーを最大限に保護することにあります。そのプライバシー保護メカニズムは主に以下の点に集約されます。

  1. ブラウザによる仲介とUI提供: IdPとRP間の直接的な通信を避け、ブラウザが仲介します。特に、ログインUIはブラウザ自身が描画・制御します。これにより、IdPやRPがユーザーの閲覧履歴やログイン試行を勝手に追跡し、クロスサイトでユーザーを紐付けることを技術的に困難にしています。例えば、ユーザーがRPサイトを訪問した際に、ブラウザはIdPに自動的にアカウント情報を問い合わせるのではなく、RPからのFedCM API呼び出しを受けて初めて、ユーザーの明示的な許可や過去の利用状況に基づいて、限定的な情報（例えばログイン状態を示すフラグ）をIdPに問い合わせるかどうかを判断します。
  2. 限定的な情報交換: FedCMフローで交換される情報は、ID連携に必要な最小限の情報に限定されます。IdPはRPサイト上でのユーザーのアクティビティを直接観測できませんし、RPはIdPからユーザーの完全なプロフィール情報などを勝手に取得できません。IDトークンなどのクレデンシャルは、ユーザーの同意に基づいてブラウザを介して安全にRPに渡されます。
  3. SameParty Cookie (CHIPS) との連携: FedCMの内部実装において、ブラウザはIdPのオリジンが利用する特定のCookieを、Strict SameParty Cookie (CHIPS) のセマンティクスで扱うことがあります。これにより、同じトップレベルサイト（例: example.com）内で複数のサブドメイン（IdP: accounts.example.com, RP: shop.example.com）が連携する場合でも、これらのCookieが意図せずクロスサイトトラッキングに利用されることを防ぎます。CHIPSは、Partitioned 属性を持つCookieであり、トップレベルサイトごとにパーティション化されます。
  4. ログイン状態の緩和されたチェック: ブラウザは、ユーザーが特定のIdPにログインしているかどうかのチェックを、限定的な方法でのみ行います。これにより、IdPがユーザーがどのRPサイトを訪問したかをパッシブに知ることを防ぎます。具体的には、ブラウザは特定のAPI呼び出しがあった場合にのみ、限定的なタイミングでIdPのログイン状態をチェックし、その結果をIdPに伝える際にも詳細なコンテキスト情報は含めません。
  5. Logout Notification: FedCMを介して確立されたセッションについて、ユーザーがIdPまたはRPでログアウトした場合、ブラウザがもう一方にその状態を通知するメカニズムが検討されています。これにより、セッションの状態を適切に管理しつつ、不必要なログイン状態の問い合わせを防ぎます。

これらの技術的な仕組みにより、FedCMは従来のID連携技術に比べて、ユーザーのオンライン活動全体を通じた追跡のリスクを大幅に低減し、プライバシーに配慮したログイン体験を提供します。

FedCMの実装における考慮事項と広告分野への潜在的な影響について考察します。

FedCMの実装は、IdPとRP双方にとって技術的な対応が必要です。

IdP側の考慮事項: * FedCM仕様に準拠した各種HTTPエンドポイント（Configuration, Accounts, ID Assertionなど）を実装する必要があります。 * これらのエンドポイントは、セキュリティと可用性が高く求められます。 * 既存の認証システムとの連携を考慮する必要があります。特に、既存のセッション管理やトークン発行プロセスをFedCMフローに組み込む設計が必要です。 * ブラウザによって表示されるUIの制御は限られるため、ユーザー体験設計においてはブラウザのUIを前提とする必要があります。

RP側の考慮事項: * 既存のログインボタンやフローを、navigator.credentials.get({ identity: ... }) の呼び出しに置き換える必要があります。 * FedCMから返されるクレデンシャル（通常はIDトークン）の検証と、それに基づくユーザーセッションの確立ロジックを実装する必要があります。 * FedCMがサポートされていないブラウザや状況（例: ユーザーがAPIをブロックしている場合）のためのフォールバックメカニズムを用意する必要があります。 * FedCMは非同期APIであるため、ユーザーがログインUIで操作を完了するまでの間に、RPのUIがフリーズしないように配慮が必要です。 * 同一サイト内の異なるオリジン間での連携（例: example.com と login.example.com）の場合、CHIPSなどの関連技術の理解も重要です。

広告分野への潜在的な影響: FedCMは直接的に広告ターゲティングや効果測定のためのAPIではありません。しかし、ポストCookie時代において、ウェブサイト上でのユーザーID管理の重要な要素となり得ます。

ただし、FedCMはクロスサイトトラッキングを意図的に困難にする設計であるため、IdPがユーザーのサイト訪問履歴を基にクロスサイトで詳細なプロファイルを構築し、それを広告目的で利用するといった従来のサードパーティCookieに依存した手法は、FedCMでは実現できません。広告分野への応用は、あくまでファーストパーティコンテキストやユーザーが明示的に同意した範囲でのID連携に基づいたものに限定されると考えられます。

将来的な展望と関連するWeb標準について

FedCMはまだ進化の途上にある仕様です。W3CのFedID (Federated Identity) Community Group および Working Groupで議論が進められており、今後も仕様の改訂や機能追加が行われる可能性があります。例えば、ブラウザによるより柔軟なUI制御のオプション、複数デバイス間での連携のサポート、より多様な認証フローへの対応などが検討課題となり得ます。

また、FedCMはポストCookie時代のウェブエコシステムにおけるプライバシー保護と機能性の両立を目指す取り組みの一つです。Privacy Sandboxの他のAPI群（Topics, Protected Audience, Attribution Reportingなど）は広告配信や効果測定に焦点を当てていますが、FedCMはより一般的なID連携の課題に対処するものです。これらはそれぞれ異なるレイヤーの課題を解決する技術ですが、ユーザーがウェブを安全かつ便利に利用できる環境を構築するという共通の目標を持っています。

技術専門家としては、FedCMの仕様の動向を注視し、IdPとRP双方での実装要件を深く理解することが求められます。ポストCookie時代において、ユーザー中心のプライバシー保護設計は不可欠であり、FedCMはその実現に向けた重要な構成要素の一つとなるでしょう。

まとめ

Federated Credential Management API (FedCM) は、サードパーティCookieに依存しないプライバシー配慮型のクロスサイトID連携を可能にするウェブ標準APIです。ブラウザがIdPとRPの間で仲介し、ユーザーインターフェースを制御することで、不要なユーザー追跡を防ぎます。技術仕様としては、RP側のJavaScript API呼び出しと、IdP側で提供すべき複数のHTTPエンドポイントが定義されています。そのプライバシー保護メカニズムは、ブラウザ仲介、情報交換の限定、CHIPSとの連携など多岐にわたります。ポストCookie時代のID連携維持に不可欠な技術であり、ログインベースのファーストパーティデータ活用や、他のプライバシー保護技術との連携において広告分野にも間接的な影響を与え得ます。W3Cでの仕様策定が進んでおり、その動向を継続的に追跡し、技術的な理解を深めることが、プライバシー重視のアドテク開発・コンサルティングにおいては重要となります。