WebAuthnレジデントキー：パスキーとしての発見可能な認証情報

パスキーと、その基盤となるWebAuthnプロトコルは、認証の世界に革命をもたらしています。しかし、WebAuthnサーバーを正しく設定するのは、なかなか一筋縄ではいかない作業です。設定を誤ると、脆弱性を生み出すだけでなく、後で変更が必要になった場合に既存のパスキーを壊してしまう可能性もあります。この記事では、複雑なことの多いWebAuthnの仕様をより深く理解し、あなたのユースケースに最適な設定は何かについてアドバイスします。

WebAuthnは、主に3つのエンティティで動作します。

• リライングパーティ (RP): ユーザーを認証したいあなたのウェブサービスです。クライアントにチャレンジを送信し、レスポンスを検証し、パスキーの公開鍵を管理します。
• 認証器: 認証情報の所有を証明できるデバイスです。スマートフォン、ラップトップ、またはセキュリティキー（例：YubiKey）などが含まれます。認証器には、プラットフォーム固有のもの（Windows HelloやAppleのTouch ID / Face IDなど）と、クロスプラットフォームのもの（セキュリティキー、例：YubiKey）があります。
• クライアント: 通常はウェブブラウザやネイティブアプリで、RPと認証器の間の仲介役として機能します。通信を円滑にし、データが正しく安全に流れるようにします。

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

以下に、認証プロセス（ログインまたはサインアップ）における大まかなデータフローを説明します。

1. クライアントによる開始: プロセスはクライアント側で始まります。通常はユーザーがログインまたはサインアップを試みるときです。例えば、「WebAuthnでログイン」ボタンをクリックすると、クライアントはRPにチャレンジを要求するリクエストを送信します。
2. RPからのリクエスト: RPはクライアントにチャレンジを返します。このチャレンジはランダムに生成された値で、その後のレスポンスの真正性を保証します。
3. クライアントから認証器へ: サインアップ時、クライアントは認証器に対応する公開鍵と秘密鍵のペアを作成して新しいパスキーを生成するよう要求します。ログイン時、クライアントは認証器にチャレンジへの署名を要求します。これは、RPに保存されている登録済みの公開鍵に対応する、認証器上の秘密鍵を使用して行われます。
4. 認証器からのレスポンス: サインアップ時、認証器は公開鍵をクライアントに返します。ログイン時、認証器はチャレンジに署名し、この署名済みアサーションをクライアントに返します。
5. クライアントからRPへ: クライアントはこの新しい公開鍵/署名済みアサーションをRPに転送します。
6. RPによる検証: RPは公開鍵を保存する/保存済みの公開鍵を使用して署名済みアサーションを検証します。有効であれば、認証は成功です。

Ben Gould

Head of Engineering

I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.

10,000+ devs trust Corbado & make the Internet safer with passkeys. Got questions? We’ve written 150+ blog posts on passkeys.

Join Passkeys Community

上記の大まかなプロセスフローは、WebAuthnのサインアップとログインのプロセスを説明したものです。パスキーはWebAuthnを基盤として構築されています。もともとパスキーという用語は、WebAuthnよりも記憶に残りやすく、技術的でない言葉として同じものを指すために使われていました。さらに、パスキーは標準のWebAuthnに比べて、クラウドアカウントやパスワードマネージャーを介してパスキーを同期する機能など、より多くの機能を提供します。

以降のセクションをよりよく理解するために、共通認識を持つためにWebAuthnプロトコルの重要な用語をいくつか定義します。

