クロスドメイン ログインをデフラグする

Eiji Kitamura

最新のビジネス アーキテクチャは、複数の異なるドメインにまたがることがよくあります。組織は、マーケティング用の brand.example、コアプロダクト用の service-app.example、カスタマー サービス用の support-portal.example など、さまざまな機能専用の環境を維持しています。理想的には、ユーザーがこれらのプロパティ間を移動する際に、統合されたシングル サインオン エクスペリエンスを提供したいところです。ただし、エンジニアリング チームは、断片化を引き起こすアドホックな手法を使用してこれらのドメインを統合することがよくあります。これにより、パスワード マネージャーの自動入力フローが中断され、パスキーの導入が遅れるため、ブラウザの組み込みの認証情報管理が妨げられます。

同じアカウントが複数のドメインにまたがっている場合、ユーザーはドメインが同じ組織に属していることを認識し、ログイン時に同じ認証情報を提供する必要があります。最悪の場合、ユーザーが重複アカウントを作成したり、フィッシング ウェブサイトにパスワードを渡したりする可能性があります。

アーキテクチャ標準とソリューション（メタデータ、クロスオリジン iframe、ID 連携、サブドメイン統合など）を使用して、クロスドメイン ID の断片化を解決し、シームレスなユーザー ジャーニーを実現する方法を学びます。

一般的な回避策

組織は、クロスドメイン ジャーニーを維持するために、確立されたいくつかの手法を使用します。これらの方法は一般的ですが、ブラウザでより厳格なプライバシー境界とセキュリティ基準が適用されるため、構造的なハードルに直面しています。

CORS フェッチ リクエスト

ドメインが独立して動作する場合、フロントエンドは通常、一元化された認証 API に向けられたクロスオリジン fetch() リクエストに依存します。これは、クロスオリジン リソース シェアリング（CORS）を使用して安全に許可できます。ブラウザではクロスサイト Cookie がブロックまたは制限されることが多いため、デベロッパーは Set-Cookie ヘッダーに依存するのではなく、JSON ペイロード内の JSON Web Token（JWT）などの認証トークンを返すようにこれらの API を明示的に設計することがあります。

アカウント データベースの共有

複雑なフロントエンド統合を行わずにバックエンドで ID を統合するには、ユーザー データストアを集中管理します。複数のドメインが同じデータベースに対して認証を行いますが、フロントエンドのログイン エクスペリエンスは別々のままです。これにより、ユーザーは同じ認証情報を使用したドメインを覚えておく必要があり、ユーザー エクスペリエンスが低下します。

ログインが連携されていない場合の問題

技術的な回避策で基本的な機能は実現できても、シームレスなジャーニーは実現できません。ログインフローが分断されていると、ユーザビリティとセキュリティの両方を損なう摩擦点が生じます。

パスワード マネージャーの断片化

最も大きな摩擦は、パスワード マネージャーの妨害です。パスワード マネージャーは、保存された認証情報を登録された特定のオリジンにバインドします。これにより、異なるドメインが同じ組織に属している場合でも、ブラウザが異なるドメイン間で自動入力を行うのを防ぐことができます。

ユーザーが保存された認証情報を含むドメインから組織内の新しいドメインに移行すると、パスワード マネージャーは関係を認識できず、自動入力のプロンプトがトリガーされません。これにより、手動入力の摩擦が生じます。ユーザーは、認証情報を確認するか、パスワードをリセットするか、重複するアカウントを作成する必要があります。

パスワード マネージャーがこれらのプロパティで信頼できないことが判明すると、ユーザーはこれらのサイトのツールを放棄する可能性があります。代わりに、覚えやすい弱いパスワードを作成して他の場所で再利用することが多く、組織の全体的なセキュリティが低下します。

フィッシング ゲートウェイ

この妨害はフィッシング ゲートウェイとして機能します。認識されないドメインでの自動入力をパスワード マネージャーが拒否することは、主要な防御メカニズムです。ユーザーに異なる URL で認証情報を手動で入力させることで、ユーザーがフィッシング攻撃の被害に遭うように意図せず訓練することになります。

パスキーのロードブロッキング

