Federated Credential Management API

# 実装ステータス

このドキュメントでは、ID 連携の新しい提案である Federated Credential Management API（FedCM）の概要を説明します。

• FedCM の提案は公開ディスカッションを進行中です。
• FedCM は Chrome 108 で出荷されます。
• FedCM は他のブラウザではまだサポートされていませんが、Mozilla は Firefox にプロトタイプを実装しています 。Apple は、FedCM の提案に協力することに全般的な支持と関心を表明しています。
• Chrome プラットフォームのステータス

今後は、ID プロバイダー（IdP）、リライングパーティー（RP）、およびブラウザベンダーから受け取ったフィードバックに基づいて、多数の新機能を導入する予定です。ID プロバイダーが FedCM を採用することを願っていますが、FedCM はまだ開発中の API であり、2023 年第 4 四半期まで下位互換性のない変更が予想されることに注意してください。

下位互換性のない変更をデプロイする際の課題を最小限に抑えるために、現在、ID プロバイダーに対し 2 つの推奨事項があります。

• API の進化に合わせて更新情報をお送りするニュースレターを購読してください。
• API が成熟するまでは、IdP が JavaScript SDK を介して FedCM API を配布し、RP はセルフホスティング SDK を使用しないようにすることをお勧めします。これにより、IdP は API の進化に合わせて変更を加えることができ、すべてのリライングパーティーに再デプロイを依頼する必要がなくなります。

# FedCM が必要な理由

過去 10 年間、ID 連携は、サイトごとのユーザー名とパスワードを使用した方法に比べ、信頼性、使いやすさ（パスワードレスのシングルサインインなど）、およびセキュリティ（フィッシングやクレデンシャルスタッフィング攻撃への耐性の向上など）の観点から、ウェブでの認証の基準を引き上げる上で中心的な役割を果たしてきました。

ID 連携では、RP（リライングパーティー）は IdP（ID プロバイダー）に依存して、新しいユーザー名とパスワードを作成することなくユーザーにアカウントを提供することができます。

残念ながら、ID 連携が依存してきた仕組み（iframe、リダイレクト、および Cookie）は、ウェブ全体でユーザーを追跡する方法として活発に悪用されています。ユーザーエージェントは ID 連携と追跡を区別できないため、さまざまな種類の悪用を軽減する取り組みが ID 連携の展開をより困難にしています。

Federated Credential Management API（FedCM）は、ユーザーが IdP からアカウントを選択してウェブサイトにログインできるようにするブラウザ経由のダイアログを公開することで、ウェブ上の ID 連携フローのユースケース固有の抽象化を提供します。

FedCM は、ウェブ上の ID を改善するための複数のステップからなるプロセスであり、その最初のステップでは、ID 連携に対するサードパーティ Cookie の段階的廃止の影響を軽減することに重点を置いています（この先のいくつかのステップについては、ロードマップのセクションをご覧ください）。

# 期待される影響

コミュニティの取り組みと私たちの調査を通じて、サードパーティ Cookie の段階的廃止の影響を受ける ID 連携関連の統合がいくつかあることがわかりました。

• OpenID Connect フロントチャンネルのログアウト
• OpenID Connect セッション管理
• iframe ベースのバックグラウンドトークンの更新
• iframe ベースのログインウィジェット

FedCM の最初の目標は、サードパーティ Cookie の段階的廃止が ID 連携に与える影響を減らすことです。上記は、影響を受けると予想される領域のリストです。その他のユースケースでリストに含まれていないものがある場合は、貢献とフィードバックの共有をお勧めします。

# FedCM の推奨使用対象者

以下のすべての条件に該当する場合にのみ、FedCM が役立つと考えています。

1. ID プロバイダー（IdP）である
2. サードパーティ Cookie の段階的廃止の影響を受ける
3. RP がサードパーティである。 使用している RP が SameParty である場合、First-Party Sets での配信が適している可能性があります。

# IdP である場合

