Chrome は、サードパーティ Cookie によるユーザーが選択可能な新しいエクスペリエンスを提案しています。サードパーティ Cookie を使用せずにブラウジングすることを選択するユーザーのためにサイトを用意する必要があります。
このページでは、ログイン時に使用頻度の高いオプションについて説明します。 可能な解決策についても記載しています。
ウェブサイトで同じドメインおよびサブドメイン内のフローのみを処理する場合は、
publisher.example、login.publisher.example などであるため、クロスサイト
ログインフローがサードパーティ Cookie の変更の影響を受けないと想定できます。
ただし、サイトでログインに別のドメインを使用する場合（ Google ログイン、Facebook ログイン、またはサイトでユーザーを共有する必要がある 認証を複数のドメインやサブドメインにわたって行う場合、 Google Workspace からスムーズに移行するには、 あります。
ID 関連のユーザー ジャーニーをテストする
ログインフローがサードパーティ Cookie の影響を受けているかどうかをテストする最善の方法 登録、パスワードの再設定、ログイン、 サードパーティ Cookie のテストフラグを有効にしてログアウト フローを実行します。
このチェックリストは、第三者による広告配信を制限した後で確認すべき事項をまとめたものです Cookie:
- ユーザー登録: 新しいアカウントを作成することは想定どおりに機能します。次を使用する場合: 新しいアカウントの登録が機能することを確認する 必要があります
- パスワードの再設定: ウェブ UI から、パスワードが意図したとおりに復元されます。 パスワード再設定用のメールを受信します。
- ログイン: ログイン ワークフローは、同じドメイン内で、 他のドメインに移動する場合などですすべてのログイン統合を必ずテストしてください。
- ログアウト: ログアウト プロセスは意図したとおりに動作し、ユーザーは ログアウト後にログアウトした状態を 確認します
また、ユーザーのログインを必要とする他のサイト機能が、 クロスサイト Cookie がなくても機能する（特に読み込みを伴う場合） リソースが含まれています。たとえば、CDN を使用してユーザーのプロフィール画像を読み込む場合、 確認します。カスタマー ジャーニーが 購入手続きでログインを制限し、これらが継続して機能するようにします。
以降のセクションでは、これらのフローの具体的な情報を 影響を受ける可能性があります。
フェデレーション ID
Google でログイン、Facebook ログインなどのログインボタン Twitter によるログインは、ウェブサイトで フェデレーション ID プロバイダを使用します。各フェデレーション ID プロバイダは 最善の解決策は、プロバイダの お問い合わせください。
非推奨の Google Sign-In JavaScript プラットフォーム ライブラリを使用すると、 認証のために新しい Google Identity Services ライブラリに移行する 認証と認可が必要です。
新しい Google Identity Services ライブラリを使用しているほとんどのサイトは、 サードパーティ Cookie のサポート終了。ライブラリは暗黙的に移行され、 互換性確保のため FedCM を使用。サイトをテストすることをおすすめします サードパーティ Cookie のテストフラグを有効にして、必要に応じて FedCM 移行チェックリストを使用して準備します。
個別のログイン ドメイン
ウェブサイトによっては、認証していないユーザーの認証にのみ別のドメインを使用することがあります。
同一サイト Cookie の対象になります（例: メインの Cookie に example.com を使用しているウェブサイト）。
ログインフロー用の login.example を使用してアクセスする必要があります。
両方でユーザーが認証されるようにします。
できます。
このシナリオで考えられる移行パスは次のとおりです。
- ファーストパーティ（同一サイト）Cookie を使用するように更新: インフラストラクチャを構築して、ログインフローが同じドメイン（または サブドメイン）をメインサイトとして使用し、ファーストパーティの Cookie のみを使用します。このため、 インフラストラクチャの設定方法によっては、多くの労力が必要になります。
- 関連ウェブサイト セット（RWS）を使用する: 関連ウェブサイト セットの有効化 関連する小規模なグループ間のクロスサイト Cookie アクセスが制限されます。RWS は、このユースケースをサポートするために構築されたプライバシー サンドボックス API です。ただし、RWS は 一部のドメインでクロスサイト Cookie アクセスをサポートしています。
- 5 つ以上の関連ドメインでユーザーを認証する場合は、 FedCM の詳細をご覧ください。Federated Credentials Management（FedCM）を使用すると、 ID プロバイダが Chrome を利用して ID 関連のフローを処理できます。 サードパーティ Cookie を 必要とします今回の場合の「ログインドメイン」はとして動作する FedCM ID プロバイダに接続し、他の Google Cloud サービスでの できます。
複数ドメイン
複数のサービスを異なるドメインやサブドメインでホストしている場合は、 これらのプロダクト間でユーザー セッションを共有すると、 複数のドメイン間でサードパーティ Cookie にアクセスする必要がある。
このシナリオでは多くの場合、すべての商品を同じドメインでホストします。 実用的ではありません。この場合の解決策は次のとおりです。
- 関連ウェブサイト セットを使用する: クロスサイト Cookie アクセスが必要な場合 関連付けられるようになります。
- Federation Credential Management（FedCM）を使用する: ドメインが大規模な場合は、別個のログイン ドメインを ID として使用する FedCM を使用してサイト全体でユーザーを認証できます。
ログイン ソリューション
サードパーティのシングル サインオン（SSO）
SSO ソリューションの実装は複雑なため、多くの企業は サードパーティのソリューション プロバイダを利用して、 生成します。プロバイダの例としては、Okta、Ping Identity、Google Cloud IAM、 Microsoft Entra ID。
サードパーティのプロバイダを利用する場合は、 サードパーティ Cookie の変更がソリューションに与える影響と、 お客様に最適なアプローチを 提案できます
オープンソースの SSO ソリューション
多くの企業は、独自の SSO ソリューションを維持しています。 業界標準のもの、または確立されたオープン （Keycloak、WSO2、Auth.js、Hydra など）のソース プロジェクトにエクスポートできます。
ご利用のプロバイダのドキュメントで、 Cookie の変更がソリューションや、 提供できます
カスタムの社内ソリューション
ログイン ソリューションが前述のユースケースのいずれかに該当し、 （サードパーティ Cookie の段階的廃止に備える）で詳しく説明 コードを監査してサードパーティ Cookie の変更に備える方法について説明します。
今すぐご対応ください。
ウェブサイトがいずれかのユースケースに該当する場合は、複数のソリューションがあります あらゆる影響に対処できます。たとえば、認証フローの移行や ファーストパーティの Cookie のみを使用するように設定し、 関連ウェブサイト セット: 少数のユーザー間での Cookie の共有を許可します Federation Credential Management を利用することなどが考えられます。