パスキーを使用すると、摩擦が増大します。WebAuthn のコア セキュリティ アーキテクチャでは、パスキーが指定されたリライング パーティ ID（RP ID）に厳密に暗号的にバインドされます。

これにより、「RP ID トラップ」が作成されます。brand.example に登録されたパスキーは、ブラウザがクロスドメイン アクセスを拒否するため、service-app.example では使用できません。ユーザーがサイトごとに個別のパスキーを登録するよう求められないようにするには、これらのプロパティを 1 つの RP ID に統合する必要があります。

推奨されるアプローチ

ID の継続性を確立するには、アドホックなログイン統合から離れ、認識されたアーキテクチャ標準を採用する必要があります。

• メタデータ構成ファイルを使用する: 暗号信頼チェーンを確立するために、Digital Asset Links や Related Origin Requests などのメタデータ ファイルをホストします。これにより、異なるドメインやモバイルアプリ間で認証情報とパスキーをシームレスに共有できます。このアプローチは、既存のウェブ インフラストラクチャの複雑な再アーキテクチャを必要としない、低コストでサイレントな ID の断片化の修正です。
• クロスオリジン iframe を使用する: 依存当事者内に一元化された認証オリジンを iframe として埋め込み、保存された認証情報とパスキーをさまざまなサイト間でブリッジします。このアプローチでは、Permissions Policy とパーティション分割された Cookie を使用して、CSP とクロスドキュメント メッセージングを通じて厳格なセキュリティ境界を維持しながら、シームレスなコンテキスト内ログイン エクスペリエンスを実現します。
• 標準の ID 連携に従う: OpenID Connect などの業界標準プロトコルを採用して、専用の ID プロバイダ（IdP）ドメインで認証を一元化します。これにより、安全なリダイレクトによるログイン プロセスが正式化され、脆弱な統合が信頼性とスケーラビリティの高いファーストパーティ ソリューションに置き換えられます。
• サブドメインを統合する: 共通のルートの下にあるサブドメインに移行します。これにより、登録可能なドメイン全体でワイルドカード Cookie を介したシームレスなセッション共有とパスキーの継続性が実現します。多くのパスワード マネージャーは、共有ルートドメインを認識し、関連するサブドメイン間で保存された認証情報を自動的に提案できます。

メタデータ構成ファイルを使用する

クロスドメイン ID の主な課題は、保存された認証情報の断片化です。パスワード マネージャーは、異なるドメインとアプリを完全に分離されたエンティティとして扱うため、あるプロパティに保存された認証情報を別のプロパティに自動入力することはできません。

フラグメンテーションに対処するには、ウェブサイトの構造を変更するのではなく、パスワード マネージャーの動作を構成します。特定のメタデータ構成ファイルをホストすることで、組織は、異なるドメインとアプリケーションが同じ組織に属することを暗号的に証明できます。これにより、オペレーティング システム、ブラウザ、パスワード マネージャーがこの関係を認識し、ID コンテキストを自動的にブリッジして、プロパティ間でパスワードとパスキーを共有できるようになります。このアプローチは、ウェブ ドメインが統合されている場合でも、ウェブベースのパスワードとパスキーをモバイル アプリケーションと共有するために必要です。

2 つの異なる構成ファイルを使用して、さまざまなプラットフォームとエコシステムをカバーします。

• Android と Chrome の Google パスワード マネージャー: /.well-known/assetlinks.json に Digital Asset Links（DAL）JSON ファイルをホストして、組織の関連アプリとウェブサイト間の検証可能な信頼関係を確立します。この信頼により、アプリのディープリンクとシームレスな認証情報の共有が可能になります。ウェブで保存されたパスワードが関連付けられたウェブサイトで自動的に自動入力されます（ただし、複数のウェブ ドメイン間でパスキーを共有するには、関連するオリジン リクエストが必要です）。詳しくは、シームレスな認証情報の共有ガイドをご覧ください。

• iOS と Safari の Apple パスワード: /.well-known/apple-app-site-association で Apple App Site Association（AASA）ファイルをホストし、iOS アプリと Safari で Apple パスワードの状態をブリッジするために必要な暗号信頼チェーンを確立します。サードパーティ エコシステムをサポートするために、クラウドソース リポジトリを使用して、これらの関連ドメインを一元的に宣言できます。そうすることで、独立したツール（このリポジトリを明示的に取り込む 1Password など）も共有 ID コンテキストを認識できます。Apple App Site Association について詳しくは、関連付けられたドメインのサポートをご覧ください。