FedCM には、ID プロバイダーのサポートが必要です。RP は、FedCM を単独で使用することはできません。RP の場合は、IdP に指示を仰ぎましょう。

# サードパーティ Cookie の段階的廃止の影響を受ける場合

現在の統合がサードパーティ Cookie の段階的廃止の影響を受ける場合にのみ、FedCM を使用してください。

Chrome のサードパーティ Cookie が段階的に廃止された後も ID 連携が引き続き機能するかどうかわからない場合は、シークレットモードでウェブサイトでの統合への影響をテストすることができます。 または、デスクトップの場合は chrome://settings/cookies で、モバイルの場合は設定 > サイト設定 > Cookie に移動して、サードパーティ Cookie をブロックすることができます。

サードパーティ Cookie を使用しなくても ID 連携への影響が検出されない場合は、FedCM を使用せずに、現在の統合を引き続き使用できます。

確認すべき内容がわからない場合は、段階的廃止による影響が期待される既知の機能について詳しくお読みください。

# RP がサードパーティである場合

RP が IdP と同じパーティ内にある ID プロバイダーの場合は、First-Party Sets の方が適していると考えられます。First-Party Sets を使用すると、同じエンティティが所有して運用する関連ドメイン名が、同じファーストパーティに属していると宣言できます。これにより、サードパーティ Cookie が段階的に廃止された後でも、同じパーティのサードパーティ Cookie が機能します。

First-Party Sets は常に使用できるわけではありませんが、RP が SameParty の場合は、First-Party Sets の使用を検討してください。

# ユーザーと FedCM の対話

現在、FedCM の主な焦点は、サードパーティ Cookie の段階的廃止の影響を軽減することです。ユーザーは、 Chrome のユーザー設定で FedCM を有効または無効にできます。

FedCM はプロトコルに依存しないように設計されており、次の認証関連機能を提供します。

• RP へのサインインに、ID プロバイダーを使用する

仕組みについては、デモを確認してください。

# RP にサインインする

ユーザーがリライングパーティー（RP）のウェブサイトにアクセスすると、ユーザーが IdP にサインインしている場合は FedCM サインインダイアログが表示されます。

ユーザーが IdP を使用する RP にアカウントを持っていない場合、サインアップ ダイアログが表示され、RP の利用規約やプライバシーポリシー（提供されている場合）などの追加の開示テキストが表示されます。

ユーザーは Continue as...（...として続行）をタップしてサインインを完了できます。成功した場合、ブラウザは、ユーザーが IdP を使用して RP でアカウント連携を作成したという事実を保存します。

RP は、FedCM をサポートしていないブラウザで動作することが期待されています。ユーザーは、FedCM 以外の既存のサインイン プロセスを使用できる必要があります。FedCM でのサインインの仕組みの詳細についてさらにご覧ください。

# FedCM を有効化または無効化する設定

ユーザーは Android の Chrome の設定で FedCM を有効または無効にできます。設定 > サイトの設定 > サードパーティのサインインに移動し、トグルを変更します。

デスクトップの Chrome では、chrome://settings/content/federatedIdentityApi で同じ操作を行えます。

# ロードマップ

FedCM に多くの変更を加える作業を進めています。

IdP、RP、ブラウザベンダーから寄せられた問題点など、まだ解決しなければならないことはいくつかありますが、これらの問題を解決できると信じています。

• クロスオリジン iframe のサポート: IdP は、クロスオリジン iframe 内から FedCM を呼び出すことができます。
• パーソナライズされたボタン: IdP は、IdP が所有するクロスオリジン iframe 内のサインインボタンに、再度アクセスしたユーザーの ID を表示できます。
• Metrics エンドポイント: IdP にパフォーマンス指標を提供します。

また、評価中またはプロトタイプ作成中の特定の提案を含め、活発に調査を進めている未解決の問題があります。

