9つのWebAuthnサーバー実装ライブラリを比較

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

チートシートを入手

安全でシンプルなユーザー認証を提供することは、2024年のデジタル企業にとって必須条件です。新しいログイン標準としてのパスキーは、これらのニーズを満たす理想的なソリューションです。しかし、ユーザーにとってのパスキーの強化されたユーザーエクスペリエンスとセキュリティは、開発者として実装する際に代償を伴います。実装の難しさは、パスキーがユーザーだけでなく開発者にとっても比較的新しいこと、そしてパスワードベースの認証と比較して実装が非常に困難になる可能性があることに起因しています。実際、パスワード認証では1つのAPIエンドポイントが必要であるのに対し、パスキー認証では少なくとも4つのAPIエンドポイントが必要です。

パスキー認証を提供するためのサーバー側のコアコンポーネントの1つが**WebAuthnサーバー（緑色のライブラリ部分）**です。WebAuthnサーバーがより広範なエンタープライズスタック統合にどのように適合するかについての包括的なガイドについては、専用の記事を参照してください。

出典：Yubico

このブログ記事では、いくつかのWebAuthnサーバーライブラリ/パッケージ/SDKを比較し、違いを分析して、パスキー実装が初めての開発者向けの推奨事項を提供します。

そもそもなぜWebAuthnサーバーライブラリが必要なのかをよりよく理解するために、パスキーの実装方法を見てみましょう。原則として、ウェブサイトやアプリにパスキーを統合するには2つの方法があります。

1. サードパーティのパスキーソリューション（Corbadoなど）を使用する
2. 以下のWebAuthnサーバーライブラリのいずれかを使用して自分でパスキーを実装する

サードパーティのパスキーソリューションは統合が容易で、通常はエンジニアリング時間（特にエッジケース、メンテナンス、リカバリ、フォールバック、および改善されたパスキーのUX）を大幅に節約できますが、一部の開発者はすべてを自分で実装することを好みます。

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

Passkeysを試す

DIYによるパスキー実装がどのように機能するかを見てみましょう。非常に基本的なセットアップでは、登録（サインアップ）と認証（ログイン）のメカニズムが必要です。全体的なフローは似たようなスキーマに従いますが、両方のプロセス（WebAuthnセレモニーとも呼ばれます）は異なる方法で処理されます。

1. フロントエンド（ブラウザ）がサインアップまたはログイン要求を開始し、バックエンドAPIエンドポイントを呼び出します。
2. バックエンドはWebAuthnサインアップまたはログインパラメーターを生成します。これらはそれぞれPublicKeyCredentialCreationOptionsおよびPublicKeyCredentialRequestOptionsと呼ばれます。これらのWebAuthnパラメーターの最も重要な部分の1つはチャレンジです。その後、WebAuthnパラメーターはフロントエンドに送り返されます。
3. フロントエンドはこれらのWebAuthnパラメーターを受け取り、ローカルデバイスの認証システム（Face ID、Touch ID、Windows Helloなど）を使用してユーザーの身元を検証します。サインアッププロセスでは、新しい公開鍵と秘密鍵のペアが作成され、秘密鍵はローカルに保存され、公開鍵はサーバーに送信されます。ログインプロセスでは、パスキーの秘密鍵を使用してチャレンジに署名し、別のバックエンドAPIエンドポイントに送信します。
4. サインアッププロセスでは、バックエンドが公開鍵を受信して保存します。ログインでは、バックエンドが署名されたチャレンジを受信し、WebAuthnサーバーを使用してその整合性を検証します。

すべてのサインアップ/ログインプロセスにはこれらの手順が含まれるため、バックエンドはユーザー、パスキー、サインアップ/ログイン要求を追跡する必要があります。

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

パスキーの機能や（サードパーティのパスキーソリューションを使用しない）シンプルな実装がどのように見えるかについてより深い知識を得たい場合は、こちらのブログ記事をご覧ください。

実際のシナリオにおいて、自分でパスキーを実装する場合、サインアップとログインのための必要なAPIエンドポイントと基本的な実装を提供するだけではないことに留意してください。さらに、以下のトピックとユースケースに対処する必要があります。

• デバイス管理
• クロスプラットフォームおよびクロスデバイスのログインフロー
• ユーザー管理
• セッション管理
• パスキー対応デバイスの検出
• ユーザー教育
• フォールバック認証オプション
• リカバリメカニズム
• アカウント共有のオプション
• 高い採用率を実現するための最適化されたパスキー作成フローおよびパスキーログインフロー

