--- url: 'https://www.corbado.com/ja/blog/webauthn-relying-party-id-rpid-passkeys' title: 'WebAuthnのRelying Party ID (rpID) とパスキー：ドメインとネイティブアプリ' description: '本記事では、パスキー認証におけるWebAuthnのRelying Party ID（rpID）について解説します。適切な設定、ドメインマッチング、ネイティブアプリの設定の概要を説明します。' lang: 'ja' author: 'Vincent Delitz' date: '2026-06-15T13:54:56.520Z' lastModified: '2026-06-16T06:02:44.761Z' keywords: 'Relying Party ID, WebAuthn, パスキー, ドメインマッチング, ネイティブアプリ, フィッシング耐性, apple-app-site-association, assetlinks.json' category: 'WebAuthn Know-How' --- # WebAuthnのRelying Party ID (rpID) とパスキー：ドメインとネイティブアプリ ## Key Facts - **Relying Party ID**はすべてのパスキーに埋め込まれるドメインです。ブラウザのオリジンが一致しない場合、認証は失敗するため、パスキーは強力なフィッシング耐性を持ちます。 - **RP ID**は**Public Suffix List**（パブリックサフィックスリスト）に登録されているものであってはならず、変更すると既存のすべてのパスキーが無効になります。将来的な拡張性を考慮して、デフォルトではルートドメインを使用してください。 - iOSアプリは、RP IDの下の`/.well-known/`に**apple-app-site-association**ファイルを配置する必要があります。Androidでは、同じパスに**assetlinks.json**が必要です。新しいファイルがキャッシュされるまでに最大24時間かかる場合があります。 - 複数のルートドメインでパスキーを共有するには、`.well-known/webauthn`を介した**Related Origin Requests**が必要です。ウェブとネイティブのすべてのアプリで1つのRP IDを持つ単一のWebAuthnサーバーを使用してください。 ## 1. はじめに [TikTok](https://www.corbado.com/blog/tiktok-passkeys)、GitHub、[WhatsApp](https://www.corbado.com/blog/whatsapp-passkeys)、X（[Twitter](https://www.corbado.com/blog/x-twitter-passkeys)）、[LinkedIn](https://www.corbado.com/blog/linkedin-passkeys)、Amazonなどのテクノロジー大手が導入を進めている、あるいはすでに導入していることから、パスキー認証は急速に標準となりつつあります。テクノロジー業界が、シンプルで安全な認証の重要性を認識していることは明らかです。 [Face ID](https://www.corbado.com/faq/is-face-id-passkey)、Touch ID、[Windows Hello](https://www.corbado.com/glossary/windows-hello)などを使用した認証のシームレスなユーザーエクスペリエンスに加え、パスキーはパスワードのような従来の認証方法と比較して比類のないセキュリティを提供します。その際立った特徴の1つが、強力なフィッシング耐性です。 フィッシング攻撃とは、被害者を騙して元のサイトを模倣した偽のサイトにクレデンシャルを提供させる攻撃です。例えば、銀行を装ったメールを受信し、ログインを求められたとします。リンクをクリックすると、ウェブサイトが本物のように見えるため、クレデンシャルを入力してしまい、攻撃者はそれを使って元のサイトにログインできるようになります。これはデジタル時代においてますます深刻な問題となっており、[Okta](https://www.darkreading.com/application-security/okta-flaw-involved-mgm-resorts-breach-attackers-claim)（認証プロバイダーです！）や[Retool](https://retool.com/blog/mfa-isnt-mfa/)のような大企業でさえスピアフィッシング攻撃（特定の被害者を狙い撃ちにし、非常に個人的な手口を用いるフィッシングの特殊な形態）の犠牲となっており、堅牢なセキュリティ対策の必要性が強調されています。 対照的に、パスキーを使用している場合、サイトが偽物であれば認証は失敗します。これは、**Relying Party ID**を介して、パスキーが作成されたドメインにバインドされているためです。 > パスキーを使って他のサイトにログインすることはできないため、パスキーは強力なフィッシング耐性を持ちます（ただし、すべての攻撃ベクトルに対して完全に免疫があるシステムはありません）。 このメカニズムは、パスワードレス認証の基盤となるウェブ標準であるWebAuthnに組み込まれています。WebAuthnは、登録と認証という2つのコアセレモニーに基づいて構築されています。 登録（サインアップ）セレモニーでは、ウェブまたはネイティブアプリを介して、オンラインサービス（[Relying Party](https://www.corbado.com/glossary/relying-party)）用の新しいパスキーが作成されます。このプロセスで、パスキーが作成されたドメイン（[Relying Party](https://www.corbado.com/glossary/relying-party) ID）がパスキー内に保存されます。 これにより、認証（ログイン）セレモニーにおいて、ウェブまたはネイティブアプリが属するオンラインサービス（[Relying Party](https://www.corbado.com/glossary/relying-party)）が、パスキーに保存されているRelying Party IDと一致するかどうかを確認できます。 以下では、この[ドメインマッチング](#what-relying-party-id)プロセスがどのように機能するか、そして特にネイティブアプリがどのように保護されるかを詳しく説明します。 ## 2. Relying Party IDとは？ [**Relying Party ID**](https://www.w3.org/TR/webauthn-2/#relying-party-identifier)は本質的にパスキー内に保存されるドメインであり、現在のブラウザURL（すべてのリクエストで自動的に送信されるユーザーのオリジン）がそれと一致する場合にのみパスキーが機能することを保証します（[後述](#integration-options-native-apps)のネイティブアプリのアプローチを参照）。これはWebAuthn仕様の重要なコンポーネントであり、詳細については[こちら](https://www.w3.org/TR/webauthn-2/)を参照できます。Relying Party IDには、ルートドメイン（例：`corbado.com`）またはサブドメイン（`auth.corbado.com`）を指定できます。ルートドメインがパブリックサフィックスリストに含まれている場合、それをRelying Party IDとして保存することはできません（リストおよびパブリックサフィックス検出用ライブラリは[こちら](https://publicsuffix.org/learn/)を参照）。オンラインサービスのRelying Party IDを変更すると、既存のパスキーは機能しなくなります（例外：新しいRelying Party IDが古いRelying Party IDのサブドメインである場合、または関連ドメイン間でのパスキーの再利用を許可するために`.well-known/webauthn`を介してRelated Origin Requestsが設定されている場合）。 認証プロセス中、Relying Party IDはブラウザのURL（ユーザーのオリジン）と照合され、一致することが確認されます。この意味での「一致」とは、次のいずれかを指します。 - ブラウザのURL（ユーザーのオリジン）がRelying Party IDと正確に一致する - ブラウザのURL（ユーザーのオリジン）がRelying Party IDと一致するサブドメインであり、親ドメインが登録可能である（例：`com`やパブリックサフィックスリストに載っているドメインは機能しません） 以下は、どの _originalHost_ （2列目）がその親ドメインへのアクセスを許可されるかの詳細な概要です。 ![relying party id table](https://www.corbado.com/website-assets/relying_party_id_table_4c98cc04f4.jpg) 以下に、解析された[**PublicKeyCredentialCreationOptions**](https://www.w3.org/TR/webauthn-2/#iface-pkcredential)を示します。 ```json { "publicKey": { "attestation": "direct", "authenticatorSelection": { "authenticatorAttachment": "platform", "requireResidentKey": false, "userVerification": "preferred" }, "challenge": "qNqrdXUrk5S7dCM1MAYH3qSVDXznb-6prQoGqiACR10=", "excludeCredentials": [], "pubKeyCredParams": [ { "alg": -7, "type": "public-key" } ], "rp": { "id": "corbado.com", "name": "Corbado" }, "timeout": 30000, "user": { "displayName": "Corbado user", "id": "bz9ZDfHzOBLycqISTAdWwWIZt8VO-6mT3hBNXS5jwmY=" } } } ``` `rp`はRelying Partyの略です。 Relying Party IDの主な利点の1つは、フィッシング攻撃の防止です。次のようなシナリオを想像してください。 1. 攻撃者が、あなたの名前でログインし、攻撃者の口座に送金するために[PayPal](https://www.corbado.com/blog/paypal-passkeys)のクレデンシャルを盗もうとする偽のウェブサイトである[PayPal](https://www.corbado.com/blog/paypal-passkeys)クローンを開発します。この偽の[PayPal](https://www.corbado.com/blog/paypal-passkeys)ウェブサイトはpaybal.comというドメインでホストされています（一見しただけでは別のドメインであることがわからないことがよくあります）。 2. あなたは過去に、正規のPayPalサイトでパスキーを既に作成しています。このパスキーにはRelying Party IDとしてpaypal.comが保存されています。 3. あなたがpaybal.comのPayPal偽ウェブサイトにアクセスすると（このサイトにアクセスした時点でのリクエストのオリジンはpaybal.comです\*）、サイトはあなたのデバイス（オーセンティケーター）にRelying Party ID `paypal.com`のチャレンジを送信し（ここであなたを騙そうとします）、Relying Party ID paypal.comのパスキーでそれに署名するよう求めます。 4. あなたのデバイス（オーセンティケーター）は、リクエストのオリジン（`paypal.com`）と、パスキーに保存されているRelying Party ID（`paypal.com`）が一致するかどうかを確認します。 5. 明らかに一致しないため、認証は失敗し、攻撃者にPayPalアカウントへのアクセスを許してしまう事態を防ぎます。 以下の図は、このフィッシング防止のメカニズムを示しています。 _ネイティブアプリの場合、オリジンの扱いはプラットフォームによって異なります。Androidでは、オリジンは`android:apk-key-hash:`としてフォーマットされます。iOSでは、WebAuthnのオリジンはRPウェブオリジン（例：`https://paypal.com`）です。どちらの場合も、ネイティブアプリとサーバー間の信頼性は対応するアソシエーションファイルを介して検証されます（[後述](#configuring-relying-party-native-apps)を参照）。ネイティブアプリでのオリジン検証がどのように機能するかの詳細については、ネイティブアプリのWebAuthnオリジン検証に関する専用ガイドを参照してください。_ ## 3. ネイティブアプリ向けの2つの異なる統合オプション ネイティブアプリにパスキーを実装する場合、開発者は[WebView](https://www.corbado.com/blog/native-app-passkeys)経由で追加するか、ネイティブに追加するかを選択できます。以下で両方のアプローチの利点と欠点を検証しましょう。 ### 3.1 WebViewによるパスキー統合 ![Passkey Integration WebView (GitHub)](https://www.corbado.com/website-assets/650c601b1eb462e25702a870_android_webview_passkey_github_8bc81d9852.jpg) **WebView**\*を使用してパスキーを統合するということは、ネイティブアプリ内にウェブブラウザを埋め込んで認証プロセスを処理することを意味します。このアプローチでは、基本的にはアプリ内にウェブページが表示されるため、ネイティブプラットフォーム用に書き直すことなく、ウェブベースの認証フローを簡単に再利用できます。ただし、いくつかの欠点があります。[WebView](https://www.corbado.com/blog/native-app-passkeys)はすべてのパスキー機能をサポートしていない可能性があり、安全に実装されていない場合、「中間者（man-in-the-middle）」攻撃の潜在的なリスクがあります。さらに、ユーザーエクスペリエンスがネイティブ統合ほどスムーズでない可能性があり、異なるデバイスやOSバージョン間で一貫した動作を維持する上で課題が生じることがあります。 _\*WebViewには複数の種類があります：iOS（WKWebView、SFSafariViewController、またはOAuth/OpenID Connectベースの認証フロー用のSFAuthenticationSession / ASWebAuthenticationSession）およびAndroid（WebView、CCT-Chrome Custom Tabs）。詳細についてはこちらのブログ記事を参照してください。ネイティブ統合を希望しない場合、パスキーのコンテキストではSFSafariViewController/ASWebAuthenticationSessionとChrome Custom Tabsを使用することをお勧めします。_ ### 3.2 ネイティブパスキー統合 ![Native Passkey Integration (Kayak)](https://www.corbado.com/website-assets/650c625cac723f594137a029_android_native_passkey_kayak_0f689e761e.jpg) **ネイティブ統合**には、プラットフォーム固有のAPIとライブラリを使用して、[iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios)または[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)アプリに直接パスキー機能を組み込むことが含まれます。この方法では、ネイティブアプリと[WebView](https://www.corbado.com/blog/native-app-passkeys)間を移行する必要がないため、よりシームレスなユーザーエクスペリエンスが提供されます。また、パフォーマンスが向上し、より一貫したルックアンドフィールが可能になります。セキュリティの観点から見ると、ネイティブ統合は、特にプラットフォーム固有のセキュリティ機能と組み合わせた場合、特定の種類の攻撃に対する保護を強化できます。ただし、開発者は各プラットフォーム（[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)と[iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios)）用に個別のコードを記述して保守する必要があるため、実装の労力が大きくなる可能性があります。さらに、最新のパスキー / WebAuthn仕様を常に最新の状態に保つには、より頻繁にアプリを更新する必要があるかもしれません。 以下では、ネイティブパスキー統合に焦点を当てます。 ## 4. ネイティブアプリ用のRelying Partyの設定 ネイティブアプリ（iOSや[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)アプリなど）は、ウェブアプリに比べて課題があります。ウェブアプリとは異なり、Relying Party IDと照合するためのブラウザURLがありません。それにもかかわらず、同じレベルのセキュリティを確保するために、ドメインは**アソシエーションファイル**を介してネイティブアプリに接続され、ドメインとネイティブアプリ間の信頼関係が確立されます。 これは、パスキーがウェブアプリで作成され、同じRelying Party IDのネイティブアプリで使用される場合（またはその逆）に特に重要です。 ### 4.1 iOSのアソシエーションファイル：apple-app-site-association iOSは[apple](https://www.corbado.com/ja/blog/how-to-enable-passkeys-macos)-app-site-associationファイルを使用します。このファイルには様々なエンタイトルメントが含まれていますが、WebAuthnとパスキーにはwebcredentialsエンタイトルメントが重要です。 ```json { "webcredentials": { "apps": ["9RF9KY88B2.com.corbado.passkeys"] } } ``` webcredentials.appsに、Application Identifier Prefix（例：`9RF9KY77B2`）とBundle Identifier（例：`com.corbado.passkeys`）を保存する必要があります。 iOSのネイティブアプリが機能するためには、[apple](https://www.corbado.com/ja/blog/how-to-enable-passkeys-macos)-app-site-associationファイルはRelying Party IDの`/.well-known`ディレクトリ（`https:///.well-known/apple-app-site-association`）に保存されている必要があります。 ライブの例は[こちら](https://pro-6244024196016258271.frontendapi.cloud.corbado.io/.well-known/apple-app-site-association)をご覧ください。 ### 4.2 Androidのアソシエーションファイル：assetlinks.json Androidは`assetlinks.json`ファイルを使用しますが、iOSのファイルと同様に、WebAuthnとパスキーのための特別な設定が必要です。 ```json [ { "relation": [ "delegate_permission/common.handle_all_urls", "delegate_permission/common.get_login_creds" ], "target": { "namespace": "android_app", "package_name": "com.corbado.passkeys.pub", "sha256_cert_fingerprints": [ "F8:90:4E:9A:99:01:71:75:25:38:D5:36:16:2D:B3:65:EB:41:51:D4:53:9A:72:BC:4B:56:C5:16:43:62:E2:C0" ] } } ] ``` relation値に`delegate_permission/common.handle_all_urls`と`delegate_permission/common.get_login_creds`を設定する必要があります。さらに、パッケージ名と署名証明書のSHA-256フィンガープリントを追加する必要があります。 ネイティブアプリとウェブアプリ間でパスキーの共有を許可するには、2つのエントリを追加する必要があります。1つはnamespace web用で、もう1つはnamespace android_app用です。 ライブの例は[こちら](https://pro-6244024196016258271.frontendapi.cloud.corbado.io/.well-known/assetlinks.json)をご覧ください。 Androidアプリが機能するためには、assetlinks.jsonファイルはRelying Party IDの`/.well-known`ディレクトリ`https:///.well-known/assetlinks.json`に保存されている必要があります（iOSとほぼ同じです）。 ネイティブのAndroid / iOSアプリとウェブアプリ間でパスキーを共有する実装のサンプルを見るには、こちらのブログ記事をチェックしてください。 ## 5. ネイティブアプリとウェブアプリ間の信頼関係の確立 ### 5.1 iOS iOSアプリとウェブアプリ間の信頼関係を確立するプロセスは以下のようになります。 1. iOSアプリ開発者は、ネイティブアプリに関連付けたいドメインのリストを指定する必要があります。これらのドメインはiOSアプリのエンタイトルメントにハードコードされます。例： - webcredentials:auth.Corbado.com - webcredentials:\*.Corbado.com 2. iOSアプリがインストールまたは更新されるたびに、iOSはアプリのエンタイトルメントリストの各エントリについて、[apple](https://www.corbado.com/ja/blog/how-to-enable-passkeys-macos)-app-site-associationファイルをダウンロードします。 3. iOSアプリ内でクレデンシャル（パスキーなど）が作成されると、iOSアプリは以下の2点を確認して、Relying PartyサーバーのドメインがiOSアプリに関連付けられているかを検証します。 - このRelying Partyサーバーのドメインの`apple-app-site-association`ファイルがデバイス上に存在するか？ - iOSアプリがその`apple-app-site-association`ファイルにリストされているか？ この両方の質問に「はい」と答えられる場合にのみ、iOSアプリ内でパスキーを作成できます。 ### 5.2 Android Androidアプリとウェブアプリ間の信頼関係を確立するプロセスは以下のようになります。 1. Androidアプリ開発者は、Androidアプリに関連付けたいドメインのリストを指定する必要があります。これらのドメインはassetlinks.jsonファイル内にnamespace webのターゲットとして保存されます。Androidアプリとウェブアプリがクレデンシャルを共有することを宣言するには、`delegate_permission/common.get_login_creds`を指定する必要があります。詳細は[こちら](https://developer.android.com/training/sign-in/passkeys#add-support-dal)をご覧ください。 2. Androidアプリ内でパスキーが作成された場合、Androidアプリは`assetlinks.json`を確認して、Relying Party IDがAndroidアプリに関連付けられているかを検証します。 - このRelying Party IDの`assetlinks.json`ファイルが`https://./well-known/assetlinks.json`に存在するか。 - Androidアプリがターゲットとして正しく定義されているか。 3. この両方の質問に「はい」と答えられる場合にのみ、Androidアプリ内でパスキーを作成できます。 以下の図は、これらの信頼確立プロセスを並べて比較したものです。 ## 6. Android、iOS、およびFlutterの設定の概要 以下に、ネイティブアプリでパスキー認証を適切に設定するために必要なさまざまな設定の詳細な概要を示します。 | 機能 | iOS | Android | | --------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ネイティブパスキー認証の公式実装ガイダンス | Apple Developer | Google Developer | | ウェブアプリとのパスキー共有を許可 | はい、apple-app-site-associationファイル経由 | はい、assetlinks.json経由 | | アソシエーションファイルの場所 | [https://acme.com/.well-known/apple-app-site-association](https://acme.com/.well-known/apple-app-site-association) | [https://acme.com/.well-known/assetlinks.json](https://acme.com/.well-known/assetlinks.json) | | ファイルはキャッシュされるか | はい（iOS 14以降）、最初の同期に最大24時間かかる場合があります | はい（Play開発者サービスによる） | | バイパスは可能か | はい、alternate modeセクションを使用 | いいえ | | テスト可能か | apple-app-site-associationテスト | assetlinks.jsonテスト | | サンプル付きアプリ識別子 | `.`、例：`T84QZS65DQ.com.facebook.Messenger` | SHA256フィンガープリント、例：`E3:F9:E1:E0:CF:99:D0:E5:6A:05:5B:A6: 5E:24:1B:33:99: 7F:CE:A5:24:32: 6B:0C:DD:6E:C1:32: 7E:D0:FD:C1` | | アプリ識別子の見つけ方 | Team Application Identifier Prefixはdeveloper.apple.comの開発者アカウントにあり、Bundle IdentifierはXCodeプロジェクト内にある正確な名前です | 既にアップロード済みの場合：Google Play Console > Release management > App signing ローカルの場合：`keytool -list -v -keystore -alias -storepass -keypass ` | | アプリとウェブをリンクするセクションの名前 | applinks（パスキーには不要） | `delegate_permission/common.handle_all_urls`（パスキーに必要） | | アプリ/ウェブ間でのクレデンシャル共有を許可するセクションの名前 | webcredentials | `delegate_permission/common.get_login_creds` | | すべてのアソシエーションファイルのレジストリ | XCode開発環境で関連ドメインを有効にして追加（エンタイトルメントファイルを生成するためのプロパティの設定） | Credential Manager APIを使用する場合、パスキーについてはマニフェストでのassetlinks.jsonのレジストリは不要です（ただしパスワードには必要です）。Credential Manager APIを使用しない場合は、特定のアクティビティ（Androidアプリソースコードの一部）のAndroidManifest.xmlの``エントリでホスト名をリストする必要があります。``はautoVerify=trueである必要があります。 | [Flutter](https://www.corbado.com/blog/flutter-passkeys-package)の場合、AndroidまたはiOSのそれぞれのルールが適用されます。唯一の[Flutter](https://www.corbado.com/blog/flutter-passkeys-package)固有の設定はアソシエーションファイルのレジストリであり、以下を追加する必要があります。 - Androidの場合：[AndroidManifest.xmlにflutter_deeplinking_enabledを追加](https://docs.flutter.dev/cookbook/navigation/set-up-app-links) - iOSの場合：[Info.plistにFlutterDeepLinkingEnabled trueを追加](https://docs.flutter.dev/cookbook/navigation/set-up-universal-links) ## 7. 有効および無効なRelying Party IDとアソシエーションファイルの例 私たち自身が経験したように、Relying Party ID、様々なレベルの（サブ）ドメイン、およびCNAMEを扱うことは非常に困難な作業になる可能性があるため、4つの異なる例を提示し、それらがなぜ、どのように機能するのかを説明します。 なお、CNAMEの表の行はパスキー認証には必須ではなく、単に追加したかった私たちの調査の結果です。 ### 7.1 例1：Relying Partyがルートドメイン | **Relying Party ID** | corbado.com | | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | **エンタイトルメント（iOSのみ）** | webcredentials:corbado.com | | **apple-app-site-associationファイルの場所** | [https://corbado.com/.well-known/apple-app-site-association](https://corbado.com/.well-known/apple-app-site-association) | | **assetlinks.jsonファイルの場所** | [https://corbado.com/.well-known/assetlinks.json](https://corbado.com/.well-known/assetlinks.json) | | **CNAME** | 該当なし | この例では、Corbado.comの`apple-app-site-association` / `assetlinks.json`ファイルは、ファイルがRelying Party IDと同じ場所にあるため、ネイティブアプリのインストール/更新時に問題なくダウンロードできます。 **Relying Party IDのパスキーを作成できます。** ### 7.2 例2：Relying PartyがサブドメインでCNAMEが設定されている | Relying Party ID | auth.corbado.com | | -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | **エンタイトルメント（iOSのみ）** | webcredentials:auth.corbado.com | | **apple-app-site-associationファイルの場所** | [https://pro-123.passkeys.eu/.well-known/apple-app-site-association](https://pro-123.passkeys.eu/.well-known/apple-app-site-association) | | **assetlinks.jsonファイルの場所** | [https://pro-123.passkeys.eu/.well-known/assetlinks.json](https://pro-123.passkeys.eu/.well-known/assetlinks.json) | | **CNAME** | auth.corbado.com => pro-123.passkeys.eu | この例では、auth.corbado.comの`apple-app-site-association` / `assetlinks.json`ファイルは、CNAMEがRelying Party IDから保存場所を指しているため、ファイルがRelying Party IDと同じ場所にあり、ネイティブアプリのインストール/更新時に問題なくダウンロードできます。 **Relying Party IDのパスキーを作成できます。** ### 7.3 例3：Relying PartyがルートドメインでCNAMEが設定されている | Relying Party ID | corbado.com | | -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | **エンタイトルメント（iOSのみ）** | webcredentials:corbado.com; webcredentials:auth.corbado.com | | **apple-app-site-associationファイルの場所** | [https://pro-123.passkeys.eu/.well-known/apple-app-site-association](https://pro-123.passkeys.eu/.well-known/apple-app-site-association) | | **assetlinks.jsonファイルの場所** | [https://pro-123.passkeys.eu/.well-known/assetlinks.json](https://pro-123.passkeys.eu/.well-known/assetlinks.json) | | **CNAME** | auth.corbado.com => pro-123.passkeys.eu | この例では、auth.corbado.comの`apple-app-site-association` / `assetlinks.json`ファイルは、CNAMEにより`auth.corbado.com`が期待する場所にあるため、ネイティブアプリのインストール/更新時に問題なくダウンロードできます。 ただし、corbado.comの`apple-site-association-file` / `assetlinks.json`は、期待される`https://corbado.com/.well-known/apple-app-site-association` / `https://corbado.com/.well-known/assetlinks.json`にファイルがなく、そこを指すCNAMEもないため、ネイティブアプリのインストール/更新時にダウンロードできません。 **Relying Party IDのパスキーは作成できません。** ### 7.4 例4：Relying Partyがサブドメインでワイルドカードエンタイトルメントが設定されている | Relying Party ID | auth.corbado.com | | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | **エンタイトルメント（iOSのみ）** | webcredentials:\*.corbado.com | | **apple-app-site-associationファイルの場所** | [https://corbado.com/.well-known/apple-app-site-association](https://corbado.com/.well-known/apple-app-site-association) | | **assetlinks.jsonファイルの場所** | [https://corbado.com/.well-known/assetlinks.json](https://corbado.com/.well-known/assetlinks.json) | | **CNAME** | 該当なし | この例では、ファイルが期待される場所にあり、webcredentialsエンタイトルメント（`*.corbado.com`）がRelying Party ID（`auth.corbado.com`）と一致するため、ネイティブアプリのインストール/更新時にcorbado.comの`apple-app-site-association`ファイルを問題なくダウンロードできます。Androidは（ワイルドカード）エンタイトルメントのようなものを使用しないため、この例はAndroidでは機能しないことに注意してください。一般に、このようにRelying Party IDを定義することはお勧めしません。 **Relying Party IDのパスキーを作成できます。** ## 8. よくあるRelying Party IDのミスとそれを回避する方法 ### 8.1 Relying Party IDをサブドメインからルートドメインに変更する **ミス：** 開発を開始し、Relying Party IDとしてサブドメイン（例：`login.acme.com`）を定義しました。最初のユーザーがこのRelying Party IDのパスキーを作成しました。その後、別のサブドメイン（例：`app.acme.com`）の認証にもこれらのパスキーが必要なことに気づきました。ユーザーのオリジンと新しいサブドメインのRelying Party IDが一致しないため、ユーザーはパスキーでサインインできません。WebAuthn設定でRelying Party IDを`acme.com`に変更すると、新しいオリジンと既存のパスキーに保存されているRelying Party IDが一致しないため、既存のすべてのパスキーが無効になります。 **解決策：** Relying Party IDを定義する際は、ほぼ確定事項となるため、最初に二重チェックを行ってください。将来的に他のサブドメインで認証にパスキーが必要になる可能性があるなど、よくわからず将来に備えたい場合は、[パブリックサフィックスリスト](https://publicsuffix.org/learn/)にない限り、Relying Party IDとしてルートドメイン（例：acme.com）を使用することをお勧めします。 ### 8.2 ネイティブアプリとウェブアプリで異なるRelying Party ID **ミス：** ネイティブアプリとウェブアプリを同時に開発しています。スピードアップのために、ネイティブとウェブアプリで異なるRelying Party IDを持つ2つの異なるWebAuthnサーバーを使用します。ユーザーが最初のパスキーを作成すると、それぞれのRelying Party IDがパスキーに保存されます。ウェブアプリで作成したパスキーを使ってネイティブアプリでサインインしようとするなど、同じパスキーでのクロスデバイス/クロスプラットフォームのログインはできなくなります。2つのWebAuthnサーバーをマージすると、古いWebAuthnサーバー（古いRelying Party ID）で登録されたパスキーは放棄され、ユーザーはこれらのパスキーでログインできなくなります。 **解決策：** 複数のアプリケーション（ウェブアプリとネイティブアプリなど）がある場合、WebAuthnサーバーは常に1つだけにし、すべてのアプリに対して1つのRelying Party IDのみを定義してください。これらのアプリ間のリンクは、上記の手順で行うことができます。 ### 8.3 無効で到達不可能なアソシエーションファイル **ミス：** アプリケーションの開発を開始し、アソシエーションファイルを設定してサーバーにデプロイしました。何らかの理由で依然としてエラーメッセージが表示され、根本原因が見つかりません。 **解決策：** エラーメッセージの潜在的な原因は、アソシエーションファイルの形式が正しくないか、到達できないことである可能性があります。アソシエーションファイルをサーバーにデプロイする前に、[iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios)とAndroid用に提供されているツールを使用して、アソシエーションファイルの有効性と到達可能性（AppleやGoogleのクローラーによる適切なアクセスを防ぐ[堅牢なVPN](https://cybernews.com/best-vpn/most-secure-vpns/)やファイアウォールの背後にこれらのファイルがあることがよくあります）をチェックすることを強くお勧めします。 ### 8.4 apple-app-site-associationファイルがApple CDNにまだキャッシュされていない **ミス：** apple-app-site-associationファイルをサーバーにデプロイし、すぐにテストデバイスでパスキーの作成を開始したいと考えています。何らかの理由でパスキーを作成できず、エラーメッセージが表示されます。 **解決策：** これらのエラーメッセージの背後にある理由は、iOSデバイスがRelying Partyを検証するために`apple-app-site-association`ファイルをダウンロードすることです。そのため、iOSデバイスはサーバーに直接リクエストを送信するのではなく、代わりにCDNを使用します。デバイスとCDNはどちらも、正常に取得された後に`apple-app-site-association`ファイルをキャッシュします。このキャッシュ機能により、`apple-app-site-association`ファイルへの新しい変更はアプリに直接反映されません。CDNが`apple-app-site-association`ファイルをキャッシュするまでに最大24時間かかる場合があります。開発中にこの制限を回避するには、Relying Party IDに`?mode=developer`を追加して、キャッシュを完全に無効にすることができます（例：Relying Party IDは`acme.com?mode=developer`になります）。 ### 8.5 AndroidエミュレーターとAPIバージョンの非互換性 **ミス：** Androidアプリの開発を開始し、Androidエミュレーターでテストしたいと考えています。Androidエミュレーターを適切にセットアップし、他のアプリはスムーズに動作しているように見えるのに、何らかの理由でエラーメッセージが表示されます。 **解決策：** パスキーアプリケーションをテストする場合、Androidのバージョン、Playストアのサポート、およびAPIバージョンが大きな役割を果たします。さらに、Googleアカウントにログインしている必要があります。詳細については、トラブルシューティングセクションを参照してください。 ## 9. 推奨事項 ### 9.1 一般的な推奨事項 全体的な推奨事項は、アプリケーションの状況と要件に基づいてRelying Party IDを慎重に選択することです。以下に最も一般的なユースケースをまとめましたが、一般的な推奨事項としては、**ルートドメインをRelying Party IDとして選択することを目指し**、この方法で認証を設定することです。Corbadoを使用する場合、すべての技術的なセットアップでシームレスなパスキー認証を提供するアプローチの一環として、この方法が事前に設定されています。UIコンポーネントとSDKは、Relying Party IDとしてルートドメインを使用するように準備されています。 | ケース | 推奨 | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **A) ルートドメインが1つある場合：**