• 認証情報ID（Credential ID）: Credential IDは、認証器によって生成された特定の公開鍵認証情報に割り当てられる一意の識別子です。これにより、リライングパーティ（RP）は認証プロセスで正しいPublicKeyCredentialを識別し、選択することができます。
• PublicKeyCredential: これは、ブラウザやネイティブアプリのWebAuthn APIから返される主要なデータ構造です。サインアップ時のアテステーションデータと、ログイン時のアサーションデータの両方を含みます。本質的に、RPがプロセスを検証するために必要なデータが含まれています。
• アテステーション: WebAuthnの文脈におけるアテステーションは、認証器の出自とその完全性を証明する役割を果たします。サインアップ時、これは認証器が「ユーザーの認証情報を安全に登録しました。それを検証するために使用できるステートメントがこちらです」と伝える方法です。リライングパーティは、署名が許可された特定の認証器（例：YubiKey）からのものであることを確認できます。すべてのパスキー認証器がこのようなアテステーションを返すわけではなく、中には有用なデータを返さないものもあります（パスキー認証器のリストはこちらを参照）。より多くの認証器（主にセキュリティキー、例：YubiKey）を識別するAAGUID（Authenticator Attestation GUID）については、FIDO Alliance Metadata Serviceで確認できます。
• アサーション: サインアッププロセスの後、ユーザーがログインしようとすると、認証器はアサーションを生成します。アサーションは基本的に、PublicKeyCredentialと署名されたチャレンジを合わせたものです。このアサーションは、ユーザーが実際の秘密鍵を明かすことなく、登録された公開鍵に紐づく秘密鍵を所有していることを証明します。これは、認証器が「これは本物のユーザーであり、私が保証します」と伝える方法です。

Subscribe to our Passkeys Substack for the latest news.

Subscribe

レジデントキー（RK）と非レジデントキー（NRK）は、WebAuthnプロトコルで使用される2種類の暗号鍵であり、主にその保存場所と取得メカニズムが異なります。

定義:

レジデントキーは、認証器自体に直接保存されます。これには、セキュリティキー（例：YubiKey）、プラットフォームのセキュアエンクレーブ（例：iPhoneのセキュアエンクレーブ）、またはラップトップのトラステッドプラットフォームモジュール（TPM）などが含まれます。条件付きUI（パスキーの自動入力）はレジデントキーでのみ機能し、現在WebAuthnワーキンググループは、パスキーと見なされるためにはレジデントキーであることを要求しています。

以下のスクリーンショットでは、YubiKeyに保存されているすべてのレジデントキー（認証情報ID、rpID、ユーザー名、表示名）のリストが表示されています。非レジデントキーは認証器に保存されていないため、リストには含まれていません。

ログインフロー:

出典: William Brown

ログインプロセス中、リライングパーティは認証情報を指定せずにリクエストをクライアント（ブラウザ）に送信し、クライアントは認証器（図ではセキュリティキー）に問い合わせを開始します。認証器は対応するリライングパーティのすべてのレジデントキーを発見し、クライアント（ブラウザ）が目的のレジデントキーを選択します。このレジデントキーがチャレンジへの署名に使用されます。署名は認証器からクライアント経由でリライングパーティに送信されます。

利点:

1. 合理化されたユーザーエクスペリエンス: レジデントキーの最大の利点の1つは、認証器がユーザーハンドル（例：メールアドレス、電話番号、ユーザー名）を保存するため、ログイン時にユーザーハンドル（例：メールアドレス、電話番号、ユーザー名）を事前入力できることです。ユーザーはユーザーハンドル（例：メールアドレス、電話番号、ユーザー名）を覚えたり入力したりする必要がなくなり、特に生体認証機能を備えたデバイスでのログインプロセスが合理化されます。これは条件付きUIによって自動的に行われることもあります。
2. デバイス固有の認証: レジデントキーは、認証を特定のデバイスに結びつけることで、追加のセキュリティ層を提供できます。これは、ユーザーが信頼できるデバイスからログインしていることを確認したいサービスにとって特に有用です。
3. 条件付きUI（パスキーの自動入力）: 条件付きUIは、最もシームレスなログイン体験を提供するレジデントキーでのみ機能します（詳細は下記参照）。

欠点:

1. ストレージの制限: 一部の認証器はストレージ容量に限りがあります。特にセキュリティキー（例：YubiKey）では、保存できるレジデントキーの数に制限があることが多く（ほとんどの場合、8から約100個のレジデントキーが上限）、この上限に達すると、新しいキーのためのスペースを確保するために古いキーを削除する必要があるか、ユーザーが別の認証器を使用する必要があるかもしれません。
2. 認証器の紛失: セキュリティキー（例：YubiKey）やスマートフォンなどの認証器を紛失または破損した場合、そのデバイス上のすべてのレジデントキーが失われます。これにより、ユーザーはアカウントを再登録または回復するまで、複数のサービスからロックアウトされる可能性があります。クラウドアカウント（例：iCloudキーチェーン、Googleパスワードマネージャー）や最新のパスワードマネージャー（例：1PasswordやDashlane）を介してキーを同期することで、この損失を防ぐことができます。
3. セキュリティ上の懸念: レジデントキーを持つ認証器が盗まれた場合、攻撃者がキーを抽出しようとする可能性があります。最新の認証器には抽出を防ぐための堅牢なセキュリティメカニズムがありますが（例：ユーザーが強力なPIN、パスコード、またはジェスチャーでデバイスを保護する）、リスクは最小限ながらも存在します。

ユースケース: 個人のスマートフォンやラップトップなど、ユーザーが頻繁に認証するデバイスに最適です。

Want to find out how many people use passkeys?

View Adoption Data

定義:

対照的に、非レジデントキーは認証器に保存されません。代わりに、サインアップ時に、認証器は新しいキーペアを（内部で保護されたマスターキーに基づいて）生成し、この新しいキーペアの公開鍵を、シードを含む認証情報IDと一緒にサーバー（リライングパーティ）に送信します。その後、サーバーはこの公開鍵をユーザーのアカウントに関連付けます。その後の認証では、認証器は認証情報IDを受け取り、シードを抽出してマスターキーと組み合わせることで、秘密鍵を再導出します。このキーは認証器の保護されたメモリ内で一時的にのみ利用可能であるため、暗号学の用語ではエフェメラルキー（ephemeral key）と呼ばれることもあります。

ログインフロー:

出典: William Brown

ログインプロセス中、リライングパーティはまずどのユーザーが認証を要求しているかを識別し（例：ユーザーハンドル、メールアドレス、電話番号、ユーザー名などを尋ねる）、その要求ユーザーについて把握している認証情報IDをクライアント（ブラウザ）に送信します。クライアントはそれらを認証器（ここではセキュリティキー）に転送します。認証器は、認証情報IDを認証器のマスターキーと一緒に使用して一時的な秘密鍵を導出し、生成された鍵でチャレンジに署名してクライアント（ここではブラウザ）に返し、クライアントはそれをリライングパーティに転送します。非レジデントキーは元々、パスキーが導入される前の第二要素として使用されていたため、最初にユーザーを識別することは通常のログインプロセスの一部でした。

利点:

1. スケーラビリティ: 非レジデントキーは認証器上に存在しないため、ユーザーはさまざまなサービスに関連付けられたほぼ無制限の数の非レジデントキーを持つことができます。これは、多数のプラットフォームにアカウントを持つユーザーにとって特に有益です。
2. ローミング機能: 非レジデントキーは、セキュリティキー（例：YubiKey）などのローミング認証器に最適です。ユーザーは同じセキュリティキー（例：YubiKey）を使用して複数のデバイスやプラットフォームで認証でき、一貫した体験を提供します。
3. 認証器のストレージへの依存度の低減: 適切なWebAuthnサーバー設定であれば、認証器のストレージ制限について心配する必要はありません。これは、セキュリティキー（例：YubiKey）などの低ストレージ認証器にとって特に有利です。

欠点:

1. UXの低下（ユーザーハンドルが必要）: 非レジデントキーの最大の欠点は、ユーザーがユーザーハンドル（例：メールアドレス、電話番号、ユーザー名）を提供する必要があることであり、これにより条件付きUIによるユーザー名の事前入力が不可能になります。このユーザーハンドルは、ephermal key-wrapped keyの計算に必要な認証情報IDに結び付けられる必要があります。
2. 管理ミスの可能性: RPは、ユーザーアカウントと公開鍵の間の関連付けを管理し、保護する必要があります。不適切な管理や脆弱性は、セキュリティ問題につながる可能性があります。

ユースケース: 複数のサービスやプラットフォームで使用されるセキュリティキー（例：YubiKey）などのローミング認証器に最適です。

あなたがセキュリティキー（例：YubiKey）を持っていて、それを2つのオンラインサービス（サービスAとサービスB）に登録すると想像してみてください。サービスAにはレジデントキーを使用します。サービスBには非レジデントキーを使用します。サービスAに認証するときは、単にセキュリティキー（例：YubiKey）をタップするだけでログインできます。ユーザー名を入力する必要はありません。サービスBの場合は、まずブラウザ/ネイティブアプリでユーザー名を入力します。すると、サービスは関連する認証情報IDをあなたのセキュリティキー（例：YubiKey）に送信し、キーは認証のためにエフェメラルな秘密鍵を再生成します。

本質的に、レジデントキーと非レジデントキーはどちらも暗号認証を活用してセキュリティを強化しますが、そのユーザーエクスペリエンスとストレージメカニズムは異なり、さまざまなユースケースに対応しています。

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

条件付きUIは、パスキー/WebAuthnにおける画期的な機能です。ユーザーはパスワードを覚える必要がないだけでなく、リライングパーティにサインアップしたときのユーザーハンドル（例：メールアドレス、電話番号、ユーザー名）を覚える必要もなくなるため、ユーザーの負担をさらに軽減します。特に、リライングパーティのサービスがたまにしか利用されない場合に、これは大きな進歩です。

これが機能する理由は、ログインページが開かれるとすぐに、リライングパーティサーバーがバックグラウンドでクライアントにチャレンジを送信するためです（この呼び出しでは認証情報IDを送信する必要はないことを思い出してください）。クライアントはこのチャレンジを受け取り、この認証器上でどのパスキーがリライングパーティIDに一致するかを確認し、自動入力メニューを介して選択肢を提示します。そこでユーザーは適切なパスキーを選択できます。

さらに、自動入力メニューからパスキーが選択されるとすぐにログインプロセスが開始されるため、ユーザーがログインボタンを余分にクリックする手間も省けます。

CTAPはFIDO2標準の基盤となるプロトコルで、クライアント（ブラウザなど）と認証器（セキュリティキー、例：YubiKey、またはスマートフォンなど）の間の通信ギャップを埋めます。CTAPをよりよく理解するために、まずレジデントキーと非レジデントキーへの影響を分析する前に、異なるプロトコルバージョンを簡単に見てみましょう。

初期のバージョンは、しばしばUniversal 2nd Factor (U2F)と呼ばれ、主に第二要素認証のために設計されました。U2Fでは、サーバーがチャレンジを提供し、認証器が秘密鍵の所持を証明するレスポンスを提供します。しかし、U2Fはレジデントキーをサポートしていないため、ユーザーのためにどのキーを使用するかを識別するために常にサーバー側のルックアップが必要でした。これは第二要素を要求するプロセスの一部だったからです。

U2Fの後継であるCTAP2は、レジデントキーのサポートを導入し、パスワードレスおよびユーザー名レスの認証を可能にしました。レジデントキーにより、認証器はユーザーのユーザー名と認証情報IDを（リライングパーティIDと共に）保存し、認証時にリライングパーティサーバーがそれを提供する必要がなくなります。これは、よりシームレスなUXへの大きな飛躍です。

