PKaaSで始めるパスキーのローカル開発

こんにちは。

LINEヤフー研究所の大神と田口です。

パスワードを使わない認証方法として、「パスキー（Passkey）」を目にする機会が増えてきました。

パスキーを使う認証（パスキー認証）では、端末の画面ロック解除で使っている生体認証をウェブサービスのログイン時に使えるため、ユーザー体験が良くなると言われています。

LINEヤフーではパスキーを導入しパスワードレス認証を提供していますが、自社サービスを提供している管理者の方々の中にも、パスキー認証の導入を検討している方がいらっしゃるのではないでしょうか？

パスキー認証ではサーバー側の仕様が複雑になりやすいため、公開鍵の管理や署名検証、チャレンジ生成などの処理を任せられるLINEヤフーのサービス「PKaaS」を紹介します。

認証サーバーを自前で構築せず、まずは手元のパソコン（ローカル環境）で動作を試してみたい開発者の方に向けて、パスキー認証の入り口までを案内します。

パスキー導入の課題

ウェブサービスの利用が増える中で、パスワードを使い回してしまうことに加え、巧妙な手口によるフィッシング詐欺の被害も増え続けており、パスワード認証を使い続けることの課題を身近に感じるケースが増えてきました。

こうした課題をさまざまな面におけるリスクと捉えて、ユーザー保護の観点からパスワードを使わない認証としてFIDO（Fast IDentity Online）認証の導入を検討するサービスが急速に増えています。

パスキー認証は図の「FIDOサーバー」を構築・運用することで、パスワードを使わずに認証を行う技術です。

本記事では、少しややこしいので、パスキーとFIDO認証/WebAuthnを以下のように呼びます。

パスキー：ユーザー向けの呼称（パスワードを使わない認証を指す文脈）WebAuthn/FIDO：実装・仕様の文脈（ブラウザAPIやプロトコルを指す文脈）

パスキー認証について詳しくはFIDO認証＆パスキー総復習（認証の仕組みやパスキー登場までの経緯）も参照してください。

パスキー認証とは、パスワードの代わりに公開鍵と秘密鍵（パスキー）の組み合わせを利用する認証方法で、かつては「FIDO認証」とも呼ばれていました。

一方で、開発環境によっては、FIDOサーバーの構築に開発コストがかかるかもしれません。

FIDOサーバー開発の負担

FIDOサーバーを実装するには、以下の対応のうち複数、場合によっては全てを検討する必要があります。

WebAuthn / FIDO2仕様への対応認証用公開鍵の安全な保管チャレンジ生成と署名検証処理ユーザー登録（Attestation）/認証（Assertion）フローの管理認証器情報やクレデンシャルIDの永続化認証基盤との連携設計（CookieやSAML連携など）

特に、独自のFIDOサーバーを開発・運用する必要があるケースでは、設計・実装・セキュリティレビュー・運用保守まで含めて大きなコストが発生します。

「パスキー認証を導入したいが、サーバー実装が重い」という課題が多くの開発チームにとって導入における最初の壁となるのではないでしょうか。

こうした課題を解決するアプローチの1つとして、私たちはPKaaS（Public-Key based authentication as a Service）を提案しています。

PKaaSとは

PKaaSは、パスキー認証に必要な機能をクラウドサービスとして提供します。

チャレンジ生成署名検証処理認証関連データの保存FIDOプロトコル処理の抽象化認証用公開鍵の管理（※本記事で紹介する機能では提供しません）

PKaaSのコンセプトや設計についてはPKaaSの紹介ページも御覧ください。

大まかにまとめると、パスキー認証の仕様に沿った複雑な処理をおまかせする仕組みです。

PKaaSがやらないこと

PKaaSは、IDaaS（Identity as a Service）製品のように「ログイン画面」や「セッション管理」を丸ごと提供するサービスではありません。

その代わり、アプリケーション側で認証体験や状態管理を自由に設計できます。

ログイン画面（UI/UX）のデザインログイン状態（セッション）の管理ユーザーIDとのひも付け（アカウント管理）リスク判定（追加認証の要否など）

大まかなPKaaSと開発者が実装する部分の役割分担

PKaaSは「署名検証が成立しているかどうか」を支援し、開発者が作るアプリでは「それをログインとして扱うか（セッション発行・権限付与など）」を決めます。

開発のメリット

PKaaSを利用することで、開発者は以下のメリットを得ることができます。

FIDOプロトコルの詳細実装から解放される署名検証ロジックを自前で持つ必要がなくなるアプリケーションロジックに集中できる

PKaaSを利用した実装は2つのパターンがあります。下図はAPIを利用した開発例です。

ローカル開発用API

ローカル開発用APIは、開発者がローカル環境でパスキー（WebAuthn/FIDO）の登録・認証フローを試すために、PKaaSが提供するAPI群です。

上図の開発例でいうと、中心部分にある「開発者サーバー」をローカル環境に設置し、PKaaSに処理を依頼できます。