例：acme.com

すべてのアプリケーションと認証は、このルートドメインまたはそのサブドメインで実行されます | ✔️ Webアプリでもネイティブアプリでも問題が発生しないため、Relying Party IDとしてルートドメインを選択します。 | | **B) 複数のルートドメインがある場合：**

例：kayak.com、kayak.co.uk、kayak.de

異なる国際的なトップレベルドメインからユーザーにサービスを提供しています。米国の場合はKayak.com、英国の場合はkayak.co.uk、あるいは同じユーザーが同じパスキーでログインできるようにする完全に異なるルートドメインがあります。 | ⚠️ ウェブアプリでパスキーを共有するには、指定したオリジンで共通のRP IDを使用できるように、`.well-known/webauthn`経由でRelated Origin Requestsを設定する必要があります（ブラウザのサポート状況は異なるため、互換性を確認してください）。または、共通の認証ルートドメインを選択します。

✔️ ルートのアソシエーションファイルを制御できる限り、ネイティブアプリを任意の数のルートドメインに接続できます。

❌ 後でウェブサイトをホストするために別のルートドメインに移行したい場合、ブランドを変更してドメイン（Relying Party ID）を変更する必要があるため、すでに作成したパスキーは使用できなくなります。 | | **C) まだルートドメインを持っておらず、バックエンドのみ、またはパブリックサブドメインで実行している場合。これが起こり得るケースがいくつかあります：**