しかし、CTAP2には課題もあります。注目すべき問題の1つはレジデントキーの管理です。例えば、CTAP2.0デバイスで特定のレジデントキーを削除するには、しばしばデバイスの完全なリセットが必要となり（つまり、マスターキーもリセットされ、すべての非レジデントキーも機能しなくなります）、これはユーザーフレンドリーではなく、1つのデバイスに複数のレジデントキーが保存されているシナリオでは問題となる可能性があります。これにより、CTAP2.0デバイスでのレジデントキーの使用は重大なコミットメントとなります。特にセキュリティキー（例：YubiKey）でしばしば限られているスペースを、誤って埋めてしまいたくはないでしょう。

CTAP2.1はCTAP2の後続バージョンで、プロトコルに追加機能と改善をもたらします。CTAP 2.1に関するいくつかの重要なポイントは次のとおりです。

• レジデントキー管理の向上: CTAP 2.1では、デバイスから特定のレジデントキーを個別に管理、更新、削除できます。
• エンタープライズアテステーション: この機能により、企業は従業員が使用するキーをより詳細に管理できます。企業が使用されているキーが会社支給のものであることを確認する方法を提供します。
• 複数のユーザー認識: 一部の認証器は複数のユーザーを認識できます。CTAP 2.1は、これらの認証器がどのユーザーが認識されたかを示す方法を提供します。
• 後方互換性: CTAP 2.1はCTAP2との後方互換性を持つように設計されており、古いバージョンをサポートするデバイスやプラットフォームが新しいバージョンでも動作することを保証します。

レジデントキー、非レジデントキー、そして異なるCTAPバージョンを見てきた後、今度はリライングパーティ側、つまりWebAuthnサーバー側をより深く分析します。

WebAuthnの柔軟性（しかし複雑さも）は、主にそのサーバー設定、特にauthenticatorSelectionオブジェクトに起因します。このオブジェクトは、クライアントが適切な認証器を選択する際の指針となります。

{
    "rp": {
        "name": "corbado.com",
        "id": "corbado.com"
    },
    "user": {
        "id": "dGVzdefEyMjE",
        "name": "test-username",
        "displayName": "test-username"
    },
    "challenge": "mhanjsapJjCNaN_Ttasdfk1C0DymR-V_w_0UVOPsdfdfJG2ON_FK5-ODtqp33443tgqHzuuDjv-NUUmMAE4hg",
    "pubKeyCredParams": [
        {
            "type": "public-key",
            "alg": -7
        },
        {
            "type": "public-key",
            "alg": -257
        }
    ],
    "timeout": 60000,
    "excludeCredentials": [],
    "authenticatorSelection": {
        "authenticatorAttachment": "platform",
        "residentKey": "preferred",
        "requireResidentKey": false,
        "userVerification": "preferred"
    },
    "attestation": "none",
    "extensions": {
        "credProps": true
    }
}

このサーバーオプションは、認証器がクライアントデバイスにどのように接続されているかを指定します。認証器がクライアントとどのように通信するかについての洞察を提供します。

設定可能な値

• Platform: 認証器がクライアントのプラットフォームに接続されており、取り外し不可能であることを示します。
• Cross-platform: 認証器がクライアントのプラットフォームに縛られておらず、複数のデバイスで使用できることを示します。

ユースケースと例

• Platform: ラップトップに内蔵された指紋スキャナーや、スマートフォンの顔認証システム（例：Face ID、Touch ID、Windows Hello）など。
• Cross-platform: USBセキュリティキー（例：YubiKey）、Bluetoothデバイス、NFCカードなど。

WebAuthn Level 1仕様では、このサーバーオプションはrequireResidentKeyと呼ばれ、ブール値のtrue（認証器はレジデントキーを作成しなければならない）またはfalse（認証器は非レジデントキーを作成しなければならない）を保持できました。 WebAuthn Level 2では、このサーバーオプションが新しいサーバーオプションresidentKeyに置き換えられました。

設定可能な値

• Required: 認証器はレジデントキーを作成しなければなりません（不可能な場合は操作は失敗します）。
• Preferred: 認証器はレジデントキーの作成を試みるべきです（不可能な場合は非レジデントキーを作成します）。
• Discouraged: 認証器は非レジデントキーを作成しなければなりません（不可能な場合は操作は失敗します）。

