WebAuthn関連オリジン：クロスドメインのパスキーガイド

パスキーは、安全でユーザーフレンドリーな認証の新しい標準です。FIDO/WebAuthn標準に基づいて構築されており、公開鍵暗号方式を活用してフィッシングやクレデンシャルスタッフィングに対する本質的な耐性を提供し、セキュリティ体制を劇的に向上させながら、ユーザーのログイン体験を簡素化します。組織にとっては、これが具体的なビジネス上のメリットにつながります。パスワードリセットやSMS OTPによる運用コストの削減、アカウント乗っ取り詐欺による財務リスクの軽減、そしてコンバージョン率の向上による収益増加などです。

しかし、WebAuthnの最大のセキュリティ上の強みの一つである、厳格なオリジンに紐づく性質は、グローバルなブランドや多様なデジタルフットプリントを持つ企業にとって、現実世界で大きな課題を生み出します。設計上、特定のウェブドメイン用に作成されたパスキーは、そのドメインに暗号学的にロックされます。これはフィッシング攻撃を防ぐための基本原則です。これは強力なセキュリティ機能ですが、単一のブランドが複数のドメインで事業を展開している場合、断片的で混乱を招くユーザー体験につながります。

この課題の顕著な例が、TwitterからXへのリブランディングです。twitter.comでパスキーを作成したユーザーは、x.comではそれを使えないことに気づくでしょう。これにより、会社は面倒なリダイレクトを実装するか、ユーザーに再登録を求める必要があり、これが普及を直接妨げる摩擦を生み出します。これは孤立した問題ではありません。Amazonのような大企業は、amazon.com、amazon.de、amazon.co.ukといった多数の国コードトップレベルドメイン（ccTLD）にわたって事業を展開しており、これらはすべて共通のユーザーアカウントシステムを共有しています。パスキー以前の世界では、パスワードマネージャーがこの複雑さを巧みに処理していましたが、WebAuthnのデフォルトの動作では、ドメインごとに別のパスキーが必要になり、ユーザーを苛立たせ、シームレスなログインという約束を損なうことになります。

この重大な導入障壁を解決するために、W3CはWebAuthn標準に新しい機能、**関連オリジンリクエスト（Related Origin Requests, ROR）**を導入しました。この強力なメカニズムは、標準化された安全な方法で、信頼できるドメインのセットが単一のパスキーを共有することを可能にし、ブランドのデジタルエコシステム全体で統一されたシームレスな認証体験を創出します。この詳細な解説では、RORの技術的基盤を探り、その実装に関する実践的なガイドを提供し、現代の認証アーキテクチャに対する戦略的な意味合いを分析します。

RORの導入は、WebAuthn標準の大きな成熟を示しています。初期の仕様では、中核となる暗号技術とセキュリティ原則の確立が優先され、クレデンシャルをRelying Party ID（rpID）に厳密にバインドすることが、そのアンチフィッシング設計の基礎となっていました。AmazonやGoogleのような企業による大規模なエンタープライズ展開が現実のものとなるにつれて、この厳格さが引き起こす実践的な摩擦が明らかになりました。この摩擦は、高いユーザー採用率を達成するための直接的な障害であり、これこそがパスキープロジェクトの成功の最終的な尺度です。RORの開発は、このエンタープライズからのフィードバックに対する直接的な応答であり、標準の実用的な進化を示しています。セキュリティプロトコルが広範な成功を収めるためには、その使いやすさが、それを展開する組織の複雑なビジネスの現実とブランディング戦略に対応できる規模にまでスケールする必要があることを認めています。

この包括的なガイドは、WebAuthn関連オリジンリクエストを実装するための5つの重要な問いに答えます。