1. ルートドメインが管理下にない、無料で利用可能なサブドメインで作業している（ルートドメインは[https://publicsuffix.org/](https://publicsuffix.org/)にリストされています）。たとえばCDN URLなど

2. ネイティブアプリで作業している。 | ❌ パブリックサブドメインでは、ルートドメインのルートレベルにあるアソシエーションファイルを制御できません。そのため、パスキーはネイティブでは機能しません。

⚠️ 一部のサービスでこれを修正する唯一の方法は、CNAMEを定義したり、自分用のカスタムルートドメインを取得したりできる有料プランに変更することです。 | ### 9.2 Corbadoを使用する場合の推奨事項 以下に、パスキーソリューションとしてCorbadoを使用する場合に、適切なRelying Party IDを決定し、アソシエーションファイルをどのように処理/ホストするかを判断するのに役立つ非常に具体的なデシジョンツリーを提供します。 最初の決定事項は、開発環境か本番環境かです。次に決定するレベルは、アプリケーションの状況に基づいています。ネイティブアプリのみか、それともネイティブアプリとウェブアプリがあるかです。 #### A) 開発環境 開発環境では、すぐに開発とテストを開始したいと想定しています。本番稼働させたい場合は、Relying Party IDを後で変更できます。 ##### A1) ネイティブのみ - Relying Party IDを`pro-XXX.frontendapi.cloud.corbado.io`に設定（デフォルト値） - Corbadoがアソシエーションファイルをホストします - DNSの作業は不要です ##### A2) ネイティブアプリとウェブアプリ ウェブアプリとネイティブアプリの両方を同時にテストすることは簡単ではありません **オプション1：** Relying Party ID = `pro-XXX.frontendapi.cloud.corbado.io`（ネイティブアプリが機能します）に設定するか、またはRelying Party ID = `localhost`（ウェブアプリが機能します）に設定します **オプション2：** ネイティブアプリとウェブアプリが同時に機能する唯一の解決策は、ローカルリバースプロキシを使用することです（かなりハッキーな解決策です）： - Relying Party IDを`acme-dev.com`に設定 - `acme-dev.com`から`pro-XXX.frontendapi.cloud.corbado.io`へのCNAMEを設定 - ローカルの`/etc/hosts`にエントリ`localhost acme-dev.com`を追加 - `acme-dev.com` => `localhost:3000`のルールのリバースプロキシ（nginx）を追加（例として） #### B) 本番環境 本番環境では、Relying Party IDとしてサブドメイン（例：`auth.acme.com`）を使用するか、Relying Party IDとしてルートドメイン（例：`acme.com`）を使用するかを決定する必要があります。 ##### B1) Relying Party IDとしてサブドメインを使用 ###### B1.1) ネイティブのみ - Relying Party IDを`auth.acme.com`に設定 - Corbadoがアソシエーションファイルをホストします - `auth.acme.com`から`pro-XXX.frontendapi.cloud.corbado.io`へのCNAMEを設定 ###### B1.2) ネイティブアプリとウェブアプリ - Relying Party IDを`auth.acme.com`に設定 - Corbadoがアソシエーションファイルをホストします - `auth.acme.com`から`pro-XXX.frontendapi.cloud.corbado.io`へのCNAMEを設定（Corbadoのセッション管理を使用する場合、Cookieを機能させるためにも必要です） ##### B2) Relying Party IDとしてルートドメインを使用 ###### B2.1) ネイティブのみ - Relying Party IDを`acme.com`に設定 - ご自身のサーバーの`acme.com/.well-known/`でアソシエーションファイルをホストします - DNSの作業は不要です ###### B2.2) ネイティブアプリとウェブアプリ - Relying Party IDを`acme.com`に設定 - ご自身のサーバーの`acme.com/.well-known/`でアソシエーションファイルをホストします - Corbadoのセッション管理を使用する場合、Cookieを機能させるために`auth.acme.com`から`pro-XXX.frontendapi.cloud.corbado.io`へのCNAMEを設定する必要があります（このCNAMEはRelying Party IDのためには必要なく、セッション管理のためだけに必要です） 以下のデシジョンツリーは、すべての構成パスを要約しています。 ## 10. 結論 Relying Party IDはWebAuthnおよびパスキーベースの認証の基盤であり、強力なフィッシング耐性を提供します。Relying Party IDを適切に構成し、ドメインマッチングの複雑さを理解し、ネイティブアプリの正しいデプロイメントを確実に行うことが重要です。このブログ記事では、それらを正しく設定し、さまざまな間違いに対処する方法を紹介しました。rpIDの構成がしっかりしたら、パスキー作成フローとパスキーログインフローの最適化に注力して、実際の導入を推進してください。ネイティブアプリのパスキーの設定に関する詳細な洞察については、[Flutter](https://www.corbado.com/blog/flutter-passkeys-package)のパスキーについて読むことをお勧めします。 さらにご質問がある場合やサポートが必要な場合は、遠慮なく[お問い合わせ](https://bit.ly/passkeys-community)ください。 ## よくある質問 ### Relying Party IDはパスキー認証でのフィッシングをどのように防ぎますか？ オーセンティケーターは、ブラウザの実際のオリジンとパスキーに保存されているRelying Party IDを比較します。攻撃者が異なるドメインで偽サイトをホストしている場合、偽造されたチャレンジが正当なRP IDを要求していても、オリジンの不一致により認証は自動的に失敗します。このバインディングにより、paypal.comで登録されたパスキーは、paybal.comのような類似ドメインでは使用できなくなります。 ### ユーザーがパスキーを登録した後にWebAuthnのRelying Party IDを変更するとどうなりますか？ 各クレデンシャルに保存されているRP IDが新しい値と一致しなくなるため、RP IDを変更すると既存のすべてのパスキーが無効になります。例外は、新しいRP IDが古いRP IDのサブドメインである場合か、`.well-known/webauthn`を介してRelated Origin Requestsが設定されている場合のみです。この不可逆的な問題を避けるため、最初からルートドメインをRP IDとして選択してください。 ### apple-app-site-associationファイルをデプロイした直後にiOSのパスキーが機能しないのはなぜですか？ iOSはapple-app-site-associationファイルをサーバーから直接取得しません。AppleのCDNを使用しており、新規または更新されたファイルがキャッシュされるまでに最大24時間かかる場合があります。開発中は、Relying Party IDに`?mode=developer`を追加することで、キャッシュを完全にバイパスできます。 ### パスキーのRelying Party IDとしてサブドメインとルートドメインのどちらを使用すべきですか？ ルートドメイン（例：acme.com）の使用が推奨されます。任意のサブドメインで作成されたパスキーは、そのルートのすべてのサブドメインで認証できるためです。サブドメインをRP IDにすると、パスキーの使用がそのサブドメインとその子に制限され、後でクロスサブドメインのフローに支障をきたす可能性があります。acme.comやacme.co.ukのような複数のルートドメインがある場合は、`.well-known/webauthn`でRelated Origin Requestsを設定し、パスキーを再利用できるようにしてください。