ただし、基本的なパスキーの実装では、WebAuthn標準に準拠するだけで済みます。通常は、よく知られサポートされているWebAuthnサーバーライブラリを実装するだけで十分です。ライブラリはWebAuthnサーバーパラメーターを生成し、ログインチャレンジを検証するため、実質的に暗号化と最も複雑な部分を引き受けてくれます。

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

参加する

分析されたすべてのWebAuthnサーバーライブラリは、パスキー認証を提供するために必要な機能を提供しています。したがって、以下の基準に特に注意を払いました。

• オーセンティケーターの選択基準（Authenticator Selection Criteria）： 特定の動作やセキュリティ機能（例：レジデントキーの作成の強制）の環境設定をどのように行えるか？
• グローバル設定（Global Settings）： 必要な構成をどの程度一元化できるか？
• ドキュメント（Documentation）： WebAuthnサーバーライブラリがどの程度適切に文書化されており、分かりやすいか。
• 例（Examples）： リファレンスとして使用できる実装例があるか。

以下のWebAuthnサーバーライブラリを分析しました（2023年12月時点のGitHubスター数の降順で並べています）：

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

利用データを見る

• プログラミング言語： Typescript
• フレームワーク： Node.js
• 作成者： Matthew Miller（Duo Security / Cisco）
• スター数： 1000
• 使用数： 781
• コントリビューター数： 19
• FIDO適合性： はい
• グローバル設定： いいえ
• オーセンティケーターの選択基準： W3Cの提案に従う（authenticatorAttachment、residentKey、requireResidentKey、およびuserVerificationなどの変数を含む必要があり、これらもW3Cのページで説明されています）
• ドキュメント： 迅速なセットアップと使いやすさに重点を置いた優れた構造。パスキーの知識（例：パスキーとは何か、どのように機能するか）も含まれています
• 例： ドキュメントで利用可能なサンプルプロジェクト
• 推奨データ構造：

type UserModel = {
  id: string;
  username: string;
  currentChallenge?: string;
};
 
/**
 * It is strongly advised that authenticators get their own DB
 * table, ideally with a foreign key to a specific UserModel.
 *
 * "SQL" tags below are suggestions for column data types and
 * how best to store data received during registration for use
 * in subsequent authentications.
 */
type Authenticator = {
  // SQL: Encode to base64url then store as `TEXT`. Index this column
  credentialID: Uint8Array;
  // SQL: Store raw bytes as `BYTEA`/`BLOB`/etc...
  credentialPublicKey: Uint8Array;
  // SQL: Consider `BIGINT` since some authenticators return atomic timestamps as counters
  counter: number;
  // SQL: `VARCHAR(32)` or similar, longest possible value is currently 12 characters
  // Ex: 'singleDevice' | 'multiDevice'
  credentialDeviceType: CredentialDeviceType;
  // SQL: `BOOL` or whatever similar type is supported
  credentialBackedUp: boolean;
  // SQL: `VARCHAR(255)` and store string array as a CSV string
  // Ex: ['usb' | 'ble' | 'nfc' | 'internal']
  transports?: AuthenticatorTransport[];
};

• その他の特徴： WebAuthnレスポンス用の優れたWebAuthn Debuggerがあり、バックエンド/サーバーライブラリだけでなく、フロントエンド用のライブラリ（基本的にクライアントからの一部のWeb Authentication APIをラップするもの）も提供しています。
• 個人的な評価： これまで見た中で最も直感的なセットアップであり、非常にわかりやすいです。さらに、クライアントの実装を支援するブラウザライブラリも提供する数少ないライブラリの1つであり、非常に優れています。ライブラリの作成者はWebAuthn/パスキーコミュニティで非常に活発に活動しています。
• GitHubリンク： https://github.com/MasterKale/SimpleWebAuthn

• プログラミング言語： C#
• フレームワーク： .NET
• 作成者： Anders à berg、Alex Seigler
• スター数： 962
• 使用数： 200
• コントリビューター数： 40
• FIDO適合性： はい
• グローバル設定： はい
• オーセンティケーターの選択基準： W3Cの提案に従う
• ドキュメント： Readmeといくつかのサンプルのみ。ライブラリのウェブサイトにいくつかのパスキーインテリジェンス情報があります。
• 例： 統合例を示すデモコントローラーとサンプルクレデンシャルストアが利用可能
• 推奨データ構造：