このAPIの利点は、本番向けの構成や大がかりな準備に入る前に、まず手元で登録・認証フローを動かして確かめられることです。リモート環境に開発者サーバーを別途用意しなくても試し始めやすく、申請不要で実装イメージをつかみたい場合にも向いています。

PKaaS APIとの大きな違いは、公開鍵やユーザーひも付け情報をPKaaS側に保存しない点です（例えば、ユーザーIDとの対応、credentialIdなど）。

これは、ローカル検証で作成したデータがサービス側に残らないようにし、共有環境でのデータ衝突を避けるためです。

その代わり、登録・認証に必要な情報はローカルの開発者サーバーで管理します。

ローカル開発環境で実際に動かしてみる

ここからは、ローカル開発用APIを使って、手元のパソコン上で起動する「開発者サーバー」からパスキー認証の一連の流れを試す方法を見ていきます。

ここで押さえておきたいポイントはシンプルで、開発者が用意する必要があるのは手元のパソコン上で起動する開発者サーバーだけという点です。（ブラウザで開く認証ページも、この開発者サーバーから配信して同一オリジンに揃えるイメージです）

前提（ローカル開発用APIの位置づけ）

ローカル開発用APIは、ローカル開発・検証用途に限定されており、本番サービスや実アプリへの組み込みは想定されていません。

大まかな流れ

ここは細部より「流れ」を押さえればOKです。

Yahoo! JAPAN ID → アプリ登録 → Client IDの取得ローカルでHTTPSの開発環境を用意して、認証用ページと開発者サーバーを同一オリジンで動かす

つまり、手元のパソコンで起動する開発者サーバーが1つあればOK（そのサーバーがページ配信とAPI呼び出しをまとめて担当）

APIは登録（attestation）→ 認証（assertion）の順に進める（どちらも「チャレンジ発行→署名検証」の2段）

APIの呼び出し順は次の4本が基本です。

登録（attestation）：/api/attestation/options → /api/attestation/result認証（assertion）：/api/assertion/options → /api/assertion/result

ローカル開発用API特有のポイントとして、登録の署名検証結果で返ってくる localhost情報（資料内で「*」扱い）をローカルに保持し、認証の署名検証時に extensions として付与する、という扱いです（PKaaS側に鍵を保存しないため）。

注意点として、ローカル開発前に、fido-dev.test を 127.0.0.1 に割り当てる hosts 設定と、https://fido-dev.test でアクセスできる HTTPS環境を用意してください。ローカル開発用APIでは localhost ではなく fido-dev.test を認証ドメインとして利用します。

参考文献（一次情報）

APIリファレンス（Reference）：https://idp-demo.yahoo-net.jp/local-implementation-guides#referenceサンプル（Sample）：https://idp-demo.yahoo-net.jp/local-implementation-guides#sample

（動画）実際の動き：登録 → 認証

最後に、実際にローカルで「登録→認証」がどのように進むかを動画で紹介します。動画では特に次の点が分かるようにしています。

Register を押すと、チャレンジ取得 → WebAuthn呼び出し → 登録の署名検証まで進むAuthenticate を押すと、チャレンジ取得 → WebAuthn呼び出し → 認証の署名検証まで進む

検証を行う際の前提条件（技術要件）

ローカル環境でパスキー認証を検証する際には、デバイスやブラウザの要件があります。

対応デバイス/ブラウザ要件

以下の条件を満たす端末が必要です。

Android 9.0以上（画面ロック設定済み）iOS / iPadOS 16以上macOS 13（Ventura）以上推奨ブラウザ： Google Chrome

特に重要なのは、端末に画面ロックが設定されていることです。パスキー認証は、端末のセキュアな認証機能（生体認証・PIN等）を利用するため、この設定が必須です。

まとめと関連情報

パスキー認証は、使いやすいユーザー体験とセキュリティを両立する認証方式です。しかし、サーバー実装の負担が導入の障壁となるケースも少なくありません。

PKaaSの機能の1つである、ローカル開発用APIを活用することで、以下のメリットを得ることができます。

認証ロジックの複雑性を吸収開発コストを最小化ローカル環境で迅速に検証

今後、PKaaSでは、ローカル開発だけにとどまらない機能の拡充を検討しています。

さらに理解を深めたい方へ

PKaaSの技術の元となった学術論文：FIDOaaS: 公開鍵暗号方式に基づく認証機能の分離（外部サイトへ移動します）FIDO仕様やパスキーに関する情報：FIDOアライアンス （外部サイトへ移動します）

パスキー認証の仕組みや背景まで押さえることで、PKaaSの設計思想をより深く理解いただけたら幸いです。

パスワードを使わないパスワードレス認証が広がる中で、パスキーのさらなる普及につながればと考えています。まずはお手元のローカル環境で、PKaaSを動かしてFIDOサーバーの実装を試してみてください。