1. なぜパスキーは複数のドメインで機能しないのか？ WebAuthnのオリジンに紐づくセキュリティモデルとその現実世界での摩擦点を理解する
2. 関連オリジンリクエストは技術的にどのように機能するのか？ ブラウザの検証フローと.well-known URIメカニズムを深く掘り下げる
3. RORを実装するために何が必要か？ 実用的なコード例を用いたサーバー側とクライアント側のステップバイステップの設定
4. いつRORをフェデレーションログインより選ぶべきか？ RORとOIDC/SAMLアプローチを比較する戦略的意思決定フレームワーク
5. ブラウザの互換性とセキュリティの考慮事項にどう対処するか？ 現在のサポートマトリックスとセキュリティのベストプラクティス

さらなる技術的な詳細については、公式のWebAuthn関連オリジンリクエスト解説をご覧ください。

関連オリジンリクエストというソリューションの洗練さを十分に理解するためには、まずその存在を必要とする根本的な技術的概念を理解することが不可欠です。それは、ウェブの同一オリジンポリシーとWebAuthnのRelying Party ID（rpID）のスコープ規則です。これらのメカニズムはウェブセキュリティの基礎ですが、RORが軽減しようとするまさにその摩擦を生み出します。

ウェブの「オリジン」は、コンテンツが提供されるプロトコル（例：https）、ドメイン（例：app.example.com）、ポート（例：443）のユニークな組み合わせによって定義される重要なセキュリティ概念です。同一オリジンポリシーは、あるオリジンから読み込まれたスクリプトが別のオリジンのリソースとどのように対話できるかを制限する、ブラウザによって強制されるセキュリティメカニズムです。これはウェブセキュリティの重要な要素であり、潜在的に悪意のあるドキュメントを効果的に隔離し、例えば、詐欺的なウェブサイトが別のタブで認証されたユーザーのウェブメールセッションから機密データを読み取るのを防ぎます。

WebAuthnのエコシステムでは、「Relying Party」（RP）とは、ユーザーが認証しようとしているウェブサイトやアプリケーションのことです。すべてのパスキーは、作成された瞬間に**Relying Party ID（rpID）**に暗号学的に紐付けられます。rpIDはドメイン名であり、そのクレデンシャルのスコープと境界を定義します。

デフォルトでは、rpIDはパスキーが作成されているオリジンの有効なドメインです。WebAuthnのスコープ規則では、オリジンは自身のドメインと等しいか、または登録可能なドメインサフィックスであるrpIDを設定できます。例えば、https://www.accounts.example.co.ukで実行されているスクリプトは、以下のrpIDでパスキーを作成できます。

• www.accounts.example.co.uk（完全なドメイン）
• accounts.example.co.uk
• example.co.uk

この柔軟性により、あるサブドメインで作成されたパスキーを、同じ親ドメインの他のサブドメインでも使用できるようになります。これは一般的で必要なパターンです。しかし、この規則はサフィックスでないrpIDの設定を厳しく禁止しています。www.accounts.example.co.uk上の同じスクリプトは、example.comというrpIDでパスキーを作成することは_できません_。なぜなら、.comは異なるトップレベルドメインだからです。

この厳格な紐付けは、ドメインスコープごとにクレデンシャルを分離するという重要な目的を果たします。mybank.com用に作成されたパスキーは、phishing-site.comでは行使できません。なぜなら、悪意のあるサイトはmybank.comの正当なrpIDを主張できないからです。ブラウザは選択肢としてそのパスキーを提示さえしません。

しかし、rpID自体が主要なアンチフィッシング対策ではありません。WebAuthnのフィッシング対策は、実際にはclientDataJSONオブジェクト内のオリジン検証から来ています。すべてのWebAuthnの処理中、ブラウザはリクエストを開始した_正確なオリジン_を含む重要なコンテキストを含んだJSONオブジェクトを作成します。このオブジェクト全体が、認証器の秘密鍵によって暗号学的に署名されます。サーバー（Relying Party）は、この署名を必ず検証し、そして重要なことに、署名されたclientDataJSON内のオリジンフィールドが、期待される信頼できる値と一致することを検証しなければなりません。このオリジン検証がフィッシング攻撃を防ぐのです。

