WebAuthnのRelying Party ID (rpID) とパスキー：ドメインとネイティブアプリ

TikTok、GitHub、WhatsApp、X（Twitter）、LinkedIn、Amazonなどのテクノロジー大手が導入を進めている、あるいはすでに導入していることから、パスキー認証は急速に標準となりつつあります。テクノロジー業界が、シンプルで安全な認証の重要性を認識していることは明らかです。

Face ID、Touch ID、Windows Helloなどを使用した認証のシームレスなユーザーエクスペリエンスに加え、パスキーはパスワードのような従来の認証方法と比較して比類のないセキュリティを提供します。その際立った特徴の1つが、強力なフィッシング耐性です。

Passkeysチートシート. パスキープログラム向けの実践ガイド、展開パターン、KPI。

チートシートを入手

ライブデモでパスキーを試せます。

Passkeysを試す

フィッシング攻撃とは、被害者を騙して元のサイトを模倣した偽のサイトにクレデンシャルを提供させる攻撃です。例えば、銀行を装ったメールを受信し、ログインを求められたとします。リンクをクリックすると、ウェブサイトが本物のように見えるため、クレデンシャルを入力してしまい、攻撃者はそれを使って元のサイトにログインできるようになります。これはデジタル時代においてますます深刻な問題となっており、Okta（認証プロバイダーです！）やRetoolのような大企業でさえスピアフィッシング攻撃（特定の被害者を狙い撃ちにし、非常に個人的な手口を用いるフィッシングの特殊な形態）の犠牲となっており、堅牢なセキュリティ対策の必要性が強調されています。

対照的に、パスキーを使用している場合、サイトが偽物であれば認証は失敗します。これは、Relying Party IDを介して、パスキーが作成されたドメインにバインドされているためです。

このメカニズムは、パスワードレス認証の基盤となるウェブ標準であるWebAuthnに組み込まれています。WebAuthnは、登録と認証という2つのコアセレモニーに基づいて構築されています。

登録（サインアップ）セレモニーでは、ウェブまたはネイティブアプリを介して、オンラインサービス（Relying Party）用の新しいパスキーが作成されます。このプロセスで、パスキーが作成されたドメイン（Relying Party ID）がパスキー内に保存されます。

これにより、認証（ログイン）セレモニーにおいて、ウェブまたはネイティブアプリが属するオンラインサービス（Relying Party）が、パスキーに保存されているRelying Party IDと一致するかどうかを確認できます。

以下では、このドメインマッチングプロセスがどのように機能するか、そして特にネイティブアプリがどのように保護されるかを詳しく説明します。

Relying Party IDは本質的にパスキー内に保存されるドメインであり、現在のブラウザURL（すべてのリクエストで自動的に送信されるユーザーのオリジン）がそれと一致する場合にのみパスキーが機能することを保証します（後述のネイティブアプリのアプローチを参照）。これはWebAuthn仕様の重要なコンポーネントであり、詳細についてはこちらを参照できます。Relying Party IDには、ルートドメイン（例：corbado.com）またはサブドメイン（auth.corbado.com）を指定できます。ルートドメインがパブリックサフィックスリストに含まれている場合、それをRelying Party IDとして保存することはできません（リストおよびパブリックサフィックス検出用ライブラリはこちらを参照）。オンラインサービスの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列目）がその親ドメインへのアクセスを許可されるかの詳細な概要です。

以下に、解析されたPublicKeyCredentialCreationOptionsを示します。