public class StoredCredential
{
    /// <summary>
    /// The Credential ID of the public key credential source.
    /// </summary>
    public byte[] Id { get; set; }
 
    /// <summary>
    /// The credential public key of the public key credential source.
    /// </summary>
    public byte[] PublicKey { get; set; }
 
    /// <summary>
    /// The latest value of the signature counter in the authenticator data from any ceremony using the public key credential source.
    /// </summary>
    public uint SignCount { get; set; }
 
    /// <summary>
    /// The value returned from getTransports() when the public key credential source was registered.
    /// </summary>
    public AuthenticatorTransport[] Transports { get; set; }
 
    /// <summary>
    /// The value of the BE flag when the public key credential source was created.
    /// </summary>
    public bool IsBackupEligible { get; set; }
 
    /// <summary>
    /// The latest value of the BS flag in the authenticator data from any ceremony using the public key credential source.
    /// </summary>
    public bool IsBackedUp { get; set; }
 
    /// <summary>
    /// The value of the attestationObject attribute when the public key credential source was registered.
    /// Storing this enables the Relying Party to reference the credent’al's attestation statement at a later time.
    /// </summary>
    public byte[] AttestationObject { get; set; }
 
    /// <summary>
    /// The value of the clientDataJSON attribute when the public key credential source was registered.
    /// Storing this in combination with the above attestationObject item enables the Relying Party to re-verify the attestation signature at a later time.
    /// </summary>
    public byte[] AttestationClientDataJson { get; set; }
 
    public List<byte[]> DevicePublicKeys { get; set; }
 
    public byte[] UserId { get; set; }
 
    public PublicKeyCredentialDescriptor Descriptor { get; set; }
 
    public byte[] UserHandle { get; set; }
 
    public string AttestationFormat { get; set; }
 
    public DateTimeOffset RegDate { get; set; }
 
    public Guid AaGuid { get; set; }
}

• その他の特徴： Bitwardenによって使用されています（スタートアップのpasswordless.devはBitwardenに買収されました）
• 個人的な評価： 豊富な補足資料を備えた開発者向けの使いやすいライブラリ
• GitHubリンク： https://github.com/passwordless-lib/fido2-net-lib

• プログラミング言語： Python
• フレームワーク： 特定なし
• 作成者： Duo Labs
• スター数： 727
• 使用数： 912
• コントリビューター数： 23
• FIDO適合性： 該当なし
• グローバル設定： いいえ
• オーセンティケーターの選択基準： W3Cの提案に従う
• ドキュメント： ほとんどなし。事前にパスキーの知識が必要です
• 例： サインアップとログインの小さなコードサンプルが含まれています
• 推奨データ構造： 該当なし
• その他の特徴： Python >= 3.8が必要です
• 個人的な評価： ファイル数が少なく比較的コンパクトなライブラリで、短時間で概要を把握できます。
• GitHubリンク： https://github.com/duo-labs/py_webauthn

• プログラミング言語： Ruby
• フレームワーク： Ruby on Rails
• 作成者： Cedarcode
• スター数： 580
• 使用数： 679
• Gemダウンロード数： 1,800万
• コントリビューター数： 27
• FIDO適合性： はい
• グローバル設定： はい
• オーセンティケーターの選択基準： W3Cの提案に従う
• ドキュメント： Readmeのみがドキュメントです
• 例： 該当なし
• 推奨データ構造： 該当なし
• その他の特徴： このライブラリのラッパーも利用可能です（warden-webauthn、devise-passkeys）
• 個人的な評価： 補足資料がかなり限られているため、Rubyとパスキーの両方に精通している場合にのみこのライブラリを推奨します
• GitHubリンク： https://github.com/cedarcode/webauthn-ruby

• プログラミング言語： Go
• フレームワーク： Gin、EchoなどのGoベースのフレームワーク
• 作成者： 元々はDuo Labs / James Elliottによって継続
• スター数： 480
• 使用数： 280
• コントリビューター数： 18
• FIDO適合性： はい
• グローバル設定： はい
• オーセンティケーターの選択基準： W3Cの提案に従う
• ドキュメント： いくつかのサンプルを含むReadmeのみがドキュメントです
• 例： サンプルリポジトリが利用可能
• 推奨データ構造： 該当なし
• その他の特徴： ファイル数が多く、概要を把握するのに時間がかかります
• 個人的な評価： 人気のあるライブラリであり、慣れれば使いやすいですが、事前にパスキーの知識（どのように機能するか、手順がどのようなものかなど）を学ぶことをお勧めします。
• GitHubリンク： https://github.com/go-webauthn/webauthn

