Chrome はサードパーティ Cookie による新たなユーザー選択機能を提案しています。サードパーティ Cookie を使用しないブラウジングを選択するユーザーに対応できるよう、サイトを準備する必要があります。
このページでは、影響を受ける可能性が高い ID シナリオと、考えられる解決策について説明します。
ウェブサイトで同じドメインとサブドメイン（publisher.example や login.publisher.example など）内のフローのみを処理する場合、クロスサイト Cookie は使用されず、サードパーティ Cookie の変更によるログインフローへの影響もありません。
ただし、サイトでログインに別のドメイン（Google ログインや Facebook ログインなど）を使用している場合や、サイトが複数のドメインやサブドメイン間でユーザー認証を共有する必要がある場合は、クロスサイト Cookie からスムーズに移行するためにサイトに変更を加える必要が生じる可能性があります。
一般的なユーザー ジャーニー
これまで、多くの ID ワークフローはサードパーティ Cookie に依存していました。次の表に、一般的なユーザー ジャーニーと、サードパーティ Cookie に依存しない各ジャーニーの解決策を示します。以降のセクションでは、これらの推奨事項の理由について説明します。
一般的なユースケースに推奨される代替 API
| ユーザー ジャーニー | 推奨 API |
|---|---|
| ソーシャル ログイン |
ID プロバイダの場合: FedCM を実装します 信頼関係のある当事者の場合: ID プロバイダにお問い合わせください |
| フロント チャンネルのログアウト | ID プロバイダの場合: FedCM を実装する |
|
ID プロバイダまたはカスタム ソリューションの場合: 関連するウェブサイト セット |
|
| ユーザー プロファイルの管理 |
Storage Access API 関連ウェブサイト セット CHIPS FedCM |
|
Storage Access API 関連ウェブサイト セット CHIPS FedCM |
|
| 認証 |
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 にリダイレクトされてから元に戻った場合も、同じ問題が発生します。Cookie は 3-party-app.example サイトのファーストパーティ コンテキストで書き込まれますが、パーティション化されているため、3-party-app.example iframe 内からはアクセスできません。
ユーザーがトップレベル コンテキストで埋め込みオリジンにアクセスした場合は、Storage Access API が適切なソリューションです。
サードパーティ Cookie に依存するソリューションから移行するには、ID プロバイダが FedCM API を採用し、FedCM をポップアップではなく埋め込み内から呼び出すことをおすすめします。
このフローに対してもう一つ提案されているソリューションである Partitioned Popins の実装も進行中です。
ソーシャル ログイン
[Google でログイン]、[Facebook ログイン]、[Twitter でログイン] などのログイン ボタンは、ウェブサイトがフェデレーション ID プロバイダを使用していることを明確に示しています。各連携 ID プロバイダには独自の実装があります。
非推奨の Google ログイン JavaScript プラットフォーム ライブラリを使用している場合は、認証と認可のために新しい 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 について詳しくは、埋め込みガイドをご覧ください。
Front Channel からのログアウト
フロントチャネル ログアウトは、ユーザーが 1 つのサービスでログアウトしたときに、関連するすべてのアプリからログアウトできるようにするメカニズムです。OIDC の Front-channel ログアウトでは、IdP が RP の Cookie に依存する複数の証明書利用者（RP）iframe を埋め込む必要があります。
ソリューションが ID プロバイダに依存している場合は、軽微な変更（ライブラリのアップグレードなど）が必要になることがあります。詳しくは、ご利用の ID プロバイダにお問い合わせください。
このユースケースに対処するため、FedCM は logoutRPs 機能をテストしました。これにより、IdP は、ユーザーが以前に RP IdP 通信を承認した RP をログアウトできます。この機能は利用できなくなりましたが、この機能にご興味をお持ちの場合や、この機能が必要な場合は、最初の提案をご参照のうえ、フィードバックをお寄せください。
その他のユーザー ジャーニー
サードパーティ Cookie に依存しないユーザー ジャーニーは、Chrome のサードパーティ Cookie の処理方法の変更の影響を受けません。ログイン、ログアウト、ファーストパーティ コンテキストでのアカウント復元、2 段階認証プロセスなど、既存のソリューションは想定どおりに機能します。破損の可能性がある箇所については、すでに説明しています。特定の API の詳細については、API ステータスのページをご覧ください。不具合が発生した場合は、goo.gle/report-3pc-broken に報告してください。また、フィードバック フォームを送信するか、GitHub の プライバシー サンドボックス デベロッパー サポート リポジトリから問題を報告することもできます。
サイトの監査
ウェブサイトに、このガイドで説明するいずれかのユーザー ジャーニーを実装している場合は、サイトの準備を確認する必要があります。サイトのサードパーティ Cookie の使用状況を監査し、不具合をテストし、推奨されるソリューションに移行します。