Chrome は、サードパーティ Cookie に関するユーザーの選択を促す新しいエクスペリエンスを提案しています。サードパーティ Cookie を使用しないブラウジングを選択するユーザーに対応できるよう、サイトを準備する必要があります。
このページでは、影響を受ける可能性が高い ID シナリオと、考えられる解決策について説明します。
ウェブサイトが同じドメインとサブドメイン（publisher.example や login.publisher.example など）内のフローのみを処理する場合、クロスサイト Cookie は使用されず、サードパーティ Cookie の変更によるログイン フローの影響は想定されません。
ただし、Google ログインや Facebook ログインなど、サイトがログインに別のドメインを使用している場合や、サイトが複数のドメインまたはサブドメイン間でユーザー認証を共有する必要がある場合は、クロスサイト Cookie からの移行をスムーズに行うために、サイトに変更を加える必要がある可能性があります。
一般的なユーザー ジャーニー
これまで、多くの ID ワークフローはサードパーティ Cookie に依存していました。次の表に、一般的なユーザー ジャーニーと、サードパーティ Cookie に依存しない各ジャーニーの潜在的なソリューションを示します。以降のセクションでは、これらの推奨事項の理由について説明します。
一般的なユースケースに推奨される代替 API
| ユーザー ジャーニー | 推奨される API |
|---|---|
| ソーシャル ログイン |
ID プロバイダの場合: FedCM を実装します 信頼関係のある当事者の場合: 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 がなくても機能することをテストする必要があります。特に、クロスサイト リソースの読み込みが伴う場合は注意が必要です。たとえば、CDN を使用してユーザー プロフィール画像を読み込む場合は、引き続き機能することを確認します。ログインに制限されている重要なユーザー ジャーニー（購入手続きなど）がある場合は、それらが引き続き機能することを確認します。
ログイン ソリューション
このセクションでは、これらのフローへの影響について詳しく説明します。
サードパーティのシングル サインオン（SSO）
サードパーティのシングル サインオン（SSO）を使用すると、ユーザーは 1 つのプラットフォームで 1 つの認証情報セットで認証し、ログイン情報を再入力することなく複数のアプリケーションやウェブサイトにアクセスできます。SSO ソリューションの実装は複雑であるため、多くの企業はサードパーティ ソリューション プロバイダを使用して、複数のオリジン間でログイン状態を共有しています。プロバイダの例としては、Okta、Ping Identity、Google Cloud IAM、Microsoft Entra ID などがあります。
ソリューションがサードパーティ プロバイダに依存している場合は、ライブラリのアップグレードなど、軽微な変更が必要になることがあります。サードパーティ Cookie の依存関係がソリューションに与える影響と、サービスに推奨されるアプローチについて、プロバイダにガイダンスを求めることをおすすめします。一部のプロバイダは、サードパーティ Cookie からサイレント マイグレーションします。この場合、リレーリング パーティは更新する必要はありません。
複数ドメイン
一部のウェブサイトでは、同じサイト 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 を使用すると、利用者（RP）は、認証情報を作成して使用できる関連するオリジンの限定されたセットを登録できます。
- 関連付けられたドメインが 5 つを超える場合は、Federated Credential Management（FedCM）を検討してください。FedCM を使用すると、ID プロバイダはサードパーティ Cookie を必要とせずに、Chrome を使用して ID 関連のフローを処理できます。この場合、「ログイン ドメイン」は FedCM ID プロバイダとして機能し、他のドメインのユーザーの認証に使用できます。
埋め込みからの認証
3-party-app.example iframe が top-level.example に埋め込まれているとします。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 にリダイレクトされてから 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 ライブラリを使用しているほとんどのサイトでは、互換性を確保するために FedCM を使用するようにライブラリが自動的に移行されるため、サードパーティ Cookie の使用を停止しています。サードパーティ Cookie の段階的廃止テストフラグを有効にしてサイトをテストし、必要に応じて FedCM 移行チェックリストを使用して準備することをおすすめします。
埋め込みからユーザーデータにアクセスして変更する
埋め込みコンテンツは、ユーザー プロファイルや定期購入データへのアクセスや管理など、ユーザー ジャーニーによく使用されます。
たとえば、ユーザーが website.example にログインし、subscriptions.example ウィジェットを埋め込むとします。このウィジェットを使用すると、ユーザーはプレミアム コンテンツの定期購入や請求情報の更新など、データを管理できます。埋め込みウィジェットがユーザーデータを変更するには、website.example に埋め込まれているときに独自の Cookie にアクセスする必要がある場合があります。このデータを website.example に分離する必要があるシナリオでは、CHIPS を使用して、埋め込みが必要な情報に確実にアクセスできるようにします。CHIPS を使用すると、website.example に埋め込まれた subscriptions.example ウィジェットは、他のウェブサイト上のユーザーの定期購入データにアクセスできなくなります。
別のケースを考えてみましょう。streaming.example の動画が website.example に埋め込まれており、ユーザーが Premium streaming.example サブスクリプションをお持ちの場合、広告を無効にするにはウィジェットがそのことを把握する必要があります。複数のサイトで同じ Cookie にアクセスする必要がある場合は、ユーザーが以前に streaming.example をトップレベルとしてアクセスしている場合は Storage Access API の使用を検討し、website.example のセットが streaming.example を所有している場合は 関連ウェブサイト セットの使用を検討してください。
Chrome 131 以降、FedCM は Storage Access API と統合されています。この統合により、ユーザーが FedCM プロンプトを承認すると、ブラウザはパーティショニングされていないストレージへの IdP 埋め込みアクセスを許可します。
埋め込みコンテンツを含む特定のユーザー ジャーニーを処理するために選択する API について詳しくは、埋め込みガイドをご覧ください。
その他のユーザー ジャーニー
サードパーティ Cookie に依存しないユーザー ジャーニーは、Chrome のサードパーティ Cookie の処理方法の変更の影響を受けません。ログイン、ログアウト、ファーストパーティ コンテキスト内のアカウント復元、2 段階認証プロセスなど、既存のソリューションは想定どおりに機能します。破損の可能性がある箇所については、すでに説明しています。特定の API の詳細については、API のステータス ページをご覧ください。不具合が発生した場合は、goo.gle/report-3pc-broken に報告してください。フィードバック フォームを送信するか、GitHub の プライバシー サンドボックス デベロッパー サポート リポジトリで問題を報告することもできます。
サイトを監査する
ウェブサイトに、このガイドで説明するいずれかのユーザー ジャーニーを実装している場合は、サイトの準備を確認する必要があります。つまり、サイトでのサードパーティ Cookie の使用状況を監査し、機能の不具合をテストし、推奨されるソリューションに移行する必要があります。