ユースケースと例

• Required: ユーザー名なしのログインが望ましいシナリオや、ユーザーが以前に登録したデバイスからのみ認証するようにしたい場合（ユーザーの認証情報を特定のデバイスにバインドすることで追加のセキュリティ層を追加する）に最適です。
• Preferred: ウェブサービスが可能な限り最高のログインUX（レジデントキー経由）を提供したいが、レジデントキーが不可能な場合には非レジデントキーもサポートしたいシナリオに適しています。
• Discouraged: パスキー認証を提供し、ユーザーがストレージ機能を持たない認証器であっても、認証情報を特定のデバイスにバインドすることなく使用できるようにしたいサービス。

ユーザー検証とは、認証器を操作している人物が正当な所有者であることを保証するプロセスを指し、通常はPINの入力、指紋の提供、顔認証の使用などの特定の認証ジェスチャーを要求します。

ユーザープレゼンス（UP）という言葉がユーザー検証と同様に言及されたり使用されたりすることがありますが、実際にはいくつかの違いがあります。ユーザープレゼンスは、誰か（誰でもよい）が物理的に存在し、デバイスを操作していることを確認するだけです。その人物の身元を確認するものではありません。セキュリティキーを単純にタッチするだけで、それ以上の身元確認がなくてもユーザープレゼンスには十分です。パスキー/WebAuthnでは、ユーザーは常に存在している必要があります。

設定可能な値

• Required: 操作にはユーザー検証が必須です。
• Preferred: 操作には可能であればユーザー検証を行うべきですが、なくても続行できます。
• Discouraged: 操作にはユーザー検証を行うべきではありません。

ユースケースと例

• Required: 銀行やヘルスケアなどの高セキュリティアプリケーションに最適で、ユーザーの身元を確認すること（例：指紋やPINを通じて）が重要です。
• Preferred: 追加のセキュリティがボーナスとなるが、厳密には必要ではない一般的なアプリケーションに有用です。
• Discouraged: 低リスクの操作や、ユーザー検証が不便になる可能性のあるシナリオに適しています。

パターン

• Authenticator attachment: platform
• Resident key: required
• User verification: required

例: 企業アプリケーションで、従業員が会社支給のラップトップで内蔵の指紋リーダーを使用してパスワードなしでログインできるようにしたい場合。認証情報はデバイスに保存され、ユーザーは毎回指紋で認証する必要があります。

パターン

• Authenticator attachment: cross-platform
• Resident key: required
• User verification: required

例: ユーザーがオンラインバンキング用にセキュリティキー（例：YubiKey）を登録する場合。ユーザーはこのキーを使用して、ユーザー名を入力することなく、どのデバイスでも認証できます。

多くのハードウェアベースのセキュリティキー（例：YubiKey）には、固有のストレージ制約があります。この制限は、デバイスで利用可能な物理メモリとメーカーの設計上の考慮事項によるものです。

例: YubiKeyは20個のレジデントキーしか保存できない場合があります。この上限に達すると、既存のキーを削除しない限り、追加のレジデントキーを追加することはできません。

解決策:

• レジデントキーの選択的利用: すべてのユーザーにレジデントキーを使用するのではなく、特定の役割やシナリオに対して検討します。例えば、強化されたセキュリティを必要とする管理者ロールや高権限ユーザーにレジデントキーを優先します。
• ユーザー教育: ユーザーにセキュリティキー（例：YubiKey）の制限について知らせます。無制限のレジデントキーを使用できるデバイス、例えばラップトップやスマートフォンへの切り替えを奨励します。

異なる認証器は、レジデントキーのリクエストを異なる方法で処理する可能性があります。明示的に要求されなくてもデフォルトでレジデントキーを作成するものもあれば、明示的な指示を必要とするものもあります。

