Webアプリにパスキー認証を導入する手順と注意点

FIDO2 や WebAuthn の普及により、パスワードレス認証は「将来の構想」ではなく、現実的な選択肢になりました。中でもパスキーは、主要 OS・ブラウザが標準対応を進めており、Web アプリケーションの認証方式として無視できない存在です。

本記事では、既存の ID・パスワード認証を持つ Web アプリに、パスキーを追加導入したい開発者を対象に、技術的な仕組みから導入手順、実装時の注意点、最小構成のサンプルイメージまでを体系的に解説します。

パスワード管理の課題に悩む Web 開発者にとって、次の一手を考えるための実践的な指針となれば幸いです。

パスキーとは何か？技術的背景と仕組み
パスキーの対応プラットフォームとブラウザ状況
Webアプリへのパスキー導入手順
実装サンプル構成とコード例
まとめ：パスキーはこれからの Web 認証の標準候補

パスキーとは何か？技術的背景と仕組み

この章では、パスキーがどのような技術を基盤として成り立っているのかを整理します。単なる「便利なログイン方法」ではなく、どのようなセキュリティ特性を持つのかを理解することが重要です。

パスキーの基本概念

パスキー（Passkey）は、FIDO Alliance が推進する公開鍵暗号方式に基づくパスワードレス認証手段です。

従来の ID・パスワード認証とは異なり、ユーザーはパスワードを記憶・入力する必要がありません。

主な特徴は以下のとおりです。

サーバーには 公開鍵のみ を保存
秘密鍵はユーザー端末から外部に出ない
生体認証（指紋・顔）や端末ロックと連動
フィッシング耐性が非常に高い

この仕組みにより、サーバー侵害時でもパスワード流出という根本的なリスクを排除できます。

WebAuthn と FIDO2 の関係

パスキーは単独の技術ではなく、以下の標準仕様の上に成り立っています。

FIDO2：認証の全体仕様（CTAP + WebAuthn）
WebAuthn：ブラウザから利用するための JavaScript API

Web アプリ開発者は WebAuthn API を通じて、パスキーの登録・認証を行います。

鍵生成や署名処理といった暗号処理の実体は、OS やセキュリティデバイスが担当します。そのため、アプリケーション側で暗号アルゴリズムを実装する必要はありません。

なぜ「パスワードレス」が重要なのか

パスワード認証は、長年にわたり以下の課題を抱えてきました。

パスワード使い回しによる被害拡大
フィッシングサイトによる認証情報の窃取
管理負担による弱いパスワードの使用

パスキーはこれらを構造的に解決し、「覚えなくてよい」「盗まれにくい」認証体験を実現します。

UX とセキュリティを同時に向上させたい Web サービスにとって、非常に相性の良い方式と言えるでしょう。

パスキーの対応プラットフォームとブラウザ状況

パスキーを導入する際は、対応環境の把握が欠かせません。この章では、主要プラットフォームの状況を整理します。

主要 OS・ブラウザの対応状況

現在、以下の環境でパスキーが正式にサポートされています。

iOS / iPadOS / macOS（Safari）iCloud キーチェーンと連携し、Apple ID 経由で同期
Android（Chrome）Google アカウントに紐づくパスキー管理
Windows（Edge / Chrome）Windows Hello（指紋・顔認証・PIN）と連携

ユーザーは、同一アカウントでログインしている複数デバイス間で、パスキーを安全に同期できます。

クロスデバイス利用の仕組み

パスキーは「端末依存」と誤解されがちですが、実際には以下のような仕組みで同期されます。

Apple：iCloud キーチェーンによる暗号化同期
Google：Google アカウント経由の同期
Microsoft：Microsoft アカウントと Windows Hello

ただし、異なるエコシステム間（Apple と Google など）の完全な相互運用性は限定的です。設計時にはこの点を考慮する必要があります。

Webアプリへのパスキー導入手順

ここでは、Web アプリケーションにパスキー認証を導入する際の全体像を解説します。実装前に、処理の役割分担を把握しておきましょう。

導入フローの全体像

パスキー導入は、次の流れで進みます。

WebAuthn 対応サーバーの準備
パスキー登録（クレデンシャル作成）
パスキー認証（署名付きチャレンジ）
サーバー側での検証

HTTPS 配信と同一オリジンポリシーの遵守は必須条件です。

導入前チェックリスト

実装に入る前に、以下を確認しておくとスムーズです。

HTTPS で配信されている
同一オリジンで動作する構成になっている
ユーザー ID が一意かつ安定している（メールアドレスなど）
認証情報を保存できるデータベース設計がある

WebAuthn サーバーの構築

WebAuthn に対応したサーバー実装が必要です。代表的なライブラリには以下があります。

Node.js：SimpleWebAuthn
.NET：FIDO2-Net-Lib
Java：webauthn-server

これらを利用することで、チャレンジ生成や署名検証を安全に実装できます。

実装サンプル構成とコード例

ここでは、ASP.NET（MVC / Core）で既存の ID・パスワード認証を持つ Web アプリに、パスキーを追加するケースを想定した実装例を紹介します。実務での導入を想定し、概念理解と役割分担が分かる粒度に留めています。

想定システム構成

フロントエンド：Razor View + JavaScript
バックエンド：ASP.NET MVC / ASP.NET Core
WebAuthn ライブラリ：FIDO2-Net-Lib
データベース：ユーザーテーブル + パスキー情報

データ設計の考え方

UserId（既存ユーザー）と CredentialId を紐づけて保存
1ユーザーにつき複数パスキーの登録を許可
登録日時・デバイス表示名を保持

サーバー側：登録オプション生成（Controller例）

// パスキー登録用オプション生成
public IActionResult RegisterOptions()
{
    var user = GetCurrentUser(); // 既存ログインユーザー

    var options = _fido2.RequestNewCredential(
        new Fido2User
        {
            Id = Encoding.UTF8.GetBytes(user.UserId),
            Name = user.Email,
            DisplayName = user.DisplayName
        },
        new List<PublicKeyCredentialDescriptor>(),
        AuthenticatorSelection.Default,
        AttestationConveyancePreference.None
    );

    HttpContext.Session.SetString("fido2.attestation", options.ToJson());
    return Json(options);
}

クライアント側：パスキー登録（JavaScript）

const options = await fetch('/Passkey/RegisterOptions').then(r => r.json());
const credential = await navigator.credentials.create({ publicKey: options });

await fetch('/Passkey/Register', {
  method: 'POST',
  body: JSON.stringify(credential),
  headers: { 'Content-Type': 'application/json' }
});

サーバー側：登録結果の検証

public IActionResult Register([FromBody] AuthenticatorAttestationRawResponse attestation)
{
    var jsonOptions = HttpContext.Session.GetString("fido2.attestation");
    var options = CredentialCreateOptions.FromJson(jsonOptions);

    var result = _fido2.MakeNewCredentialAsync(attestation, options, _ => true).Result;

    SaveCredential(result); // 公開鍵情報をDBに保存
    return Ok();
}