パスキーの基本
パスキーとは：開発者向けに仕組みとパスワードとの違いを整理する
10 分で読めます
この記事の要点
- パスキーは FIDO2 / WebAuthn の discoverable credential を指す呼び名で、端末の画面ロックと同じ操作でログインできます。
- 鍵はサイトのドメイン (RP ID) に結び付くため、偽サイトでは使えず、サーバーには公開鍵しか残りません。
- 入れるときに考えるのは暗号よりも、登録の入口・復旧・パスワードとの併存の 3 つです。
パスキーは、FIDO Alliance と W3C が定めた FIDO2 / WebAuthn にもとづくログインの方法で、パスワードの代わりに公開鍵暗号の鍵の組を使います。秘密鍵は利用者の端末 (またはパスワードマネージャー、セキュリティキー) に置かれ、サーバーには公開鍵だけを登録します。鍵はサイトのドメインに結び付くため、偽サイトでは使えず、サーバーのデータが漏れてもそこからログインはできません。利用者から見ると、スマートフォンや PC の画面ロックを解くのと同じ操作 (指紋・顔・PIN) でログインが終わります。
パスキーという言葉が指すもの
FIDO Alliance はパスキーを「FIDO の標準にもとづく認証の資格情報で、スマートフォンや PC、またはハードウェアのセキュリティキーに保存され、端末のロックを解くのと同じ操作でアプリやサイトにログインできるもの」と説明しています。
技術的には、W3C の Web Authentication (WebAuthn) の仕様にある discoverable credential (以前は resident key と呼ばれていたもの) を、利用者向けに言い換えた名前です。passkeys.dev の用語集も、パスキーを「FIDO2 / WebAuthn の discoverable credential を指す、利用者向けの上位の言葉」と定義しています。discoverable であることで、利用者がユーザー名を入れなくても、端末が「このサイト向けの鍵」を見つけて候補として出せます。
WebAuthn は 2026 年 8 月 25 日に Level 3 が W3C 勧告 (Recommendation) になりました。ブラウザの navigator.credentials.create() と navigator.credentials.get() がその API です。
登場する役者
WebAuthn の説明では、次の 3 者が出てきます。
| 役者 | 仕様での呼び名 | 何をするか |
|---|---|---|
| サービス (あなたのサーバー) | Relying Party (RP) | challenge (乱数) を発行し、返ってきた署名を公開鍵で検証する |
| ブラウザ | Client | API を受け付け、オリジンと RP ID の関係を確かめ、認証器へ中継する |
| 端末・パスワードマネージャー・セキュリティキー | Authenticator (認証器) | 鍵の組を作り、秘密鍵を保管し、利用者の確認をして署名する |
RP ID は、鍵が結び付くドメインです。通常はログイン画面のドメインか、その親のドメイン (例: login.example.jp に対して example.jp) にします。仕様上、パスキーはこの RP ID の範囲でしか使えません。
登録とログインで起きること
登録
- サーバーが challenge と、RP ID・利用者の ID・求める条件 (後述の
residentKeyやuserVerification) を含む options を作る - ブラウザが
navigator.credentials.create()で認証器に渡す - 認証器が利用者の確認 (指紋・顔・PIN など) をして、そのサイト専用の鍵の組を作る
- 公開鍵と、challenge を含む署名付きのデータがサーバーに返る
- サーバーは challenge・オリジン・RP ID のハッシュなどを確かめ、公開鍵を利用者に結び付けて保存する
ログイン
- サーバーが新しい challenge を発行する
- ブラウザが
navigator.credentials.get()で認証器に渡す - 認証器が利用者の確認をして、challenge を含むデータに秘密鍵で署名する
- サーバーは保存してある公開鍵で署名を検証し、通ればセッションを発行する
秘密鍵は認証器から出ません。生体情報も端末の中で処理され、サーバーに届くのは「利用者の確認が済んだ」という結果 (フラグ) だけです。
パスワードとの違い
| 観点 | パスワード | パスキー |
|---|---|---|
| サーバーが持つもの | パスワードのハッシュ (共有された秘密) | 公開鍵 (漏れても署名は作れない) |
| サイトごとの違い | 利用者が同じものを使い回せる | 鍵はサイト (RP ID) ごとに別に作られる |
| 偽サイト | 入力すれば相手に渡る | ブラウザがドメインを確かめるため、偽サイトのドメイン向けの署名は作られない |
| 強さ | 利用者が決める | 鍵は常に生成されたもので、推測できない |
| 入力 | 文字列を打つ | 端末のロック解除と同じ操作 |
この違いの中心は 2 つです。
- 共有された秘密が無い。 サーバーには公開鍵しか残らないので、データベースが漏れても、それを使って他のサービスに入られることがありません。パスワードの使い回しによる被害 (パスワードリスト攻撃) は、仕組みとして起きません。
- ドメインに結び付く。 署名の対象には、ブラウザが確かめたオリジンが入り、認証器は RP ID ごとに鍵を選びます。NIST SP 800-63B-4 は、このように認証の出力を検証者の名前 (ドメイン) に結び付ける方式を「verifier name binding」と呼び、WebAuthn をその例に挙げてフィッシング耐性のある方式としています。SMS やアプリのワンタイムパスワードのように、利用者が偽サイトに転記できる文字列はありません。
同期パスキーと端末固定のパスキー
パスキーには、保存のされ方で 2 種類あります。
- 同期パスキー (synced passkey): OS やパスワードマネージャーのクラウドで、利用者の複数の端末に同期されます。Apple は iCloud キーチェーンで端末間に同期し、エンドツーエンドで暗号化していると説明しています。Google は Google パスワードマネージャーで Android と Chrome の間に同期できるとしています。
- 端末固定のパスキー (device-bound passkey): 1 つの認証器から出ないもの。セキュリティキーに保存したパスキーが代表例です。
WebAuthn の仕様では、認証器のデータに BE (Backup Eligibility) と BS (Backup State) のフラグがあり、サーバーはそのパスキーが同期できる種類か、いまバックアップされているかを知ることができます。同期パスキーは機種変更に強く、端末固定のパスキーは鍵が 1 か所から出ないことを重視する用途に向きます。どちらが良いかは用途で決まり、詳しくは別の記事で扱います。
別の端末でログインする (hybrid)
パスキーを持っていない PC でログインしたいときは、画面に出る QR コードをスマートフォンで読み、スマートフォンのパスキーで署名できます。WebAuthn ではこの経路を hybrid というトランスポートとして定義しています。Google の開発者向けの説明では、2 台の端末が近くにあることを Bluetooth で確かめ、利用者がスマートフォンで承認してログインが終わります。サービス側で特別な実装は要りません。
開発者が決めておくこと
パスキーの暗号の部分は、ブラウザと認証器、検証ライブラリ (または外部の API) が担います。導入でつまずくのは周辺です。
- 登録の入口をどう守るか。 パスキーは登録した後は強いのですが、登録するときに本人であることを確かめるのはサービスの責任です。パスワードだけで入れる状態のまま登録を受け付けると、盗まれたパスワードで入った第三者が自分のパスキーを足せてしまいます。
- 復旧をどうするか。 端末をなくした、同期を使っていない、という利用者を、どう本人と確かめて再登録させるかを先に決めます。
- パスワードといつまで併存させるか。 全員が一度に移ることはありません。期限の決め方と、パスキーを持つ人にパスワードの入力欄を出すかどうかを決めます。
技術の選択 (自前で作る、ライブラリを使う、外部の API を使う) は、この 3 つを決めた後で構いません。
SealGate で実装する場合
SealGate は、既存のログインにパスキーを後付けする API とブラウザ SDK です。ログイン画面と利用者のデータは開発者の側に残り、SealGate が持つのは利用者 ID (external_id) と表示名、公開鍵、認証の記録です。登録とログインは「options を取る → ブラウザで認証器を動かす → verify に送る」の 2 段で、ブラウザ側は SDK の sg.register() / sg.login() が行います。仕組みは ドキュメント を、全体の流れは 既存のログインにパスキーを足す手順 をご覧ください。
よくある質問
パスキーは生体情報をサーバーに送りますか？
送りません。指紋や顔の照合は端末の中で行われ、サーバーに届くのは利用者の確認が済んだかどうかのフラグと署名だけです。
パスキーとセキュリティキーは別物ですか？
セキュリティキーは認証器の一種で、パスキーを保存する場所の 1 つです。FIDO Alliance の説明でも、パスキーはスマートフォンや PC のほか、ハードウェアのセキュリティキーに保存できるとしています。
サーバーの公開鍵が漏れたらどうなりますか？
公開鍵から秘密鍵は求められないため、漏れた公開鍵でログインすることはできません。ただし、どの利用者がどの鍵を持つかという情報は残るので、通常の個人情報と同じように扱います。
出典
- Web Authentication: An API for accessing Public Key Credentials Level 3（W3C Recommendation, 2026-08-25）
- FIDO Passkeys: Passwordless Authentication（FIDO Alliance）
- Terms（passkeys.dev）
- NIST SP 800-63B-4 Digital Identity Guidelines: Authentication and Authenticator Management（NIST, 2025-08）
- About the security of passkeys（Apple）
- Passkeys（Google for Developers）
- Passkeys use cases（Google for Developers）