• プログラミング言語： Java
• フレームワーク： Maven / Gradle
• 作成者： Yubico
• スター数： 391
• 使用数： 該当なし
• コントリビューター数： 27
• FIDO適合性： 該当なし
• グローバル設定： はい
• オーセンティケーターの選択基準： W3Cの提案に従う。
• ドキュメント： Readmeのみがドキュメントですが、かなり詳細です
• 例： 該当なし
• 推奨データ構造： 該当なし
• その他の特徴： Credential Repositoryインターフェースが付属しており、必要なデータベース検索メソッドに関する明確なガイダンスを提供します。
• 個人的な評価： データベースは自分で管理する必要がありますが、クレデンシャルリポジトリはデータベース設計プロセスで大いに役立ちます。Javaの実装は本質的に膨大な数のファイルになり、各属性にクラスが必要であり、通常は独自のファイルに保存されます。これにより、概要を把握するのに時間がかかります。
• GitHubリンク： https://github.com/Yubico/java-webauthn-server

• プログラミング言語： Rust
• フレームワーク： Rustベース（Rocket、Axumなど）
• 作成者： Kanidm Identity Management Project
• スター数： 351
• 使用数： 617
• コントリビューター数： 25
• FIDO適合性： 該当なし
• グローバル設定： はい
• オーセンティケーターの選択基準： 構成の可能性が非常に限られています。他のライブラリはW3C標準に完全に準拠して実装されており、より高い構成可能性を示しています。
• ドキュメント： 自動生成された技術ドキュメントがありますが、あまり詳細ではありません
• 例： 3つの異なるWebフレームワークの例を含むチュートリアルリポジトリが利用可能
• 推奨データ構造： 該当なし
• その他の特徴： このライブラリはSUSE product securityによるセキュリティ監査に合格しています。
• 個人的な評価： 構成可能性とドキュメントが限られているため、メインのフレームワークがRustベースであり、パスキーの機能について知識がある場合にのみこのライブラリを推奨します。
• GitHubリンク： https://github.com/kanidm/webauthn-rs

• プログラミング言語： PHP
• フレームワーク： Symfony
• 作成者： Florent Morselli
• スター数： 347
• 使用数： 該当なし
• コントリビューター数： 18
• FIDO適合性： はい
• グローバル設定： はい
• オーセンティケーターの選択基準： W3Cの提案に従う。
• ドキュメント： 技術的な詳細を含むだけでなく、パスキーをゼロから説明する広範なドキュメント
• 例： サンプルリポジトリが利用可能
• 推奨データ構造：

<?php
 
declare(strict_types=1);
 
namespace App\Entity;
 
use App\Repository\PublicKeyCredentialSourceRepository;
use DateTimeImmutable;
use Doctrine\DBAL\Types\Types;
use Doctrine\ORM\Mapping as ORM;
use Symfony\Component\Uid\AbstractUid;
use Symfony\Component\Uid\Uuid;
use Webauthn\PublicKeyCredentialSource as BasePublicKeyCredentialSource;
use Webauthn\TrustPath\TrustPath;
 
#[ORM\Table(name: 'pk_credential_sources')]
#[ORM\Entity(repositoryClass: PublicKeyCredentialSourceRepository::class)]
class PublicKeyCredentialSource extends BasePublicKeyCredentialSource
{
    #[ORM\Column(type: Types::DATETIME_IMMUTABLE)]
    public readonly DateTimeImmutable $createdAt;
 
    #[ORM\Id]
    #[ORM\Column(type: Types::STRING, length: 255)]
    #[ORM\GeneratedValue(strategy: 'NONE')]
    private string $id;
 
    public function __construct(
        string $publicKeyCredentialId,
        string $type,
        array $transports,
        string $attestationType,
        TrustPath $trustPath,
        AbstractUid $aaguid,
        string $credentialPublicKey,
        string $userHandle,
        int $counter
    ) {
        $this->id = Uuid::v4()->toRfc4122();
        $this->createdAt = new DateTimeImmutable();
        parent::__construct($publicKeyCredentialId, $type, $transports, $attestationType, $trustPath, $aaguid, $credentialPublicKey, $userHandle, $counter);
    }
 
