WebAuthn（Web Authentication）は、ブラウザから公開鍵認証を使うための API を定めた W3C の仕様です。パスキーや、USB などのセキュリティキーを使ったログインは、この API の上で動いています。
仕様の正式名称は Web Authentication: An API for accessing Public Key Credentials で、Level 3 が 2026年8月25日に W3C 勧告になりました。実装が固まった段階にある標準です。
どの層の話をしているのか
同じ話題で出てくる言葉が3つあり、層が違います。
| 言葉 | 層 | 誰が意識するか |
|---|---|---|
| パスキー | 利用者から見た認証情報 | 利用者 |
| WebAuthn | ブラウザの API | 実装する開発者 |
| CTAP | 端末と認証器の間の通信 | 主に認証器の実装側 |
Web アプリを作る側が直接触るのは WebAuthn です。「パスキーに対応する」と言うとき、実装として行うのはこの API を呼ぶことになります。
何をやり取りしているか
パスワードを送らない、というのが核心です。おおまかには次の流れになります。
- サーバーが毎回違うランダムな値を発行する
- ブラウザが認証器（端末や外付けキー）にそれを渡す
- 認証器が端末内の秘密鍵で署名して返す
- サーバーが登録済みの公開鍵で署名を検証する
秘密鍵は端末から出ません。サーバーが保持するのは公開鍵だけなので、サーバー側が侵害されても、そこからログインできる情報は出てきません。
ドメインが鍵に紐づく
登録時に、どのドメイン向けの資格情報かが記録されます。別ドメインの偽サイトからは対応する鍵が呼び出せないため、利用者が偽物に気づかなくても認証が成立しません。これが「フィッシング耐性」と呼ばれる部分の実体です。
実装するときに考えること
API を呼ぶこと自体は難しくありませんが、設計で決めることがいくつかあります。
- 複数の認証器を登録できるようにする。1つしか登録できない設計は、端末を失った時点で詰みます
- 認証器の種類をどこまで許すか。端末内蔵のみにするか、外付けキーも許すか。運用のしやすさと強度のどちらを取るかの判断です
- 既存のパスワード認証をどう畳むか。いきなり廃止せず、しばらく併存させるのが現実的です
- 復旧経路を弱くしない。ここが弱いと、強い認証を入れた効果が相殺されます
最後の項目が本質です。認証そのものより、認証を失ったときの導線の方が攻撃されやすいという構図は変わりません。