• CORS: FedCM フェッチの仕様を確実に改善するために、Apple と Mozilla と話し合っています。
• Multiple-IdP API: FedCM アカウントのチューザーで複数の IdP が協調して共存できるようにする方法を検討しています。
• IdP Sign-in Status API: Mozilla はタイミング攻撃の問題を特定しました。私たちは IdP がユーザーのサインイン ステータスをブラウザにプロアクティブに通知することで問題を軽減していく方法を検討しています。
• IdP へのサインイン API: さまざまなシナリオをサポートできるよう、ブラウザは、ユーザーが IdP にサインインしていない場合に、ユーザーが RP を離れずにサインインするための UI を提供します。

最後に、Mozilla、Apple、および TAG のレビュー担当者からのフィードバックに基づき、まだ実行する必要があると思われることがいくつかあります。私たちは、これらの未解決の問題に対する最善の解決策を評価する取り組みを続けています。

• ユーザーの理解と一致する意図の改善: Mozilla が指摘したように、さまざまな UX の定式化とサーフェスエリア、およびトリガー基準を引き続き調査したいと考えています。
• 個人属性と選択的開示: TAG レビュー担当者が指摘したように、多かれ少なかれ個人属性（メール、年齢層、電話番号など）を選択的に共有するメカニズムを提供したいと考えています。
• プライバシー プロパティの引き上げ: Mozilla がここで提案したように、IdP ブラインドネスや有向識別子など、より優れたプライバシー保証を提供するメカニズムを引き続き調査したいと考えています。
• WebAuthn との関係: Appleが提案したように、パスキーの進歩を確認し、FedCM、パスワード、WebAuthn、および WebOTP の間で首尾一貫したまとまりのあるエクスペリエンスを提供することに取り組むことに非常にワクワクしています。
• ログイン ステータス: Apple がプライバシー CG の Login Status APIで提案したように、ユーザーのログイン ステータスは、ブラウザが十分な情報に基づいて決定を下すのに役立つ有用な情報であるという直感を共有しており、そこからどのような機会が生まれるか楽しみにしています。
• エンタープライズと教育: FedID CG で明らかなように、FedCM では十分に対応できない多くのユースケースがあり、私たちが取り組みたいと考えています。
  フロントチャンネル ログアウト（IdP がシグナルを RP に送信してログアウトする機能）、SAML のサポートなどです。
• mDL、VC 等との関係: Mobile Document Request API など、FedCM 内でこれらがどのように適合するかを理解するために引き続き作業します。

# FedCM の開発方法

FedCM を使用するには、Chrome の IdP と RP の両方で安全なコンテキスト（HTTPS または localhost）が必要です。

# Android 上の Chrome でコードをデバッグする

サーバーをローカルでセットアップして実行し、FedCM コードをデバッグします。ポートフォワーディング付きの USB ケーブルを使用して接続された Android デバイスの Chrome で、このサーバーにアクセスできます。

デスクトップで DevTools を使用して Android 上の Chrome をデバッグするには、「 Android デバイスのリモートデバッグ」の手順に従います。

# FedCM API を使用する

well-known ファイルと設定ファイル、そしてアカウントリスト、アサーション発行、オプションでクライアントメタデータのエンドポイントを作成することにより、FedCM と統合します。

そこから、FedCM は、RP が IdP でサインインするために使用できる JavaScript API を公開します。

# well-known ファイルを作成する

トラッカーによる API の悪用を防ぐには、IdP の eTLD+1 の /.well-known/web-identity から well-known ファイルを提供する必要があります。

たとえば、IdP エンドポイントが https://accounts.idp.example/ で配信されている場合、https://idp.example/.well-known/web-identity の well-known ファイルと IdP 設定ファイルを配信する必要があります。以下は、well-known ファイルの例です。

{
  "provider_urls": ["https://accounts.idp.example/config.json"]
}

JSON ファイルには、RP によって navigator.credentials.get の configURL のパス部分として指定できる IdP 設定ファイルURL の配列を持つ provider_urls プロパティが含まれている必要があります。配列内の URL 文字列の数は 1 つに制限されていますが、これは今後の皆さんからのフィードバックによって変更される可能性があります。

# IdP 設定ファイルとエンドポイントを作成する