    public function getId(): string
    {
        return $this->id;
    }
}

• その他の特徴： 該当なし
• 個人的な評価： パスキーを始めたいが事前知識がない人に適しています
• GitHubリンク： https://github.com/web-auth/webauthn-framework

• プログラミング言語： Java
• フレームワーク： Maven
• 作成者： WebAuthn4j
• スター数： 342
• 使用数： 該当なし
• コントリビューター数： 19
• FIDO適合性： はい
• グローバル設定： はい
• オーセンティケーターの選択基準： discouraged、preferred、requiredの値を伴うW3C提案のUserVerificationRequirementパラメータの代わりに、webauthn4jはブール変数としてverificationRequiredとuserPrecenseRequiredを提供します
• ドキュメント： 乾燥していますが、いくつかのコードサンプルを含む広範なドキュメントが利用可能
• 例： サンプルリポジトリが利用可能
• 推奨データ構造： 該当なし
• その他の特徴： 該当なし
• 個人的な評価： パスキーの背後にある概念ではなく、機能のみに焦点を当てた1つの大きなページであるため、ドキュメントを読むのはすぐに退屈で複雑になります。
• GitHubリンク： https://github.com/webauthn4j/webauthn4j

以下の表は、WebAuthnサーバーライブラリの概要を示しています。

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

購読する

ほとんどのライブラリは同等に強力であり、WebAuthn標準を実装しているため、以下のディシジョンツリーをお勧めします。

• 使用しているフレームワークとプログラミング言語のWebAuthnサーバーライブラリが利用可能： 上記のライブラリのいずれかに依存するフレームワークライブラリはリストしていません（例：SymfonyやLaravelで利用可能なPHPのカスタマイズがあります）。フレームワークの実装がある場合は、現在のフレームワーク構造にWebAuthn API呼び出しをネイティブに実装し、データベースの抽象化を使用してストレージを実装できるため、これを選択してください。
• 使用しているプログラミング言語のWebAuthnサーバーライブラリが利用可能： バックエンドAPIエンドポイントが必要なため、ネイティブプログラミング言語のWebAuthnサーバーライブラリを選択し、現在のAPIエンドポイントにネイティブに組み込むことができるようにします。
• 使用しているプログラミング言語で利用できるWebAuthnサーバーライブラリがない： この場合、Corbadoのようなマネージドパスキーソリューションの使用を検討する必要があります。それがオプションではない場合、商業プロジェクトやオープンソースプロジェクトの多くで使用されており、導入実績が多く軽量であるため、go-webauthnまたはSimpleWebAuthnを使用することをお勧めします。

特定のプロジェクトがまだなくてもWebAuthnサーバー全般について詳しく知りたい場合は、ライブラリとドキュメントや実装例などの補足資料との間にいくつかの違いがあるため、いくつか推奨事項があります。したがって、パスキー実装の旅をキックスタートしたいソフトウェア開発者には、以下の実装を選択することをお勧めします。

• 迅速なテストの場合： _py_webauthn_パッケージは、すぐに使えるコードスニペットを使用してすぐに実装できます。メソッドを1回呼び出すだけで、認証に必要なオプションを生成できます。ライブラリをフレームワークに埋め込んで構成する必要がないため、迅速なテストに最適です。
• 直感的な実装の場合： Typescriptで記述された_SimpleWebauthn_パッケージは、シンプルで開発者に優しいものです。_py_webauthn_と同様に実装は非常にミニマルですが、認証プロセスをガイドするドキュメントも付属しています。ただし、_py_webauthn_とは対照的に、_SimpleWebAuthn_には変更なしで実行できる明確な例が付属していません。
• 深い理解の場合： PHP用の_webauthn-framework_ライブラリは、パスキーの概念に焦点を当てた広範で構造化されたドキュメントで際立っています。_webauthn4j_のようなドキュメントが豊富な他のライブラリとの主な違いは、ドキュメントの設計と鮮やかさです。

サーバー側でWebAuthnがどのように機能するかをさらに深く理解したい場合は、WebAuthn RFCの「WebAuthn Relying Party Operations」という非常に詳細なセクションを読むことができます。このセクションでは、新しいクレデンシャルの登録（7.1）および認証アサーションの検証（7.2）のために実装する必要があるすべての手順が詳しく説明されています。