関連オリジンリクエストでは、rpIDのスコープが緩和されます。ブラウザが.well-known/webauthnファイルを検証した後、bar.comがfoo.comのrpIDを正当に主張できるようになりますが、オリジン検証の要件は変わりません。clientDataJSONは依然としてオリジンをbar.comとして正直に報告します。foo.comのサーバーはこの署名されたデータを受け取り、それを検証し、リクエストがbar.comから来たことを確認します。その後、サーバーは認証を受け入れる前に、bar.comが期待される関連オリジンであることをチェックする必要があります。これは、オリジン検証という中核原則を犠牲にすることなく、より大きな柔軟性を可能にする多層的なアプローチを示しています。

関連オリジンリクエストのメカニズムは、ドメインがパスキーを共有する目的で信頼関係を公に宣言するための、洗練された標準化された方法を導入します。これは、確立されたウェブパターンである/.well-known/ URIを活用して、ブラウザが参照できる検証可能で機械可読な「許可リスト」を作成します。

中核となるコンセプトは単純です。関連サイトのセットの主要で正規のrpIDとして機能するドメインが、標準化された「well-known」なURLであるhttps://{rpID}/.well-known/webauthnに特別なJSONファイルをホストできます。このファイルは公開マニフェストとして機能し、その主要なrpIDの下でパスキーを作成・使用することが公式に許可されている他のすべてのオリジンを明示的にリストアップします。

ブラウザの検証フローは、現在のオリジンと要求されたrpIDの間に不一致を検出するたびにトリガーされます。

1. https://example.co.ukのような「関連」サイトのユーザーが、クライアント側のコードがexample.comなど、異なるドメインをrpIDとして指定するパスキー操作（作成または認証）を開始します。
2. ブラウザはこの不一致を検出します。古いルールでは、これは即座にSecurityErrorを引き起こしました。
3. RORサポートにより、ブラウザは失敗する前に、_主張された_rpIDのwell-known URL、つまりhttps://example.com/.well-known/webauthnに対してセキュアなHTTPS GETリクエストを行います。このリクエストは、ユーザーのプライバシーを保護し、追跡を防ぐために、ユーザーのクレデンシャル（クッキーなど）やリファラーヘッダーなしで行われます。
4. ブラウザはサーバーからJSONレスポンスを受け取ります。ファイルを解析し、現在のオリジン（https://example.co.uk）がJSONオブジェクト内のorigins配列に存在するかどうかをチェックします。
5. オリジンが許可リストに見つかった場合、WebAuthn操作はexample.comを有効なrpIDとして続行することが許可されます。オリジンが見つからない場合、またはファイルが見つからない、もしくは形式が不正である場合、操作は以前と同様に失敗します。

/.well-known/ URIを使用するという選択は意図的なものであり、RORをサービスディスカバリやドメインコントロール検証のための確立されたウェブ標準と整合させます。RFC 8615で定義されたこのURIパスは、Let's EncryptのSSL証明書発行のためのacme-challengeや、ウェブサイトをAndroidアプリケーションにリンクするためのassetlinks.jsonなど、数多くの重要なプロトコルですでに使用されています。この慣習を採用することで、W3Cはドメインの所有権を本質的に意味するパターンを活用しています。この特定の標準化されたパスにファイルを配置するには、そのドメインのウェブサーバーに対する管理者権限が必要です。これにより、シンプルかつ効果的な管理権限の証明が提供され、信頼の宣言が検証可能になります。example.comの所有者がexample.co.ukを関連オリジンとしてリストしたファイルを提供するとき、それは検証可能な主張となります。このウェブネイティブなアプローチは、標準化プロセス中に検討され却下された、暗号鍵を使用して承認に署名する（RPキー）や、ドメインベースでないランダムな識別子を使用する（RP UUID）といった代替案よりも、はるかにシンプルで堅牢です。RORは、信頼関係をウェブの既存の、よく理解されたドメイン管理モデルに基づかせています。

関連オリジンリクエストを実装するには、オリジンを承認するためのサーバー側と、共有rpIDを呼び出すためのクライアント側の両方で協調した変更が必要です。このセクションでは、ドメイン全体で統一されたパスキー体験を実現するために必要な実践的なコードと設定の詳細を提供します。