{
    "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のクレデンシャルを盗もうとする偽のウェブサイトであるPayPalクローンを開発します。この偽のPayPalウェブサイトは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:<SHA256_fingerprint>としてフォーマットされます。iOSでは、WebAuthnのオリジンはRPウェブオリジン（例：https://paypal.com）です。どちらの場合も、ネイティブアプリとサーバー間の信頼性は対応するアソシエーションファイルを介して検証されます（後述を参照）。ネイティブアプリでのオリジン検証がどのように機能するかの詳細については、ネイティブアプリのWebAuthnオリジン検証に関する専用ガイドを参照してください。

最新情報とサポートのためにPasskeys Communityに参加しましょう。

参加する

ネイティブアプリにパスキーを実装する場合、開発者はWebView経由で追加するか、ネイティブに追加するかを選択できます。以下で両方のアプローチの利点と欠点を検証しましょう。

WebView*を使用してパスキーを統合するということは、ネイティブアプリ内にウェブブラウザを埋め込んで認証プロセスを処理することを意味します。このアプローチでは、基本的にはアプリ内にウェブページが表示されるため、ネイティブプラットフォーム用に書き直すことなく、ウェブベースの認証フローを簡単に再利用できます。ただし、いくつかの欠点があります。WebViewはすべてのパスキー機能をサポートしていない可能性があり、安全に実装されていない場合、「中間者（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を使用することをお勧めします。

実際にどれだけの人がパスキーを使っているか確認できます。

利用データを見る

ネイティブ統合には、プラットフォーム固有のAPIとライブラリを使用して、iOSまたはAndroidアプリに直接パスキー機能を組み込むことが含まれます。この方法では、ネイティブアプリとWebView間を移行する必要がないため、よりシームレスなユーザーエクスペリエンスが提供されます。また、パフォーマンスが向上し、より一貫したルックアンドフィールが可能になります。セキュリティの観点から見ると、ネイティブ統合は、特にプラットフォーム固有のセキュリティ機能と組み合わせた場合、特定の種類の攻撃に対する保護を強化できます。ただし、開発者は各プラットフォーム（AndroidとiOS）用に個別のコードを記述して保守する必要があるため、実装の労力が大きくなる可能性があります。さらに、最新のパスキー / WebAuthn仕様を常に最新の状態に保つには、より頻繁にアプリを更新する必要があるかもしれません。

以下では、ネイティブパスキー統合に焦点を当てます。

実際にどれだけの人がパスキーを使っているか確認できます。

利用データを見る

ネイティブアプリ（iOSやAndroidアプリなど）は、ウェブアプリに比べて課題があります。ウェブアプリとは異なり、Relying Party IDと照合するためのブラウザURLがありません。それにもかかわらず、同じレベルのセキュリティを確保するために、ドメインはアソシエーションファイルを介してネイティブアプリに接続され、ドメインとネイティブアプリ間の信頼関係が確立されます。

これは、パスキーがウェブアプリで作成され、同じRelying Party IDのネイティブアプリで使用される場合（またはその逆）に特に重要です。

iOSはapple-app-site-associationファイルを使用します。このファイルには様々なエンタイトルメントが含まれていますが、WebAuthnとパスキーにはwebcredentialsエンタイトルメントが重要です。

{
    "webcredentials": {
        "apps": ["9RF9KY88B2.com.corbado.passkeys"]
    }
}

webcredentials.appsに、Application Identifier Prefix（例：9RF9KY77B2）とBundle Identifier（例：com.corbado.passkeys）を保存する必要があります。

iOSのネイティブアプリが機能するためには、apple-app-site-associationファイルはRelying Party IDの/.well-knownディレクトリ（https://<Relying Party ID>/.well-known/apple-app-site-association）に保存されている必要があります。

ライブの例はこちらをご覧ください。

Androidはassetlinks.jsonファイルを使用しますが、iOSのファイルと同様に、WebAuthnとパスキーのための特別な設定が必要です。

[
    {
        "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用です。

ライブの例はこちらをご覧ください。

Androidアプリが機能するためには、assetlinks.jsonファイルはRelying Party IDの/.well-knownディレクトリhttps://<Relying Party ID>/.well-known/assetlinks.jsonに保存されている必要があります（iOSとほぼ同じです）。

ネイティブのAndroid / iOSアプリとウェブアプリ間でパスキーを共有する実装のサンプルを見るには、こちらのブログ記事をチェックしてください。

Passkeys Debuggerでパスキーフローを試せます。

無料で試す

iOSアプリとウェブアプリ間の信頼関係を確立するプロセスは以下のようになります。

1. iOSアプリ開発者は、ネイティブアプリに関連付けたいドメインのリストを指定する必要があります。これらのドメインはiOSアプリのエンタイトルメントにハードコードされます。例：

• webcredentials:auth.Corbado.com
• webcredentials:*.Corbado.com

2. iOSアプリがインストールまたは更新されるたびに、iOSはアプリのエンタイトルメントリストの各エントリについて、apple-app-site-associationファイルをダウンロードします。

3. iOSアプリ内でクレデンシャル（パスキーなど）が作成されると、iOSアプリは以下の2点を確認して、Relying PartyサーバーのドメインがiOSアプリに関連付けられているかを検証します。

• このRelying Partyサーバーのドメインのapple-app-site-associationファイルがデバイス上に存在するか？
• iOSアプリがそのapple-app-site-associationファイルにリストされているか？

この両方の質問に「はい」と答えられる場合にのみ、iOSアプリ内でパスキーを作成できます。

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.

See how VicRoads scaled passkeys to 5M+ users — alongside their existing IDP.

Read the case study

Androidアプリとウェブアプリ間の信頼関係を確立するプロセスは以下のようになります。

1. Androidアプリ開発者は、Androidアプリに関連付けたいドメインのリストを指定する必要があります。これらのドメインはassetlinks.jsonファイル内にnamespace webのターゲットとして保存されます。Androidアプリとウェブアプリがクレデンシャルを共有することを宣言するには、delegate_permission/common.get_login_credsを指定する必要があります。詳細はこちらをご覧ください。

2. Androidアプリ内でパスキーが作成された場合、Androidアプリはassetlinks.jsonを確認して、Relying Party IDがAndroidアプリに関連付けられているかを検証します。

• このRelying Party IDのassetlinks.jsonファイルがhttps://<Relying Party ID>./well-known/assetlinks.jsonに存在するか。
• Androidアプリがターゲットとして正しく定義されているか。

3. この両方の質問に「はい」と答えられる場合にのみ、Androidアプリ内でパスキーを作成できます。

以下の図は、これらの信頼確立プロセスを並べて比較したものです。

最新ニュースを受け取るためにPasskeys Substackを購読しましょう。

購読する

以下に、ネイティブアプリでパスキー認証を適切に設定するために必要なさまざまな設定の詳細な概要を示します。

Flutterの場合、AndroidまたはiOSのそれぞれのルールが適用されます。唯一のFlutter固有の設定はアソシエーションファイルのレジストリであり、以下を追加する必要があります。

• Androidの場合：AndroidManifest.xmlにflutter_deeplinking_enabledを追加
• iOSの場合：Info.plistにFlutterDeepLinkingEnabled trueを追加

私たち自身が経験したように、Relying Party ID、様々なレベルの（サブ）ドメイン、およびCNAMEを扱うことは非常に困難な作業になる可能性があるため、4つの異なる例を提示し、それらがなぜ、どのように機能するのかを説明します。

なお、CNAMEの表の行はパスキー認証には必須ではなく、単に追加したかった私たちの調査の結果です。

この例では、Corbado.comのapple-app-site-association / assetlinks.jsonファイルは、ファイルがRelying Party IDと同じ場所にあるため、ネイティブアプリのインストール/更新時に問題なくダウンロードできます。

Relying Party IDのパスキーを作成できます。

この例では、auth.corbado.comのapple-app-site-association / assetlinks.jsonファイルは、CNAMEがRelying Party IDから保存場所を指しているため、ファイルがRelying Party IDと同じ場所にあり、ネイティブアプリのインストール/更新時に問題なくダウンロードできます。

Relying Party IDのパスキーを作成できます。

この例では、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のパスキーは作成できません。

この例では、ファイルが期待される場所にあり、webcredentialsエンタイトルメント（*.corbado.com）がRelying Party ID（auth.corbado.com）と一致するため、ネイティブアプリのインストール/更新時にcorbado.comのapple-app-site-associationファイルを問題なくダウンロードできます。Androidは（ワイルドカード）エンタイトルメントのようなものを使用しないため、この例はAndroidでは機能しないことに注意してください。一般に、このようにRelying Party IDを定義することはお勧めしません。

Relying Party IDのパスキーを作成できます。

最新情報とサポートのためにPasskeys Communityに参加しましょう。

参加する

ミス：

開発を開始し、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を定義する際は、ほぼ確定事項となるため、最初に二重チェックを行ってください。将来的に他のサブドメインで認証にパスキーが必要になる可能性があるなど、よくわからず将来に備えたい場合は、パブリックサフィックスリストにない限り、Relying Party IDとしてルートドメイン（例：acme.com）を使用することをお勧めします。

ミス：

ネイティブアプリとウェブアプリを同時に開発しています。スピードアップのために、ネイティブとウェブアプリで異なるRelying Party IDを持つ2つの異なるWebAuthnサーバーを使用します。ユーザーが最初のパスキーを作成すると、それぞれのRelying Party IDがパスキーに保存されます。ウェブアプリで作成したパスキーを使ってネイティブアプリでサインインしようとするなど、同じパスキーでのクロスデバイス/クロスプラットフォームのログインはできなくなります。2つのWebAuthnサーバーをマージすると、古いWebAuthnサーバー（古いRelying Party ID）で登録されたパスキーは放棄され、ユーザーはこれらのパスキーでログインできなくなります。

解決策：

複数のアプリケーション（ウェブアプリとネイティブアプリなど）がある場合、WebAuthnサーバーは常に1つだけにし、すべてのアプリに対して1つのRelying Party IDのみを定義してください。これらのアプリ間のリンクは、上記の手順で行うことができます。

ミス：

アプリケーションの開発を開始し、アソシエーションファイルを設定してサーバーにデプロイしました。何らかの理由で依然としてエラーメッセージが表示され、根本原因が見つかりません。

解決策：

エラーメッセージの潜在的な原因は、アソシエーションファイルの形式が正しくないか、到達できないことである可能性があります。アソシエーションファイルをサーバーにデプロイする前に、iOSとAndroid用に提供されているツールを使用して、アソシエーションファイルの有効性と到達可能性（AppleやGoogleのクローラーによる適切なアクセスを防ぐ堅牢なVPNやファイアウォールの背後にこれらのファイルがあることがよくあります）をチェックすることを強くお勧めします。

ミス：

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になります）。

ミス：

Androidアプリの開発を開始し、Androidエミュレーターでテストしたいと考えています。Androidエミュレーターを適切にセットアップし、他のアプリはスムーズに動作しているように見えるのに、何らかの理由でエラーメッセージが表示されます。

解決策：

パスキーアプリケーションをテストする場合、Androidのバージョン、Playストアのサポート、およびAPIバージョンが大きな役割を果たします。さらに、Googleアカウントにログインしている必要があります。詳細については、トラブルシューティングセクションを参照してください。

全体的な推奨事項は、アプリケーションの状況と要件に基づいてRelying Party IDを慎重に選択することです。以下に最も一般的なユースケースをまとめましたが、一般的な推奨事項としては、ルートドメインをRelying Party IDとして選択することを目指し、この方法で認証を設定することです。Corbadoを使用する場合、すべての技術的なセットアップでシームレスなパスキー認証を提供するアプローチの一環として、この方法が事前に設定されています。UIコンポーネントとSDKは、Relying Party IDとしてルートドメインを使用するように準備されています。

以下に、パスキーソリューションとしてCorbadoを使用する場合に、適切なRelying Party IDを決定し、アソシエーションファイルをどのように処理/ホストするかを判断するのに役立つ非常に具体的なデシジョンツリーを提供します。

最初の決定事項は、開発環境か本番環境かです。次に決定するレベルは、アプリケーションの状況に基づいています。ネイティブアプリのみか、それともネイティブアプリとウェブアプリがあるかです。

開発環境では、すぐに開発とテストを開始したいと想定しています。本番稼働させたい場合は、Relying Party IDを後で変更できます。

• Relying Party IDをpro-XXX.frontendapi.cloud.corbado.ioに設定（デフォルト値）
• Corbadoがアソシエーションファイルをホストします
• DNSの作業は不要です

ウェブアプリとネイティブアプリの両方を同時にテストすることは簡単ではありません

オプション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）を追加（例として）

本番環境では、Relying Party IDとしてサブドメイン（例：auth.acme.com）を使用するか、Relying Party IDとしてルートドメイン（例：acme.com）を使用するかを決定する必要があります。

• Relying Party IDをauth.acme.comに設定
• Corbadoがアソシエーションファイルをホストします
• auth.acme.comからpro-XXX.frontendapi.cloud.corbado.ioへのCNAMEを設定

• Relying Party IDをauth.acme.comに設定
• Corbadoがアソシエーションファイルをホストします
• auth.acme.comからpro-XXX.frontendapi.cloud.corbado.ioへのCNAMEを設定（Corbadoのセッション管理を使用する場合、Cookieを機能させるためにも必要です）

• Relying Party IDをacme.comに設定
• ご自身のサーバーのacme.com/.well-known/<association file>でアソシエーションファイルをホストします
• DNSの作業は不要です

• Relying Party IDをacme.comに設定
• ご自身のサーバーのacme.com/.well-known/<association file>でアソシエーションファイルをホストします
• Corbadoのセッション管理を使用する場合、Cookieを機能させるためにauth.acme.comからpro-XXX.frontendapi.cloud.corbado.ioへのCNAMEを設定する必要があります（このCNAMEはRelying Party IDのためには必要なく、セッション管理のためだけに必要です）

以下のデシジョンツリーは、すべての構成パスを要約しています。

Relying Party IDはWebAuthnおよびパスキーベースの認証の基盤であり、強力なフィッシング耐性を提供します。Relying Party IDを適切に構成し、ドメインマッチングの複雑さを理解し、ネイティブアプリの正しいデプロイメントを確実に行うことが重要です。このブログ記事では、それらを正しく設定し、さまざまな間違いに対処する方法を紹介しました。rpIDの構成がしっかりしたら、パスキー作成フローとパスキーログインフローの最適化に注力して、実際の導入を推進してください。ネイティブアプリのパスキーの設定に関する詳細な洞察については、Flutterのパスキーについて読むことをお勧めします。

さらにご質問がある場合やサポートが必要な場合は、遠慮なくお問い合わせください。

Corbadoについて

Corbadoは、大規模なconsumer認証を運用するCIAMチームのためのPasskey Intelligence Platformです。IDPのログや一般的なanalyticsツールでは見えないものを可視化します。どのデバイス、OSバージョン、ブラウザ、credential managerがpasskeyに対応しているか、なぜ登録がログインにつながらないのか、WebAuthnフローのどこで失敗するか、OSやブラウザのアップデートがいつ静かにログインを壊すか — Okta、Auth0、Ping、Cognito、あるいは自社IDPを置き換えることなく、すべてを把握できます。2つのプロダクト：Corbado Observeは passkeyとその他あらゆるログイン方式のobservabilityを提供します。Corbado Connectは analytics内蔵のmanaged passkeyを追加します（既存のIDPと併用）。VicRoadsはCorbadoで500万人超のユーザーにpasskeyを提供しています（passkey有効化率+80%）。 Passkeyエキスパートに相談する →

オーセンティケーターは、ブラウザの実際のオリジンとパスキーに保存されているRelying Party IDを比較します。攻撃者が異なるドメインで偽サイトをホストしている場合、偽造されたチャレンジが正当なRP IDを要求していても、オリジンの不一致により認証は自動的に失敗します。このバインディングにより、paypal.comで登録されたパスキーは、paybal.comのような類似ドメインでは使用できなくなります。

各クレデンシャルに保存されているRP IDが新しい値と一致しなくなるため、RP IDを変更すると既存のすべてのパスキーが無効になります。例外は、新しいRP IDが古いRP IDのサブドメインである場合か、.well-known/webauthnを介してRelated Origin Requestsが設定されている場合のみです。この不可逆的な問題を避けるため、最初からルートドメインをRP IDとして選択してください。

iOSはapple-app-site-associationファイルをサーバーから直接取得しません。AppleのCDNを使用しており、新規または更新されたファイルがキャッシュされるまでに最大24時間かかる場合があります。開発中は、Relying Party IDに?mode=developerを追加することで、キャッシュを完全にバイパスできます。

ルートドメイン（例：acme.com）の使用が推奨されます。任意のサブドメインで作成されたパスキーは、そのルートのすべてのサブドメインで認証できるためです。サブドメインをRP IDにすると、パスキーの使用がそのサブドメインとその子に制限され、後でクロスサブドメインのフローに支障をきたす可能性があります。acme.comやacme.co.ukのような複数のルートドメインがある場合は、.well-known/webauthnでRelated Origin Requestsを設定し、パスキーを再利用できるようにしてください。