さまざまなウェブ ドメインでパスキーを有効にし、パスキーの障害に対処するために、デベロッパーは /.well-known/webauthn に Related Origin Requests（ROR）ファイルをホストできます。ROR は、同じパスキー RP ID を安全に共有することが許可されている承認済みドメインを明示的に宣言します。関連オリジン リクエストの詳細については、関連オリジン リクエストを使用してサイト間でパスキーを再利用できるようにするをご覧ください。

• 長所:
  • エンドユーザー向けのバックグラウンド修正: バックグラウンドで完全に動作し、自動入力の断片化を自動的に解決し、OS またはブラウザレベルでパスキーの継続性を確立します。UX に目に見える変更はありません。
  • シンプルな実装: 静的 JSON ファイルのホスティングのみを必要とする低コストのソリューションです。バックエンドの再アーキテクチャや複雑なトークン交換ロジックは必要ありません。
  • 既存のインフラストラクチャを維持: ブランドを変更したり、ドメインを統合したりすることなく、クロスドメインのユーザー ジャーニーを大幅に改善できます。
• デメリット:
  • プラットフォームの制約: プラットフォームでは通常、ROR に厳しい制限が課せられます。たとえば、Chrome では、1 つの RP ID に関連付けることができる eTLD+1 ラベルの最大数が 5 に制限されています。たとえば、example.co.uk と example.de は同じ example eTLD+1 ラベルを共有していますが、example-rewards.com は別の example-rewards ラベルを使用しています。大規模なドメイン ポートフォリオや多様なドメイン ポートフォリオを管理している場合は、これらの上限では不十分な可能性があります。
  • オペレーション レイテンシの増加: メタデータ ファイルの解決には追加のネットワーク ラウンドトリップが必要になるため、ブラウザが認証を処理する際にレイテンシが増加します。

クロスオリジン iframe を使用する

ROR ドメインの制限によりメタデータ構成ファイルのアプローチを使用できない場合は、クロスオリジン iframe 要素が、クロスドメイン ログインの課題を解決するための、標準に準拠した堅牢なパスを提供します。

一元化された認証元（auth.brand.example など）を信頼当事者（brand.example など）内の iframe として埋め込むことで、通常のフォーム フィールドと最新の API の両方を操作できます。パスワードの場合、ブラウザの認証情報マネージャーは、自動入力アクションを iframe のオリジン（auth.example）に関連付けます。これにより、ユーザーはさまざまなサイトで一元管理された認証情報にシームレスにアクセスできます。

パスキーの場合、親ウィンドウは Permissions Policy フレームワークを使用して iframe にアクセス権を付与する必要があります。これにより、iframe は WebAuthn を呼び出して、独自のオリジンの RP ID に対して認証を行うことができます。どちらのフローでも、CSP（コンテンツ セキュリティ ポリシー）は、クリックジャッキングやクロスサイト スクリプティングなどの攻撃からユーザーを保護するのに役立ちます。認証に成功すると、パーティション分割された Cookie を使用してセッションが確立され、postMessage() を使用してトークンが安全に親ウィンドウに返送されます。

• 長所:
  • 一元化された認証情報: 認証情報の断片化を回避します。単一の一元化されたオリジンが、保存されたパスワードと統合されたパスキー RP ID の両方を管理するため、ドメインを統合することなく、異なるドメイン間でこれらの認証情報を共有できます。
  • コンテキスト認証: パスワードの自動入力やパスキーによる確認など、ログイン フロー全体が親ページ内のコンテキストでシームレスに行われるため、フェデレーション リダイレクトによる中断を回避できます。
  • トラッキング防止機能に対する復元力: このアプローチは、パーティション分割された Cookie を使用した厳格なクロスサイト トラッキング防止機能の下でも正しく動作します。
