サードパーティ Cookie の変更がログイン ワークフローに及ぼす影響を確認する

bookmark_border コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

Chrome は、サードパーティ Cookie に関するユーザーの選択に関する新しいエクスペリエンスを提案しています。サードパーティ Cookie を使用しないブラウジングを選択するユーザーのために、サイトを準備する必要があります。

このページでは、影響を受ける可能性が高い ID シナリオと、考えられる解決策について説明します。

ウェブサイトが同じドメインとサブドメイン（publisher.example や login.publisher.example など）内のフローのみを処理する場合、クロスサイト Cookie は使用されず、サードパーティ Cookie の変更によるログイン フローの影響は想定されません。

ただし、サイトが Google ログインや Facebook ログインなど、ログインに別のドメインを使用している場合や、サイトが複数のドメインまたはサブドメイン間でユーザー認証を共有する必要がある場合は、クロスサイト Cookie からのスムーズな移行を確実に行うために、サイトに変更を加える必要がある可能性があります。

一般的なユーザー ジャーニー

これまで、多くの ID ワークフローはサードパーティ Cookie に依存していました。次の表に、一般的なユーザー ジャーニーと、サードパーティ Cookie に依存しない各ジャーニーの考えられるソリューションを示します。以降のセクションでは、これらの推奨事項の理由について説明します。

一般的なユースケースに推奨される代替 API

の機能は、まだ開発の初期段階です。皆さまからいただいた貴重なご意見を参考に、今後の改善に努めてまいります。パーティショニング ポップインの API に関するご意見をお聞かせください。

ユーザー 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 は、限定された数のドメイン間でのクロスサイト クッキー アクセスのみをサポートしています。
• Web Authentication API を使用する: Web Authentication API を使用すると、利用者（RP）は、認証情報を作成して使用できる関連するオリジンの限定されたセットを登録できます。
• 関連するドメインが 5 つを超えるユーザーを認証する場合は、Federated Credentials 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 をポップアップではなく埋め込み内から呼び出すことをおすすめします。

このフローに対する別の提案ソリューションである パーティショニングされたポップインの実装が進行中です。

ソーシャル ログイン

[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 の使用状況を監査し、不具合をテストし、推奨されるソリューションに移行します。