主要なrpIDをホストするサーバーは、関連オリジンの許可リストを公開する責任があります。

承認ファイルは、主要なrpIDドメインのルートに対して、正確に/.well-known/webauthnというパスに配置する必要があります。このファイルが以下の条件で提供されることが重要です。

• プロトコル： HTTPSで提供されなければなりません。
• Content-Type： HTTPレスポンスヘッダーのContent-Typeはapplication/jsonに設定されなければなりません。
• ファイル拡張子： URLに.json拡張子を含めてはいけません。正しいパスは/webauthnであり、/webauthn.jsonではありません。

ファイルには、originsという1つのキーを持つ単一のJSONオブジェクトを含める必要があります。その値は文字列の配列です。配列内の各文字列は、承認される完全なオリジン（プロトコル、ドメイン、およびオプションのポート）です。

{
    "origins": ["https://example.co.uk", "https://example.de", "https://example.fr"]
}

例： example.comのrpIDの場合、ファイルはhttps://example.com/.well-known/webauthnで提供されなければなりません（注意：.json拡張子はありません）。

サーバーが.well-known/webauthnファイルで設定されたら、すべての関連ドメインはWebAuthn API呼び出しで一貫して同じ共有rpIDを使用する必要があります。この調整はRORが正しく機能するために不可欠です。

主な調整要件：

1. バックエンドの責任： サーバーは暗号学的チャレンジを生成し、クレデンシャル作成と認証リクエストの両方で共有rpIDを指定します。
2. フロントエンドの責任： すべてのクライアントアプリケーション（example.com、example.co.uk、example.de）は、同じ共有rpIDをブラウザのnavigator.credentials APIに渡す必要があります。
3. 設定管理： 共有rpIDは、すべての関連サイトで一貫して適用される重要なグローバル設定値として扱われる必要があります。

1つのサイトでも設定を誤ると（共有値の代わりに自身のオリジンをrpIDとしてデフォルトで使用するなど）、そのドメインのユーザーにとって統一されたパスキー体験が壊れてしまいます。

重要： サーバーは、すべてのリクエストに対してclientDataJSON内のoriginフィールドを必ず検証し、それが承認された関連オリジンのいずれかと一致することを確認する必要があります。このオリジン検証が主要なフィッシング対策メカニズムです。

関連オリジンリクエスト（ROR）とフェデレーションアイデンティティプロトコル（OIDC/SAML）は、異なる問題を解決します。 RORはシングルサインオンの代替ではなく、特定の狭いユースケースに対応する補完的なものです。

RORは、同じユーザーデータベースを共有する複数の関連ドメインに分散された単一の論理的なアプリケーションに適しています。

• 単一ブランドが複数の国コードTLD（例：amazon.com、amazon.de、amazon.co.uk）を運営している場合
• すべてのドメインが同じバックエンド認証システムとユーザーデータベースを共有している場合
• リダイレクトベースのフローを避け、各ドメインでコンテキストに応じた認証を維持したい場合
• ドメインが5ラベル制限の範囲内である場合
• ユーザーにすべてのドメインを一つのまとまったサービスとして体験させたい場合

RORが提供するもの： 同じパスキーがすべての関連ドメインで機能し、ユーザーが各地域サイト用に別々のパスキーを作成する必要がなくなります。

異なるアプリケーション間での真のシングルサインオンには、フェデレーションアイデンティティプロトコルを使用します。

• 複数のサービスが別々のユーザーデータベースやアイデンティティシステムを持っている場合
• ユーザーが多くの異なるアプリケーション（Salesforce, Office 365, 社内ツール）にアクセスする必要があるエンタープライズシナリオ
• サードパーティアプリケーションの統合
• 一元化されたアクセス制御、監査証跡、アイデンティティガバナンスが必要な場合
• 関連オリジンの5ラベル制限を超える場合