IdP 設定ファイルには、ブラウザに必要なエンドポイントのリストがあり、IdP は、この設定ファイルと必要なエンドポイントをホストします。すべての JSON レスポンスは、application/json コンテンツ タイプで提供する必要があります。

設定ファイルの URL は、RP で実行される navigator.credentials.get呼び出しに提供される値によって決定されます。

const credential = await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: 'https://accounts.idp.example/config.json',
      clientId: '********',
      nonce: '******'
    }]
  }
});
const { token } = credential;

IdP 設定ファイルの場所の完全な URL を configURL として指定します。navigator.credentials.get() が RP で呼び出されると、ブラウザは Origin ヘッダーや Referer ヘッダーなしで GET リクエストを使用して設定ファイルをフェッチします。リクエストには Cookie がなく、リダイレクトに従いません。これにより、誰がリクエストを行い、どの RP が接続を試みているかを IdP が知ることを効果的に防ぎます。次に例を示します。

GET /config.json HTTP/1.1
Host: accounts.idp.example
Accept: application/json
Sec-Fetch-Dest: webidentity

ブラウザは、次のプロパティを含む IdP からの JSON レスポンスを期待します。

IdP からのレスポンス本文の例を次に示します。

{
  "accounts_endpoint": "/accounts.php",
  "client_metadata_endpoint": "/client_metadata.php",
  "id_assertion_endpoint": "/assertion.php",
  "branding": {
    "background_color": "green",
    "color": "0xFFEEAA",
    "icons": [{
      "url": "https://idp.example/icon.ico",
      "size": 25
    }]
  }
}

ブラウザが設定ファイルをフェッチしたら、後続のリクエストが IdP エンドポイントに送信されます。

# アカウントリストエンドポイント

IdP のアカウントリストエンドポイントは、ユーザーが現在 IdP にサインインしているアカウントのリストを返します。 IdP が複数のアカウントをサポートしている場合、このエンドポイントはサインインしているすべてのアカウントを返します。

ブラウザは、cookie を含む GET リクエストを送信しますが、client_idパラメーター、 Origin ヘッダーや Referer ヘッダーは使用しません。これにより、ユーザーがサインインしようとしている RP を IdP が知ることを効果的に防止します。次に例を示します。

GET /accounts.php HTTP/1.1
Host: accounts.idp.example
Accept: application/json
Cookie: 0x23223
Sec-Fetch-Dest: webidentity

ブラウザは、次のプロパティを持つアカウント情報の配列を持つ accounts プロパティを含む JSON レスポンスを期待します。

レスポンス本文の例:

{
 "accounts": [{
   "id": "1234",
   "given_name": "John",
   "name": "John Doe",
   "email": "john_doe@idp.example",
   "picture": "https://idp.example/profile/123",
   "approved_clients": ["123", "456", "789"],
  }, {
   "id": "5678",
   "given_name": "Johnny",
   "name": "Johnny",
   "email": "johnny@idp.example",
   "picture": "https://idp.example/profile/456"
   "approved_clients": ["abc", "def", "ghi"],
  }]
}

ユーザーがサインインしていない場合は、HTTP 401 (Unauthorized) で応答します。

返されたアカウントリストはブラウザによって消費され、RP は使用できません。

# クライアントメタデータエンドポイント

IdP のクライアントメタデータエンドポイントは、RP のプライバシーポリシーや利用規約などのリライングパーティーのメタデータを返します。RP は、事前に IdP にプライバシーポリシーと利用規約へのリンクを提供する必要があります。これらのリンクは、ユーザーがまだ IdP を使用して RP に登録していない場合に、サインイン ダイアログに表示されます。

ブラウザは、Cookie なしで client_id navigator.credentials.get を使用して GET リクエストを送信します。次に例を示します。

GET /client_metadata.php?client_id=1234 HTTP/1.1
Host: accounts.idp.example
Origin: https://rp.example/
Accept: application/json
Sec-Fetch-Dest: webidentity

クライアントメタデータエンドポイントのプロパティは次のとおりです。

