サードパーティ Cookie は、ブラウザの制限、ユーザー設定、デベロッパー フラグ、エンタープライズ ポリシーによってブロックされることがあります。
サードパーティ Cookie を使用できるかどうかに関係なく、サイトやサービスでユーザーに優れたエクスペリエンスを提供する必要があります。
このページでは、影響を受ける可能性が最も高い ID シナリオと、考えられる解決策について説明します。
ウェブサイトで同じドメインとサブドメイン（publisher.example や login.publisher.example など）内のフローのみを処理している場合、クロスサイト Cookie は使用されず、ログインフローがサードパーティ Cookie の変更の影響を受けることはありません。
ただし、サイトでログインに別のドメイン（Google ログインや Facebook ログインなど）を使用している場合や、複数のドメインやサブドメインでユーザー認証を共有する必要がある場合は、サイトを修正してクロスサイト Cookie からスムーズに移行する必要がある可能性があります。
一般的なユーザー ジャーニー
これまで、多くの ID ワークフローはサードパーティ Cookie に依存していました。次の表に、一般的なユーザー ジャーニーと、サードパーティ Cookie に依存しない各ジャーニーの潜在的なソリューションを示します。以降のセクションでは、これらの推奨事項の理由について説明します。
一般的なユースケースにおすすめの代替 API
が付いている API は、表に記載されている機能は、開発の初期段階にあります。皆様からのフィードバックは、今後の改善に役立てられます。これらの API（パーティション分割されたポップイン）についてご意見をお寄せください。
| ユーザー ジャーニー | 推奨 API |
|---|---|
| ソーシャル ログイン |
ID プロバイダの場合: FedCM を実装します。 証明書利用者（RP）の場合: ID プロバイダにお問い合わせください。 |
|
ID プロバイダまたはカスタム ソリューションの場合: 関連ウェブサイト セット |
|
| ユーザー プロファイルの管理 |
Storage Access API 関連ウェブサイト セット CHIPS FedCM + SAA |
|
Storage Access API 関連ウェブサイト セット CHIPS FedCM + SAA |
|
| 認証 |
Storage Access API FedCM Web Authentication API scienceパーティション分割されたポップイン |
| これらのシナリオは通常、サードパーティ Cookie の依存関係がなく、影響を受けないことが予想されます。 |
ID 関連のユーザー ジャーニーをテストする
ログインフローがサードパーティ Cookie の変更の影響を受けるかどうかをテストする最善の方法は、サードパーティ Cookie のテストフラグを有効にした状態で、登録、パスワードの再設定、ログイン、ログアウトのフローを試すことです。
サードパーティ Cookie を制限した後に確認すべき事項のチェックリストは次のとおりです。
- ユーザー登録: 新しいアカウントの作成は正常に機能します。サードパーティの ID プロバイダを使用している場合は、すべての統合で新しいアカウントの登録が機能することを確認します。
- パスワードの再設定: ウェブ UI から CAPTCHA、パスワード再設定メールの受信まで、パスワードの再設定が想定どおりに機能します。
- ログイン: ログイン ワークフローは、同じドメイン内と他のドメインに移動するときに機能します。すべてのログイン統合をテストしてください。
- ログアウト: ログアウト プロセスが想定どおりに動作し、ログアウト フローの後にユーザーがログアウトしたままになる。
また、クロスサイト Cookie を必要とする他のサイト機能が、クロスサイト Cookie なしでも機能することを確認する必要があります。特に、クロスサイト リソースの読み込みを伴う場合は、この確認が重要です。たとえば、CDN を使用してユーザー プロフィール画像を読み込む場合は、この処理が引き続き機能することを確認します。ログインでゲートされている購入手続きなどの重要なユーザー ジャーニーがある場合は、それらが引き続き機能することを確認します。
ログイン ソリューション
このセクションでは、これらのフローがどのように影響を受けるかについて、より具体的な情報を提供します。
サードパーティのシングル サインオン（SSO）
サードパーティのシングル サインイン（SSO）を使用すると、ユーザーは 1 つのプラットフォームで単一の認証情報セットを使用して認証し、ログイン情報を再入力することなく複数のアプリケーションやウェブサイトにアクセスできます。SSO ソリューションの実装は複雑であるため、多くの企業はサードパーティのソリューション プロバイダを利用して、複数のオリジン間でログイン状態を共有しています。プロバイダの例としては、Okta、Ping Identity、Google Cloud IAM、Microsoft Entra ID などがあります。
ソリューションがサードパーティ プロバイダに依存している場合は、ライブラリのアップグレードなどの軽微な変更が必要になる可能性があります。最適な方法は、サードパーティ Cookie の依存関係がソリューションにどのように影響するか、また、サービスに推奨されるアプローチについて、プロバイダにガイダンスを求めることです。一部のプロバイダはサードパーティ Cookie からサイレントに移行するため、その場合は RP は更新する必要がありません。
複数ドメイン
一部のウェブサイトでは、同一サイト Cookie の対象とならないユーザーの認証にのみ別のドメインを使用しています。たとえば、メインサイトに example.com を使用し、ログインフローに login.example を使用しているウェブサイトでは、両方のドメインでユーザーが認証されるようにするために、サードパーティ Cookie へのアクセスが必要になる場合があります。
複数の商品を異なるドメインやサブドメインでホストしているビジネスもあります。このようなソリューションでは、ユーザー セッションを複数のプロダクト間で共有したい場合があります。このシナリオでは、複数のドメイン間でサードパーティ Cookie にアクセスする必要が生じる可能性があります。
このシナリオで可能な移行パスは次のとおりです。
- ファーストパーティ（「同一サイト」）Cookie を使用するように更新する: ログインフローがメインサイトと同じドメイン（またはサブドメイン）でホストされるようにウェブサイトのインフラストラクチャを変更し、ファーストパーティ Cookie のみを使用するようにします。インフラストラクチャのセットアップ方法によっては、より多くの労力が必要になる場合があります。
- 関連ウェブサイト セット（RWS）と Storage Access API（SAA）を使用する: RWS を使用すると、関連するドメインの小規模なグループ間で、サイトをまたいだ Cookie へのアクセスを制限できます。RWS を使用すると、Storage Access API でストレージ アクセスをリクエストする際にユーザー プロンプトは不要になります。これにより、IdP と同じ RWS にある RP で SSO を使用できます。ただし、RWS は限られた数のドメイン間でのクロスサイト Cookie アクセスのみをサポートしています。
- Web Authentication API を使用する: Web Authentication API を使用すると、利用者が、認証情報を作成して使用できる関連オリジンの限定されたセットを登録できます。
- 5 つを超える関連ドメインでユーザーを認証する場合は、Federated Credentials Management（FedCM）をご検討ください。 FedCM を使用すると、ID プロバイダはサードパーティの Cookie を必要とせずに、Chrome に ID 関連のフローを処理させることができます。この場合、「ログイン ドメイン」が FedCM ID プロバイダとして機能し、他のドメインのユーザーの認証に使用されます。
埋め込みからの認証
top-level.example に 3-party-app.example iframe が埋め込まれているとします。3-party-app.example では、ユーザーは 3-party-app.example の認証情報または別のサードパーティ プロバイダを使用してログインできます。
ユーザーが [ログイン] をクリックし、3-party-app.example ポップアップ内で認証します。3-party-app.example ポップアップでファーストパーティ Cookie が設定されます。ただし、top-level.example に埋め込まれた 3-party-app.example iframe はパーティション化されており、3-party-app.example のファーストパーティ コンテキストで設定された Cookie にアクセスできません。
ユーザーが top-level.example から 3-party-app.example にリダイレクトされて戻った場合にも、同じ問題が発生します。Cookie は 3-party-app.example サイトのファーストパーティ コンテキストで書き込まれますが、パーティション分割されており、3-party-app.example iframe 内ではアクセスできません。
ユーザーがトップレベルのコンテキストで埋め込み元にアクセスしたことがある場合は、Storage Access API が適切なソリューションです。
サードパーティ Cookie に依存するソリューションからの移行を促進するため、ID プロバイダは FedCM API を採用し、FedCM をポップアップではなく埋め込み内から呼び出すことをおすすめします。
このフローの別の提案ソリューションである パーティション分割されたポップインは、現在実装中です。
ソーシャル ログイン
Google でログイン、Facebook ログイン、Twitter でログインなどのログインボタンは、ウェブサイトがフェデレーション ID プロバイダを使用していることを示す明確な証拠です。各フェデレーション ID プロバイダには、独自の実装があります。
サポートが終了した Google Sign-In JavaScript Platform Library を使用している場合は、認証と認可のために新しい Google Identity Services ライブラリに移行する方法をご確認ください。
新しい Google Identity Services ライブラリを使用しているほとんどのサイトでは、サードパーティ Cookie への依存関係が解消されています。これは、互換性を確保するために、FedCM を使用するようにライブラリが自動的に移行されるためです。サードパーティ Cookie のフェーズアウト テストフラグを有効にしてサイトをテストし、必要に応じて FedCM 移行チェックリストを使用して準備することをおすすめします。
埋め込みからユーザーデータにアクセスして変更する
埋め込みコンテンツは、ユーザー プロファイルやサブスクリプション データへのアクセスや管理などのユーザー ジャーニーでよく使用されます。
たとえば、ユーザーが website.example にログインし、subscriptions.example ウィジェットを埋め込むことができます。このウィジェットを使用すると、ユーザーはプレミアム コンテンツの定期購入や請求先情報の更新など、データを管理できます。ユーザーデータを変更するために、埋め込みウィジェットは website.example に埋め込まれている間、独自の Cookie にアクセスする必要がある場合があります。このデータを website.example に分離する必要があるシナリオでは、CHIPS を使用すると、埋め込みに必要な情報にアクセスできます。CHIPS を使用すると、website.example に埋め込まれた subscriptions.example ウィジェットは、他のウェブサイトのユーザーのサブスクリプション データにアクセスできなくなります。
別のケースを考えてみましょう。streaming.example の動画が website.example に埋め込まれており、ユーザーは streaming.example のプレミアム サブスクリプションを利用しています。ウィジェットは、広告を無効にするためにこの情報を知る必要があります。複数のサイトで同じ Cookie にアクセスする必要がある場合は、ユーザーが以前にトップレベルとして streaming.example にアクセスしたことがある場合は Storage Access API を、website.example のセットが streaming.example を所有している場合は関連ウェブサイト セットの使用を検討してください。
Chrome 131 以降では、FedCM が Storage Access API と統合されています。この統合により、ユーザーが FedCM プロンプトを承認すると、ブラウザは IdP エンベディングにパーティショニングされていないストレージへのアクセス権を付与します。
埋め込みコンテンツで特定のユーザー ジャーニーを処理するために選択する API について詳しくは、埋め込みガイドをご覧ください。
その他のユーザー ジャーニー
サードパーティ Cookie に依存しないユーザー ジャーニーは、Chrome によるサードパーティ Cookie の処理方法の変更の影響を受けません。既存のソリューション（ファーストパーティ コンテキスト内のログイン、ログアウト、アカウント復元、2FA など）は、意図したとおりに動作します。潜在的な破損ポイントについては、すでに説明しました。特定の API の詳細については、API ステータス ページをご覧ください。
サイトを監査する
このガイドで説明されているユーザー ジャーニーのいずれかをウェブサイトに実装している場合は、サイトの準備を整える必要があります。サイトでのサードパーティ Cookie の使用状況を確認し、破損をテストして、推奨されるソリューションに移行してください。