• デメリット:
  • 実装の制約: このアーキテクチャには、専門的なエンジニアリングが必要です。信頼できる親ドメインへの埋め込みを制限してクリックジャッキングを防ぐための厳格な CSP（frame-ancestors）、WebAuthn API を有効にするための HTTP 権限ポリシーの構成、オリジン スプーフィングと CSRF 攻撃を軽減するための安全で検証済みのクロスドキュメント メッセージング（postMessage()）が必要です。ベスト プラクティスについては、iframe 内のパスキーをご覧ください。

標準の ID 連携に従う

OpenID Connect などの標準の ID 連携を採用することは、アカウント システムを維持するための堅牢で持続可能なアプローチです。このアプローチでは、認証ワークフローを auth.brand.example などの単一の専用 ID プロバイダ（IdP）ドメインに統合することで、認証ワークフローを正式化します。確立されたプロトコルにより、アプリケーションはユーザーをこの中央ハブにリダイレクトして認証を行い、トークン転送を安全に受け取って、ターゲット ドメインでのログインを完了します。標準の連携は、サードパーティ ログイン（Google でログインなど）に関連付けられることが多いですが、脆弱な回避策に代わるファーストパーティ ソリューションとして完全に有効であり、広く使用されています。

• 長所:
  • 共通のエンジニアリング言語: 開発者は、特定のカスタムビルド プロトコルを学習したり、維持したりする必要はありません。確立された業界の知識と包括的なライブラリを利用できます。パッケージ化されたソリューションもあります。
  • 実証済みの信頼性: 標準プロトコルは、実証済みで安全であり、アドホック実装よりもはるかに脆弱性が少ないです。
  • 簡単に拡張可能: 組織が新しいサードパーティ サービスと連携したり、後で買収を統合したりする必要がある場合、ID インフラストラクチャにはすでに認証情報を提供する機能が備わっています。
  • 一貫性のある UX: ユーザーは、一元化された IdP ページをブランドの信頼できるソースとして認識し、認証情報が必要なタイミングと場所を正確に把握できます。
• デメリット:
  • 統合のオーバーヘッドが大きい: 一元化された IdP を開発または移行すると、統合のオーバーヘッドが大きくなり、セキュリティに関する専門知識が必要になります。組織は、安全なリダイレクト ベースのパターンをサポートするために、接続されているすべてのアプリケーションを安全にリファクタリングする必要があります。
  • 中断を伴うリダイレクト: 認証フローでは、ユーザーを元のサイトから一元化された ID プロバイダのページにリダイレクトする必要があるため、シームレスなコンテキスト内ログイン エクスペリエンスが妨げられます。

サブドメインを統合する

別の構造的なアプローチとして、共通の登録可能なルートドメイン（eTLD+1）の下に異なるデジタル プロパティを移動して、すべてのドメインを統合する方法があります。これには、brand.example や service-app.example などの個別のドメインを www.brand.example や service.brand.example などのサブドメインに移行することが含まれます。

• 長所:
  • 統合された認証情報管理: パスワード マネージャーはルートドメインを認識し、すべてのサブドメインを 1 つのエントリとして扱うため、パスワードの重複したプロンプトや手動入力が不要になります。
  • パスキーの継続性: デベロッパーは、パスキー RP ID を登録可能なドメインにネイティブにスコープ設定し、関連するすべてのサブドメインにパスキーのサポートを即座に拡張できます。この場合、RP ID brand.example は www.brand.example と service.brand.example の両方で機能します。
  • セッションの共有が容易になる: ドメイン構造を統合すると、ワイルドカード Cookie を使用して単一のセッションを共有できます（たとえば、Cookie のスコープを Domain=brand.example に設定するなど）。
• デメリット:
  • ブランディングと移行の制約: 組織で個別のトップレベル ドメインが義務付けられている場合、このアプローチではブランディングに制限が生じる可能性があります。移行は複雑で、HTTP リダイレクトの慎重な管理と、以前のクロスオリジン構成の広範な修復が必要です。

まとめ

ID の継続性を実現するには、アドホックなログイン統合から確立された認証標準に移行する必要があります。フェデレーション、ドメイン統合、iframe、メタデータなどの確立されたプラクティスに照らしてビジネス上の制約を評価することで、UX の摩擦を解消し、エコシステム全体で認証を改善できます。

関連トピックについて詳しくは、ブログをフォローして、Chrome の ID ポータルでその他のリソースをご覧ください。