異なるプラットフォームで異なるWebAuthnサーバーオプションに対する一貫性のない動作は、大きな問題です。例えば、iOSは渡されたWebAuthnサーバーオプションに関係なく常にレジデントキーを作成しますが、Androidではオプトイン（例：residentKey: preferred または residentKey: required）が必要です。

この動作に加えてさらに悪いことに、サーバー側に保存されたデータに基づいて、保存された認証情報がレジデントキーか非レジデントキーかを100%確実に判断することはできません。代わりに、いくつかのチェックに従って絞り込むことはできますが（下記参照）、それでもその認証情報の動作が自分の想定通りであることを期待するしかありません。

その理由は、認証情報プロパティ拡張機能（clientExtensionResults.credProps.rk、trueまたはfalseのいずれか）に認証情報の種類（レジデントキーまたは非レジデントキー）に関する情報を保存するというWebAuthnの提案があるためです。しかし、この情報をRPに提供することは保証されていません。なぜなら、すべてのWebAuthn拡張機能はオプションであり、例えばiOSはそれを送信しないためです（そのため、それがレジデントキーか非レジデントキーかわかりません）。

私たちの調査では、作成された認証情報の詳細を提供する2つのWebAuthnデモページ（https://webauthn.ioとhttps://webauthntest.identitystandards.io/）を使用して、異なるプラットフォームと認証器（Windows 10、Windows 11、Android 7、Android 13、iOS17、macOS Ventura、YubiKey）での動作をテストしようとしました。後者はレガシーのrequireResidentKeyプロパティ（WebAuthn Level 1）で動作し、それをresidentKeyプロパティ（WebAuthn Level 2）と組み合わせることもできます。しかし、結果は信頼できるものではありませんでした（例：iOSに対して非レジデントキーと表示されましたが、明らかに条件付きUIは機能していました）。

私たちが見つけた最も信頼できるチェック方法は次のとおりです。

1. あなたのWebAuthnサーバー設定で属性「residentKey」がどうなっているかを確認します。
   1. 「residentKey: required」で認証情報が正常に作成された場合 -> レジデントキーです。
   2. 「residentKey: preferred」または「residentKey: discouraged」の場合、次のチェックに進みます。
2. 拡張機能credProps.rkがサポートされており、サーバー上の認証情報に保存されていますか？
   1. credProps.rk = trueの場合、認証情報はレジデントキーです。
   2. credProps.rk = falseの場合、認証情報は非レジデントキーです。
   3. credPropsが空の場合、認証情報の種類は不明です。

ご覧のように、これにより絞り込むことはできますが、それでも「不明」という選択肢が残り、キーの種類を100%確実に判断することはできません。

これは、SUSEのWilliam Brown氏が彼の素晴らしい記事で、リライングパーティがレジデントキーを要求するとセキュリティキー（例：YubiKey）が無用になる可能性を概説した調査結果とも一致しています（私たちは彼の表を拡張しました）。

この表では、異なるWebAuthnサーバーのレジデントキーオプションに対して、レジデントキーが作成されたか（true）、非レジデントキーが作成されたか（false）、あるいは他の何かが起こったかを示しています。

解決策:

• 徹底的なテスト: 展開する前に、WebAuthn実装をさまざまな一般的な認証器でテストし、その動作を理解します。
• 明示的なサーバー設定: WebAuthnサーバーを設定する際には、要件を明示的にします。パスキーのみをサポートしたい場合は、residentKeyオプションをrequiredに設定します（注意：これにより、レジデントキー容量が限られている認証器で他の課題が生じる可能性があります、上記参照）。

ユーザーがセキュリティキー（例：YubiKey）のストレージ上限に達した場合、エラーに直面したり、新しい認証情報を登録できなくなったりする可能性があります。これは混乱と不満につながる可能性があります。

解決策:

• 丁寧なエラーハンドリング: ユーザーにセキュリティキー（例：YubiKey）がいっぱいであることを知らせ、問題の解決方法に関するガイダンスを提供する明確なエラーメッセージを実装します。
• ガイド付きワークフロー: ユーザーがレジデントキーを管理する方法に関するステップバイステップのガイドやチュートリアルを提供し、問題を自力で解決できるようにします。

9. 開発者とプロダクトマネージャーのためのベストプラクティス

上記で見てきたように、選択するWebAuthnサーバー設定は、認証プロセスのユーザーエクスペリエンスとセキュリティに大きな影響を与える可能性があります。情報に基づいた意思決定を行うためには、これらの設定のニュアンスを理解することが不可欠です。

レジデントキー vs 非レジデントキー: ユーザーの大多数が主にスマートフォンやラップトップなどの個人用デバイスからサービスにアクセスする場合、レジデントキーが適切な選択です。レジデントキーはデバイス自体に保存され、同じデバイスを頻繁に使用するユーザーにシームレスな認証体験を提供します。しかし、セキュリティキー（例：YubiKey）を使用するユーザーには、非レジデントキーの方が適しているかもしれません。

ユーザー検証（UV）設定: 達成したいセキュリティレベルに応じて、ユーザー検証プロセスの厳格さを決定できます。高いセキュリティを目指す場合は、PIN、指紋、または顔認証を要求する（userVerification: preferred または userVerification: required）ことが推奨されます。

アテステーションと信頼性: アテステーションにより、認証器の出自と完全性を検証できます。すべての認証器を信頼するか、特定のメーカーのもののみを信頼するかを決定します。機密データを扱っており、高品質で信頼できる認証器のみが使用されるようにしたい場合には、これが重要になることがあります。

フォールバックメカニズム: 常にフォールバックメカニズムを用意しておきます。ユーザーが認証器を紛失したり、故障したりした場合、アカウントにアクセスするための代替手段が必要です。これには、バックアップコード、SMS認証、メールマジックリンク、またはその他の多要素認証方法が含まれます。

継続的な学習: パスキーとWebAuthnの状況は絶えず進化しています。最新の開発、脆弱性、およびパッチで最新情報を入手し続けます。開発チームがパスキーとWebAuthnに関連するワークショップ、ウェビナー、カンファレンスに参加することを奨励します。

ユーザーオンボーディングと教育: パスキー認証を導入する際には、ユーザーがその利点と仕組みを理解していることを確認します。サインアッププロセス中に明確な指示を提供し、ユーザーがパスキーを設定・使用するのを支援するためのリソース（FAQやビデオチュートリアルなど）を提供します。

これらのベストプラクティスに従うことで、開発者とプロダクトマネージャーは、セキュリティとユーザーエクスペリエンスの両方をバランスさせながら、パスキー認証を効果的に実装することができます。

あなたのウェブサイトやアプリで主流のユーザー向けにパスキーを実装したいが、ほとんどのユーザーはスマートフォンやラップトップを使用するため、セキュリティキー（例：YubiKey）をサポートする必要がない場合は、以下の設定を推奨します。

• authenticator: platform
• residentKey: required
• userVerification: required

利点:

• 作成されるすべてのキーがレジデントキーであるため、この設定では条件付きUIが可能になり、ユーザーはユーザー名を覚える必要がないため、ログインがさらにシームレスになります。
• Apple、Google、Microsoftのすべての最新デバイスがサポートされ、パスキーを使用できます。

WebAuthnサーバーの設定は複雑でありながら、認証のための堅牢で柔軟なフレームワークを提供します。これらの設定を習得することは非常に重要です。なぜなら、それは単に新しい標準を実装するだけでなく、ユーザー認証のセキュリティと効率を根本的に改善することだからです。

本質的に、WebAuthnサーバーの設定を理解することは、より安全で、効率的で、先進的なアプリケーションを構築するための投資です。デジタルランドスケープが進化するにつれて、このような技術に精通していることは不可欠になるでしょう。最新情報を入手するために、私たちのパスキーコミュニティに参加するか、以下のニュースレターを購読してください。