ブラウザは、エンドポイントからの JSON レスポンスを期待します。

{
  "privacy_policy_url": "https://rp.example/privacy_policy.html",
  "terms_of_service_url": "https://rp.example/terms_of_service.html",
}

返されたクライアントメタデータはブラウザによって消費され、RP は使用できません。

# ID アサーションエンドポイント

IdP の ID アサーション エンドポイントは、サインインしているユーザーのアサーションを返します。ユーザーが navigator.credentials.get() 呼び出しを使用して RP のウェブサイトにサインインすると、ブラウザは application/x-www-form-urlencoded の Cookie とコンテンツタイプapplication/x-www-form-urlencoded を含む POST リクエストを、次の情報と共にこのエンドポイントに送信します。

HTTP ヘッダーの例:

POST /assertion.php HTTP/1.1
Host: accounts.idp.example
Origin: https://rp.example/
Content-Type: application/x-www-form-urlencoded
Cookie: 0x23223
Sec-Fetch-Dest: webidentity

account_id=123&client_id=client1234&nonce=Ct60bD&disclosure_text_shown=true

サーバー上で、IdP は次のことを確認する必要があります。

1. 要求されたアカウント ID が、既にサインインしているアカウントの ID と一致していること。
2. Origin ヘッダーが、所定のクライアント ID に対して事前に登録された RP のオリジンと一致すること。

ブラウザは、次のプロパティを含む JSON レスポンスを期待します。

{
  "token": "***********"
}

返されたトークンはブラウザによって RP に渡されるため、RP は認証を検証できます。

# ID プロバイダーを使って RP にサインインする

IdP の構成とエンドポイントが利用可能になると、RP は navigator.credentials.get()を呼び出して、ユーザーが IdP を使用して RP にサインインできるように要求できます。

API を呼び出す前に、[ユーザーのブラウザーで FedCM が利用可能であること] を確認する必要があります。FedCM が利用可能かどうかを確認するには、次のコードを FedCM 実装にラップします。

if ('IdentityCredential' in window) {
  // If the feature is available, take action
}

ユーザーが RP から IdP にサインインできるように要求するには、たとえば次のようにします。

const credential = await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: 'https://accounts.idp.example/config.json',
      clientId: '********',
      nonce: '******'
    }]
  }
});
const { token } = credential;

providers プロパティは、次のプロパティを持つ IdentityProvider オブジェクトの配列を受け取ります。

ブラウザは、アカウントリストエンドポイントからのレスポンス内の approved_clients の有無に応じて、サインアップとサインインのユース ケースを異なる方法で処理します。clientId が approved_clients から提供されていないか RP の clientId に含まれておらず、ユーザーがこのブラウザで過去に RP にサインアップしたことが場合、ブラウザはダイアログに RP のプライバシーポリシーと利用規約のみを表示します。

RP が navigator.credentials.get() を呼び出すと、その次のアクティビティが発生します。

1. ブラウザはリクエストを送信し、いくつかのドキュメントを取得します。
   1. エンドポイントを宣言する well-known ファイルと IdP 設定ファイル。
   2. アカウントリスト。
   3. オプション: クライアントメタデータエンドポイントから取得した RP のプライバシーポリシーと利用規約の URL。
2. ブラウザには、ユーザーがサインインに使用できるアカウントのリストと、利用可能な場合は利用規約とプライバシーポリシーが表示されます。
3. ユーザーがサインインするアカウントを選択すると、ID アサーションエンドポイントへのリクエストが IdP に送信され、トークンが取得されます。
4. RP はトークンを検証してユーザーを認証できます。

トークンが RP サーバーによって検証されると、RP はユーザーを登録するか、サインインさせて新しいセッションを開始できるようにします。

# 貢献とフィードバック

• GitHub: 提案を読み、イシューを投稿したり、ディスカッションを閲覧したりできます。
• 開発者サポート: Privacy Sandbox Developer Support リポジトリでは、質問したり、ディスカッションに参加したりできます。