OIDC/SAMLが提供するもの： アイデンティティプロバイダ（IdP）で一度ログインすれば、セキュアなトークンを通じて複数のサービスプロバイダ（SP）にアクセスできる一元化された認証。

重要： パスキーは両方のアプローチで使用できます。フェデレーションSSOのために一元化されたIdPにパスキーを実装することも、複数ドメインの単一アプリケーションにRORを使用することも可能です。認証方法ではなく、アーキテクチャに基づいて選択してください。

RORは強力な技術的ソリューションですが、その実装は慎重な戦略的決定であるべきです。アーキテクトやプロダクトマネージャーは、その利点を代替パターンと比較検討し、その制限を理解して、堅牢で将来性のある認証システムを構築する必要があります。

RORの重要な制約の一つに「ラベル制限」があります。ここでの「ラベル」とは、有効なトップレベルドメインプラスワンレベル（eTLD+1）を指し、これはドメイン名の登録可能な部分です。例えば、

• shopping.com、shopping.co.uk、shopping.caはすべて単一のラベル**「shopping」**を共有します。
• myshoppingrewards.comは、新しい別個のラベル**「myshoppingrewards」**を導入します。
• travel.shopping.comは、依然として**「shopping」**ラベルに分類されます。

WebAuthnレベル3仕様では、ブラウザ実装はoriginsリスト内で最低5つのユニークなラベルをサポートすることが求められています。 2025年現在、この最低5ラベルを超えるサポートをしている既知のブラウザはありません。したがって、組織はRORの展開をこの厳しい制限を念頭に置いて設計すべきです。5つを事実上の最大値として扱ってください。

この制限は、悪用を防ぐために意図的に設けられた乱用防止メカニズムです。これにより、共有ホスティングプロバイダー（例：wordpress.com）などが、何千もの無関係な顧客のサブドメインで機能する可能性のあるユニバーサルなパスキーを作成することを阻止し、セキュリティモデルを損なうことを防ぎます。

ほとんどの組織、大規模な多国籍ブランドでさえ、この5ラベル制限で十分です。例えば、Amazonのさまざまな国コードTLD（amazon.com, amazon.de, amazon.co.ukなど）はすべて「amazon」ラベルを共有しており、「audible」や「zappos」といったポートフォリオ内の他のブランドのために追加で4つのラベルスロットが利用可能です。

RORの実装の複雑さは、それが新しいシステムに導入されるか、既存のシステムに後付けされるかによって大きく異なります。

• 新規展開（Greenfield）： 新しいプロジェクトの場合、戦略は単純です。最初から単一の正規ドメインを共有rpIDとして選択します（例：主要な.comドメイン）。このrpIDは、初日からすべての関連ウェブサイトやアプリケーションの設定で一貫して使用されるべきです。
• 既存の展開： 複数のドメインで異なるrpIDを持つパスキーが既に展開されているシステムにRORを後付けするのは、かなり複雑です。既存のパスキーは元のrpIDに永久に紐付けられているため、直接的な移行は不可能です。このシナリオで推奨されるアプローチは、「識別子ファースト」のログインフローを実装することです。まずユーザーにユーザー名またはメールアドレスの入力を促します。次にバックエンドは、ユーザーの既存のパスキーがどのrpIDに関連付けられているかを特定するためのルックアップを実行します。最後に、ユーザーはそのrpIDに対応する正しいオリジンにリダイレクトされ、認証セレモニーを完了します。ログインが成功した後、元のサイトにリダイレクトして戻すことができます。これは、慎重な計画と実装を必要とする、かなりのアーキテクチャ上の取り組みです。

確立された企業が関連オリジンリクエストをどのように実装しているかを理解することは、自身の展開戦略にとって貴重な洞察を提供します。以下は、実際の実装（2025年10月現在）に基づく例です。

Microsoftは認証インフラにRORを使用しています。login.microsoftonline.comでの実際の設定は次のとおりです。

// https://login.microsoftonline.com/.well-known/webauthn
{
    "origins": ["https://login.microsoftonline.com", "https://login.live.com"]
}

