パスワードレスログインの仕組み:内部動作を理解する

「サインイン」をクリックし、スマートフォンが指紋を求め、認証が完了する。パスワードの入力も、メールからのコードのコピーも不要です。認証フローを実装した経験があれば、これは魔法のように感じるか、あるいは理解せずに統合することを期待されているブラックボックスのように思えるかもしれません。

本記事では、パスキーとWebAuthnがブラウザAPIの下でどのように動作しているかを解説します。認証フロー、使用される暗号プリミティブ、そしてFIDO2ベースのパスワードレス認証をマジックリンクやOTPのような従来のアプローチと根本的に異なるものにするセキュリティ特性について理解できるでしょう。

パスキーが従来の「パスワードレス」手法に取って代わった理由

マジックリンクとワンタイムパスワードは、ログインフォームからパスワードフィールドを削除しましたが、共有秘密を排除したわけではありません。マジックリンクは依然としてメールを介して送信されるベアラートークンであり、傍受可能で、再生可能であり、ユーザーが偽装ドメイン上のリンクをクリックすればフィッシング可能です。SMSで送信されるOTPは、SIMスワッピング攻撃に対して脆弱です。

パスキーはこれを異なる方法で解決します。秘密(秘密鍵)がデバイスから外に出ることがなく、ネットワーク上を移動することもない公開鍵暗号を使用します。サーバーは公開鍵のみを保存し、データベースが侵害されても攻撃者にとって無価値です。

これがFIDO2とWebAuthnの核心的な洞察です:認証は秘密の送信ではなく、所有の暗号的証明を通じて行われます。

WebAuthn認証フロー

ユーザーがパスキーで認証する際、通常4つのコンポーネントが相互作用します:フロントエンドコード、ブラウザのWebAuthn API、認証器(多くの場合OSキーチェーン、スマートフォン、またはハードウェアセキュリティキー)、そしてサーバーです。

登録:認証情報の作成

登録時、サーバーはチャレンジ(ランダムなバイト列)を生成し、リライングパーティID(通常はドメイン)と共にブラウザに送信します。フロントエンドはこれらのパラメータを使用してnavigator.credentials.create()を呼び出します。

ブラウザはCTAP(Client to Authenticator Protocol)を介してこのリクエストを認証器に渡します。認証器は新しい鍵ペアを生成し、秘密鍵を安全に保存し、公開鍵と署名された構成証明を返します。

サーバーは公開鍵、認証情報ID、署名カウンタなどのメタデータを受け取り保存します。パスワードハッシュも共有秘密もなく、ドメインにスコープされた公開鍵のみです。

認証:所有の証明

ユーザーが戻ってきたとき、サーバーは新しいチャレンジを生成します。フロントエンドはnavigator.credentials.get()を呼び出し、ブラウザは認証器にプロンプトを表示します。

認証器はRP IDに一致する認証情報を見つけ、ユーザー検証(生体認証、PIN、またはプレゼンス)を要求し、秘密鍵でチャレンジに署名します。この署名は認証器データと共にサーバーに返されます。

サーバーは保存された公開鍵に対して署名を検証します。一致すれば、ユーザーは秘密鍵を送信することなく所有を証明したことになります。

オリジンバインディング:フィッシング耐性メカニズム

パスキーを単に「フィッシングが難しい」ではなく、真にフィッシング耐性のあるものにしているのがこれです。認証器は認証情報をリライングパーティのオリジンに暗号的に紐付けます。

チャレンジに署名する際、認証器は署名データにリライングパーティIDハッシュ(ドメインから派生)を含めます。攻撃者がg00gle.comに類似サイトを作成しても、google.comの認証情報は単に機能しません—オリジンが一致せず、認証器は有効な署名を生成しません。

これはユーザーがクリックして通過できるUI警告ではありません。プロトコルレベルで暗号的に強制されます。

同期型とデバイス紐付き型のパスキー

現代のパスキーは通常、OSキーチェーン(AppleのiCloud Keychain、Google Password Manager、または1Passwordのようなサードパーティマネージャー)を介してデバイス間で同期されます。これにより、ユーザーがスマートフォンを変更してもアクセスを失わないため、ユーザビリティが大幅に向上します。

デバイス紐付き型パスキー(ハードウェアセキュリティキーなど)は、より強力な保証を提供します—秘密鍵が正確に1つのデバイスに存在することが証明可能です。ほとんどのWebアプリケーションでは、同期型パスキーが優れたUXで十分なセキュリティを提供します。どちらが重要かは脅威モデルによって決まります。

現代のUXパターン:条件付きUI

ユーザー名フィールドのオートフィル候補にパスキープロンプトが表示されるのを見たことがあるでしょう。これが条件付きUIです—ブラウザはユーザーが明示的にパスワードレスログインをリクエストする前に、利用可能なパスキーを積極的に提供します。

これを実装するには、mediation: 'conditional'を指定してnavigator.credentials.get()を呼び出し、入力フィールドにautocomplete="username"を追加します。

ブラウザが検出と表示を処理します。

多くのアプリケーションは、既存ユーザーをアップグレードするために条件付きUIを使用しています:パスワードログインが成功した後、将来のセッションのためにパスキーを登録するようユーザーにプロンプトを表示します。

セキュリティ特性と信頼境界

パスキーは攻撃対象領域を大幅に削減しますが、魔法ではありません。秘密鍵のセキュリティは認証器の実装に依存します—通常はデバイスのセキュアエンクレーブまたはTPMです。デバイス自体がハードウェアレベルで侵害された場合、すべての保証は無効になります。

アカウント復旧は設計上の課題として残ります。ユーザーがすべてのデバイスを失った場合、パスキーが排除した脆弱性を再導入しないフォールバックメカニズムが必要です。

WebAuthnは進化を続けています—Level 3が現在の仕様世代です—クロスデバイス認証とエンタープライズ構成証明に関する作業が進行中です。ここで説明した基本は安定したままです。

まとめ

パスキーは認証を「ユーザーが秘密を知っていることを検証する」から「ユーザーが鍵を所有していることを検証する」へとシフトさせます。これはメンタルモデルを変えます:パスワードをハッシュと照合するのではなく、公開鍵に対して暗号署名を検証します。

フロントエンドエンジニアにとって、実用的な意味は明確です:WebAuthn APIの登録と認証のセレモニーを学び、シームレスな検出のための条件付きUIを実装し、ユーザーをパスワードからパスキーへ段階的に移行させるアップグレードパスを設計することです。

よくある質問

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.