具体的なパスキーとWebAuthnの要件を評価します。このブログ記事では、discoverable credentials（Discoverable Credentials）としてパスキーのみをサポートしたいと想定しています。PublicKeyCredentialCreationOptionsとPublicKeyCredentialRequestOptions、そしてクライアント側のnavigator.credentials.create()とnavigator.credentials.get()のWebAuthn API呼び出しを読んで、ユースケースに合わせてWebAuthnサーバーSDKの構成のパラメータを正しく設定してください。

すべてのWebAuthnサーバーライブラリについて、以下の情報を永続化/アクセスするための適切なデータベース構造を提供する必要があります。

• クレデンシャル（Credentials）
• ユーザー（Users）
• チャレンジ（Challenges）
• オーセンティケーター（Authenticators）

一部のライブラリについては、特定の推奨事項と例があります（有用と思われる場合は上記で提供しています）。どのWebAuthnフィールドをどこに保存する必要があるかを完全に理解することが不可欠です。ユーザーID（user.id）に使用する値を特定することに特に注意を払ってください。また、ユーザーがパスキーを削除した場合にどうなるかも考慮に入れてください。それに加えて、オプションで特定のオーセンティケーターの使用を制限することができます。パスキーに関連する有効なオーセンティケーターのリストはこちらにあります。セキュリティキーの構成証明（アテステーション）もサポートして確認したい場合は、まったく別の話になります。詳細情報はこちらにあります。

ユーザーがパスキーとフォールバック認証方法を使用するデバイスを特定します。ユーザーが使用しているデバイス、ブラウザ、オペレーティングシステムがわからない場合は、プラットフォーム、ブラウザ、オペレーティングシステム全体でのパスキー対応に関する最新データについて、State of Passkeysを確認してください。特定のデバイスのパスキーの採用やパスキー対応のシェアについて具体的な質問がある場合は、お気軽にお問い合わせください。このトピックに関するさらなる洞察を提供し、サポートさせていただきます。可観測性（オブザーバビリティ）の観点からは、クライアント側のWebAuthnエラーとサーバー検証の拒否を別々のストリームとして維持します。クライアント側のバケット定義には、WebAuthnエラーを使用します。さらに、Windows 10とLinuxはパスキーのサポートが最も少ない（あるいは全くない）ため、これらのオペレーティングシステム向けに専用のソリューションを用意する必要があることに留意してください。

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

利用データを見る

現在、ほぼすべての言語やフレームワークについて、確立されたWebAuthnサーバーライブラリが存在します。異なる言語のライブラリを比較しても、特定の実装の明確な優位性は示されていません。むしろ、最も使い慣れたフレームワーク/プログラミング言語を使用する必要があります。あるいは、WebAuthnを自分で実装したくなく、付随するすべての処理を行いたくない場合は、Corbadoのような専用の構築済みパスキー認証ソリューションを試すことができます。パスキーを中心としたオールインワンの認証ソリューションとして、優れたパスキーインテリジェンス、セッション管理、およびフォールバック認証方法が備わっているため、製品の開発に集中し、認証を手放すことができます。こちらから無制限のユーザーで無料でお試しいただけます。

Corbadoについて

Corbadoは、大規模なconsumer認証を運用するCIAMチームのためのAuthentication 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エキスパートに相談する →

まず、特定のフレームワーク用のライブラリが存在するかどうかを確認し、次にプログラミング言語用のライブラリを確認します。リストされているすべてのライブラリはWebAuthn標準を同等に実装しているため、ライブラリ間の機能の違いよりも、既存のスタックへの親和性を優先して選択する必要があります。

少なくとも、クレデンシャル、ユーザー、チャレンジ、およびオーセンティケーターを永続化する必要があります。ユーザーID（userHandle）としてどの値を割り当てるかに細心の注意を払い、ユーザーがデバイスからパスキーを削除するシナリオを計画してください。

WebAuthnサーバーライブラリは、PublicKeyCredentialCreationOptionsおよびPublicKeyCredentialRequestOptionsパラメータの生成や、署名されたチャレンジの検証など、最も複雑な暗号化操作を処理します。これらをゼロから正しく行うことは、すでにテストされ監査されているFIDO準拠のライブラリを使用するよりもはるかに困難です。

Windows 10とLinuxはパスキーのサポートが最も少ないため、これらのプラットフォームのユーザーには専用のフォールバックソリューションが必要です。クライアント側のWebAuthnエラーとサーバー検証の拒否を別々のストリームとして監視することで、本番環境におけるOS固有の問題を特定しやすくなります。