この保守的なアプローチにより、Microsoftのエンタープライズ向けログインポータルとコンシューマー向けログインポータル間でのパスキー共有が可能になり、同時に焦点を絞ったセキュリティ境界を維持しています。

Shopifyは、選択したドメイン間で認証を統一するためにRORを実装しています。

// https://shopify.com/.well-known/webauthn
{
    "origins": ["https://shopify.com", "https://shop.app"]
}

この設定により、ShopifyはメインプラットフォームとShopアプリを接続でき、関連オリジンに対する焦点を絞ったアプローチを示しています。

Amazonはかなり大きなファイルを持っています。

// https://amazon.com/.well-known/webauthn
{
    "origins": [
        "https://www.amazon.com",
        "https://www.amazon.com.br",
        "https://www.amazon.com.mx",
        "https://www.amazon.ca",
        "https://www.amazon.co.uk",
        "https://www.amazon.de",
        "https://www.amazon.it",
        "https://www.amazon.es",
        "https://www.amazon.nl",
        "https://www.amazon.se",
        "https://www.amazon.sa",
        "https://www.amazon.pl",
        "https://www.amazon.com.tr",
        "https://www.amazon.fr",
        "https://www.amazon.com.au",
        "https://www.amazon.sg",
        "https://www.amazon.ae",
        "https://www.amazon.eg",
        "https://www.amazon.co.za",
        "https://www.amazon.in",
        "https://brandregistry.amazon.com",
        "https://sellercentral.amazon.com",
        "https://sellercentral.amazon.com.br",
        "https://sellercentral.amazon.com.mx",
        "https://sellercentral.amazon.ca",
        "https://sellercentral.amazon.co.uk",
        "https://sellercentral.amazon.de",
        "https://sellercentral.amazon.it",
        "https://sellercentral.amazon.es",
        "https://sellercentral.amazon.nl",
        "https://sellercentral.amazon.se",
        "https://sellercentral.amazon.sa",
        "https://sellercentral.amazon.pl",
        "https://sellercentral.amazon.com.tr",
        "https://sellercentral.amazon.fr",
        "https://sellercentral.amazon.com.au",
        "https://sellercentral.amazon.sg",
        "https://sellercentral.amazon.ae",
        "https://sellercentral.amazon.eg",
        "https://sellercentral.amazon.co.za",
        "https://sellercentral.amazon.in",
        "https://na.account.amazon.com",
        "https://vendorcentral.amazon.com",
        "https://vendorcentral.amazon.com.br",
        "https://vendorcentral.amazon.com.mx",
        "https://vendorcentral.amazon.ca",
        "https://vendorcentral.amazon.co.uk",
        "https://vendorcentral.amazon.de",
        "https://vendorcentral.amazon.it",
        "https://vendorcentral.amazon.es",
        "https://vendorcentral.amazon.nl",
        "https://vendorcentral.amazon.se",
        "https://vendorcentral.amazon.pl",
        "https://vendorcentral.amazon.com.tr",
        "https://vendorcentral.amazon.fr",
        "https://vendorcentral.amazon.com.au",
        "https://vendorcentral.amazon.co.za"
    ]
}

このパターンにより、ブランドは主要な.comドメインをrpIDとして使用しながら、地域ドメイン全体で統一されたパスキー認証を提供できます。

これらの実例から、いくつかの重要なパターンが明らかになります。

1. 主要ドメインをrpIDとして使用：すべての企業が、自社の主要な.comドメインを正規のrpIDとして使用しています。
2. 論理的なグルーピング：オリジンは技術的なアーキテクチャではなく、ビジネス機能によってグループ化されています。
3. 保守的なスコープ：ほとんどの実装は5ラベル制限を大幅に下回っており、通常3〜4つのオリジンを使用しています。
4. サブドメイン戦略：多くの企業が、ブランドの一貫性を維持するために主要ドメインのサブドメインを使用しています。

現代のウェブ標準として、RORはセキュリティを第一に考慮して設計されており、主要なブラウザで積極的に採用が進んでいます。

関連オリジンリクエストは、WebAuthnの中核となるアンチフィッシング保証を損なうことはありません。このメカニズムは、強力なセキュリティ体制を維持するように慎重に設計されています。

• オリジン検証： 前述の通り、ブラウザは依然としてリクエストの真のオリジンを署名付きのclientDataJSONに含めます。Relying Partyサーバーは、リクエストが期待されるソースから来ていることを確認するためにこのオリジンを必ず検証する必要があり、これにより、侵害された関連オリジンが別のオリジンになりすますことを防ぎます。
• セキュアなフェッチ： ブラウザによる.well-known/webauthnファイルへのリクエストはHTTPS経由で行われます。さらに、仕様ではこのフェッチをクレデンシャル（例：クッキー）なしで、かつRefererヘッダーなしで実行することが義務付けられています。これにより、リクエストがユーザー情報の漏洩やクロスサイトトラッキング目的に使用されるのを防ぎます。
• サーバーのセキュリティ： .well-known/webauthnファイル自体が重要なセキュリティ資産となります。主要なrpIDをホストするウェブサーバーの制御を奪った攻撃者は、このファイルを改ざんして自身の悪意のあるドメインを許可リストに追加する可能性があります。したがって、このファイルを提供するインフラを保護することが最も重要です。

関連オリジンリクエストは、WebAuthn Level 3仕様の機能です。ブラウザのサポートは2024年後半から展開が始まりました。

主な事実：

• ChromeとEdge： バージョン128（2024年8月）でRORサポートを追加しました。
• Safari： Safari 18でRORサポートを追加し、macOS 15およびiOS 18（2024年9月）で利用可能です。
• Firefox： 現在RORのサポートはなし。機能検出を行い、フォールバックフローを実装してください。

古いブラウザやFirefoxをサポートする必要があるアプリケーションでは、フォールバック戦略を実装してください。

1. 機能検出： PublicKeyCredential.getClientCapabilities() を使用してRORのサポートを確認します。
2. 識別子ファーストフロー： ユーザー名/メールアドレスの入力を促し、ユーザーに関連付けられたrpIDを検索し、認証のために適切なオリジンにリダイレクトします。
3. 段階的な機能低下： RORが利用できない場合、ユーザーがドメインごとに個別のパスキーを作成できるようにします。

データは2025年10月現在のサポートマトリックスに基づいています。

関連オリジンリクエストの実装には、複数の技術チーム間の慎重な調整と、WebAuthnプロトコルに関する深い専門知識が必要です。Corbadoのパスキー導入プラットフォームは、複数ドメインのパスキー展開に対応するエンタープライズ向けのソリューションを提供することで、この複雑さを解消します。

Corbadoは、関連オリジンリクエストの技術的な複雑さを次のように処理します。

• 自動設定：当社のプラットフォームは、適切なセキュリティヘッダーとJSONフォーマットを備えた必要な.well-known/webauthnファイルを自動的に生成し、ホストします。
• 複数ドメインダッシュボード：ドメインポートフォリオ全体で関連オリジンを設定するための一元管理インターフェース。
• 検証ツール：ROR設定がすべてのブラウザとプラットフォームで正しく機能することを確認するための組み込みのテストと検証。

技術的な実装を超えて、Corbadoは企業が必要とするセキュリティフレームワークを提供します。

• オリジン検証：関連ドメインの乱用を防ぐためのclientDataJSONオリジンの自動検証。
• 監査ロギング：コンプライアンスとセキュリティ監視のために、すべての関連ドメインにわたるパスキー使用状況の包括的な追跡。
• インシデント対応：疑わしいクロスドメイン認証試行に対するリアルタイムのアラートと自動応答。

既存のパスキー展開を持つ組織のために、Corbadoは以下を提供します。

• レガシー移行ツール：既存のrpID設定の自動分析と移行パスの推奨。
• 識別子ファーストフロー：移行期間中の複雑な複数rpIDシナリオを処理する事前構築済みのログインコンポーネント。
• API統合：既存の認証インフラとシームレスに統合するRESTful APIとSDK。

あなたの組織で関連オリジンリクエストを実装する準備はできましたか？Corbadoの専門家チームが、デジタルエコシステム全体で統一されたパスキー体験の設計と展開をお手伝いします。具体的な要件とタイムラインについて、当社のソリューションチームにお問い合わせください。

パスキーの約束は、より安全で、ユーザーにとって著しくシンプルな未来を提供できることにあります。しかし、この未来が世界規模で現実のものとなるためには、標準が現代のデジタルブランドのアーキテクチャ上の複雑さに対応しなければなりません。厳密にドメインに縛られたパスキーによって生じる摩擦は、多面的なオンラインプレゼンスを持つ組織にとって、導入の大きな障壁となってきました。

WebAuthn関連オリジンリクエストは、この問題に対する標準化された、安全で、洗練されたソリューションを提供します。単一のパスキーが信頼できる一連の関連ドメイン間でシームレスに機能できるようにすることで、RORはユーザーの混乱と不満の大きな要因を取り除きます。

このガイドでは、WebAuthn関連オリジンリクエストを実装するための5つの重要な問いに取り組みました。

1. なぜパスキーは複数のドメインで機能しないのか？ WebAuthnのオリジンに紐づくセキュリティモデルは、フィッシングを防ぐためにパスキーを特定のドメインに暗号学的にロックしますが、これはブランドが異なる国のTLDなど複数のドメインで事業を展開する場合に摩擦を生じさせます。
2. 関連オリジンリクエストは技術的にどのように機能するのか？ RORは、標準化された.well-known/webauthnファイルを使用して検証可能な関連ドメインの許可リストを作成し、ブラウザが安全なHTTPSフェッチプロセスを通じてクロスドメインでのパスキー使用を検証できるようにします。
3. RORを実装するために何が必要か？ 実装には、.well-known/webauthnマニフェストファイルのサーバー側での設定と、すべての関連オリジンで一貫して共有rpIDを使用するためのクライアント側の調整が必要です。
4. いつRORをフェデレーションログインより選ぶべきか？ 共有ユーザーデータベースを持つ関連ドメイン間での統一されたブランド体験にはRORを使用し、異なるアプリケーション間での真のSSOや5ラベル制限を超える場合にはOIDC/SAMLを使用します。
5. ブラウザの互換性とセキュリティの考慮事項にどう対処するか？ RORは、Chrome/Firefox 128以上、macOS 15以上のSafari、およびiOS 18以上などの主要なブラウザでサポートされており、古いブラウザ向けには識別子ファーストフローによるフォールバック戦略が利用可能です。

技術チームやプロダクトリーダーにとって、重要な点は以下の通りです。

• RORは、異なる国コードTLDや代替ブランディングを持つドメインなど、複数のドメインにまたがる単一の論理的アプリケーションに対して、統一されたパスキー体験を可能にします。
• 実装には協調した取り組みが必要です。主要なrpIDのドメインでサーバー側の.well-known/webauthnファイルを公開し、すべてのクライアント側アプリケーションでその同じ共有rpIDを使用するように設定する必要があります。
• RORを使用するという決定は戦略的なものです。特定のユースケースには優れたツールですが、特に異なるアプリケーション間での真のシングルサインオンを含むシナリオでは、より伝統的なフェデレーションログインアーキテクチャ（OIDC/SAML）と比較検討されるべきです。

関連オリジンリクエストのような機能は、パスワードレスムーブメントの継続的な勢いにとって不可欠です。これらは、標準化団体が現実世界の実装課題に取り組むというコミットメントを示しており、パスキーの利点である比類なきセキュリティと簡単なユーザー体験が、最大かつ最も複雑な組織でさえも利用可能になることを保証します。この機能がユニバーサルなブラウザサポートを得るにつれて、真にグローバルな、パスワードレスのインターネットへの最後の障壁を打ち破る上で、重要な役割を果たすことになるでしょう。