What Is Passwordless Authentication?

What Is Passwordless Authentication? の翻訳です。

パスワードレス認証（Passwordless authentication）とは、パスワードを要求せずにユーザーの本人性を確認する認証方式です。共有秘密（パスワード）の代わりに、あなたが 持っているもの（デバイスやワンタイムコード）または あなた自身（指紋、Face ID など）に依存します。

開発者にとって、パスワードレス認証はログインフローを簡素化し、パスワードの保管・管理に起因する攻撃面を減らすのに役立ちます。パスワードリセット、アカウントロック、侵害監視といった運用負担も取り除けます。さらに、パスワード疲れを減らし、問い合わせ対応を減らすことでユーザー体験（UX）も改善します。

Verizon の 2025 年版 Data Breach Investigations Report（DBIR）によると、クレデンシャル悪用は侵害における初期侵入ベクターの最上位であり、全体の 22% を占めます。

モダンな実装では、FIDO2、WebAuthn、デバイスベースの暗号技術といった標準を用いて、パスワードを不要にする安全で使いやすい認証を提供します。

なぜパスワードレス認証が重要なのか

パスワードはセキュリティ上の弱点と運用コストを生み、ユーザーと開発チームの双方に影響します。適応型ハッシュ（Argon2、bcrypt、PBKDF2）による安全な保管、侵害監視、アカウントロックポリシーが必要です。パスワード関連の問い合わせは、ヘルプデスクのチケット増加につながりがちです。

ユーザーは複数サイトでパスワードを使い回すことがよくあります。使い回しはクレデンシャルスタッフィング攻撃を可能にします。これは、ある侵害で漏えいした認証情報を別サービスへ使い回して侵入する攻撃です。

パスワードレス認証は、次の 3 つの根本課題に対処します。

セキュリティ： パスワードはフィッシング、クレデンシャルスタッフィング、リプレイ攻撃、データベース侵害に弱いです。攻撃者はソーシャルエンジニアリング、マルウェア、DB の侵害などでパスワードを盗めます。WebAuthn のような非対称暗号を用いるパスワードレス方式は、共有秘密を不要にすることで、これらの「共有秘密由来」の攻撃ベクターを排除できます。WebAuthn では秘密鍵がデバイスから送信されないため、リモートでのクレデンシャル窃取は実質的に不可能になります。
UX： パスワードリセットは重要なユーザージャーニー中の離脱を招き、大量のサポート依頼を発生させ得ます。ユーザーはパスワードを忘れがちで、ログイン失敗が増え、結果として問い合わせが増えます。パスワードレス認証なら、デバイスの一般的な機能（Face ID、指紋）やシンプルな検証（ワンタイムコード）で認証でき、摩擦を減らしコンバージョンを改善できます。
開発者の運用負担： パスワード保管には、適切なワークファクターでの安全なハッシュ、ソルト生成、侵害監視が必要です。パスワードリセットにはメール基盤、トークン管理、有効期限処理が必要です。アカウントロックには失敗回数の追跡と解除の仕組みが必要です。パスワードレス認証はこれらの実装要件を排除または大幅に削減し、開発者がコア機能に集中できるようにします。

パスワードレス認証の仕組み

パスワードレス認証は、おおむね次のパターンに従います。

本人性の証明： ユーザーは、所持要素（例：デバイス、ハードウェアキー、メールアドレス、電話番号）または生体要素（例：生体認証）をコントロールしていることを示します。
サーバー側検証： 認証サーバーは、その証明を暗号署名（非対称方式）または時間制限付きコード（OTP 方式）で検証します。
トークン発行： ユーザーが認証を完了すると、クライアントは PKCE を使って トークンエンドポイント で認可コードを交換します。トークンエンドポイントは、ID トークン（アイデンティティのクレームを含む）と アクセストークン（API の認可用）を返します。トークンはフロントチャネル経由では返されません。
セッション確立： アプリケーションは HttpOnly なセキュア Cookie またはサーバー側セッションストレージでセッションを確立します。

非対称方式（WebAuthn、パスキー）は、クレデンシャルのリモート持ち出しから保護します。一方で、Email OTP、SMS、TOTP は、攻撃者が傍受・侵害できる「秘密」を露出させる可能性があります。

開発者が現在よく使うパスワードレス方式

WebAuthn（FIDO2）

WebAuthn はブラウザやデバイスに非対称鍵ペアを生成させます。秘密鍵はデバイスに残り、送信されません。サーバーは公開鍵のみを保存します。認証時は、サーバーがチャレンジを発行し、デバイスが秘密鍵で署名して「秘密鍵の所持」を証明します（秘密鍵自体は露出しません）。

WebAuthn は、主要ブラウザと OS でネイティブ統合されており、強い暗号保証を提供します。ユーザーは組み込みの生体センサーやハードウェアセキュリティキーで認証します。

パスキー（Passkeys）

パスキーは、プラットフォーム提供の認証情報マネージャーでユーザーのデバイスエコシステムに同期される WebAuthn クレデンシャルです。ユーザーは生体認証またはデバイス PIN で認証し、QR コードをスキャンして別デバイスから認証することもできます。

パスキーは WebAuthn の暗号強度を保ちながら、同期によって使いやすさを改善します。同期機構により、ユーザーのクラウドアカウントが侵害された場合の攻撃面は広がり得ますが、基盤となる暗号保護は維持されます。

ワンタイムパスワード（OTP）

Email OTP： メールで検証コードを受け取ります。安全性はユーザーのメールアカウントの安全性に依存します。サインアップのコンバージョンやアカウントリカバリを重視するコンシューマー向けに適しています。
SMS OTP： SIM スワップ（番号乗っ取り）やメッセージ傍受の影響を受けやすいです。高い保証が必要な場面では、代替手段がない場合を除き避けるべきです。
TOTP（Time-Based One-Time Passwords）： 認証アプリがローカルでコードを生成するため、傍受リスクは減ります。しかし TOTP はリアルタイムのフィッシングや中継（MITM）攻撃に弱いままです。攻撃者がユーザーに悪性サイトで現在の TOTP を入力させれば、約 30 秒の有効期間内にそのコードを正規サービスへ即座に中継できます。TOTP は一部のコンプライアンス要件では MFA を満たし得ますが、フィッシング耐性はありません。

マジックリンク

メールでワンタイムの認証リンクを受け取り、クリックすると認証が完了します。UX はシンプルですが、メールの安全性に依存し、フィッシングへの防御は限定的です。厳格な時間制限（多くは 5〜15 分）と単回使用を前提とするコンシューマー向けに適しています。

プッシュ通知

認証アプリが登録済みデバイスへ承認プロンプトを送ります。ユーザーはコード入力ではなく「Approve / Deny」を選びます。TOTP より UX は良い一方で、攻撃者が大量に承認要求を送りつけ、ユーザーが誤って承認することを狙う MFA Fatigue（疲労）攻撃に弱いです。ユーザートレーニングと異常検知を併用できるエンタープライズ環境に適します。

Passwordless / Passkeys / MFA の関係を理解する

パスワードレス認証は複数方式の総称で、パスキーはその中の特定実装、MFA はセキュリティ要件を指します。次の表はそれらの関係を示します。

概念	定義	例
パスワードレス認証	パスワードなしで行うあらゆる認証方式	WebAuthn、パスキー、マジックリンク、TOTP、Email OTP
パスキー	組み込みのユーザー確認を伴う同期型 WebAuthn クレデンシャル	Face ID または指紋による認証
MFA	異なるカテゴリから 2 つ以上の独立要素	パスワード + TOTP、またはパスキー単独（所持 + 生体）

パスキーは、単一のフィッシング耐性オーセンティケータとして、所持要素（秘密鍵を持つデバイス）と ユーザー確認要素（生体または PIN）を 1 ステップに統合することで、従来の MFA 要件を一般に満たす、または上回ります。

パスワードレスな WebAuthn フローの流れ

WebAuthn は、非対称暗号を用いる最も安全な現代的パスワードレス実装であり、クレデンシャル窃取の排除に役立ちます。

登録（Registration）： アプリケーション（WebAuthn の relying party として）が、ユーザーのオーセンティケータへクレデンシャル作成を要求します。オーセンティケータはアプリケーションのドメインに固有の非対称鍵ペアを生成します。サーバーは公開鍵、クレデンシャル ID、メタデータ（例：コンプライアンス要件がある場合のアテステーション）を保存します。秘密鍵はオーセンティケータから出ません。プラットフォームオーセンティケータでは、ユーザーが秘密鍵を手動でエクスポートできません。デバイスに紐づく分離が WebAuthn の根本的な安全性保証です。
認証（Authentication）： サーバーは一意の暗号学的チャレンジ（通常はランダム値）を生成します。オーセンティケータはデバイス内に安全に保存された秘密鍵でそのチャレンジに署名します。サーバーは保存している公開鍵で署名を検証します。オーセンティケータは署名をアプリケーションのドメインへ暗号学的にバインドするため、署名済みレスポンスは他サイトでは無効になります。このドメインバインディングにより、ユーザーが悪性サイトで認証しようとしても、署名レスポンスは正規ドメインでしか使えず、フィッシングを防げます。
トークン発行（Token Issuance）： 認証成功後、IdP は（PKCE を用いた OpenID Connect / OAuth 2.0 などの安全なプロトコルで）トークンを発行します。通常、アイデンティティクレーム用の ID トークンと、API 認可用のアクセストークンが含まれます。
セッション確立（Session Establishment）： アプリケーションは Secure / SameSite フラグ付きの HttpOnly Cookie、またはサーバー側セッションストレージでセッションを確立します。XSS 脆弱性のため、トークンを localStorage / sessionStorage に保存してはいけません。セッション固定化攻撃を防ぐため、認証成功直後に新しいセッション識別子を発行してください。

開発者向けセキュリティ考慮事項

フィッシング耐性： OTP やマジックリンクよりも、WebAuthn やパスキーを優先してください。非対称暗号はドメインバインドされたチャレンジにより、フィッシング耐性を本質的に備えます。
トークン保管： HttpOnly Cookie（Secure / SameSite 付き）またはバックエンドのセッションストレージを使ってください。localStorage と sessionStorage は避けてください。
PKCE： すべてのクライアント種別で Authorization Code Flow + PKCE を使い、認可コードの盗聴・奪取を防いでください。
レート制限： OTP エンドポイントにはレート制限を適用してください。6 桁コードは 100 万通りしかありません。IP・ユーザー・エンドポイント・時間窓など複数軸で制限を設計してください。
セッションセキュリティ： 認証成功後にセッション ID を再生成し、セッション固定化攻撃を防いでください。アイドルタイムアウト（30 分）と絶対期限（8〜24 時間）を実装してください。
デバイス紛失時の復旧： 安全な再登録手段を用意してください。パスキーなら同期済み別デバイスから認証可能です。非同期クレデンシャルなら、検証済みメールによる復旧、管理者復旧、信頼済みデバイス承認などを使います。
アテステーション： ハードウェア検証が規制要件で求められる場合にのみ利用してください（例：FIPS 認証）。アテステーションは複雑性を増し、採用率を下げる可能性があります。

どのパスワードレス方式を使うべきか

方式	向いている用途	セキュリティ上のトレードオフ
パスキー	コンシューマーアプリ、モダンブラウザ、頻繁な認証	同期機構はクラウドアカウントの安全性に依存
WebAuthn（非同期）	エンタープライズ、管理端末、最高レベルの要件	新しいデバイスでの認証が容易ではない
Email OTP	低摩擦サインアップ、アカウント復旧	メールアカウントの安全性に依存
TOTP	中程度の安全性、許容できるセットアップ負荷	リアルタイムフィッシングに弱い
SMS OTP	フォールバック用途のみ	SIM スワップ、傍受

よくある実装ミス

TOTP をフィッシング耐性とみなす：攻撃者はプロキシ攻撃で TOTP をリアルタイムに盗めます。
レート制限が不十分：適切な多次元の制限がないと、6 桁コードは総当たりされ得ます。
クレデンシャル保管の誤り：公開鍵のみを保管してください。秘密鍵をバックアップ・手動同期してはいけません。
復旧フローが弱い：必要になる前に安全な再登録を用意し、サポート担当と一緒にテストしてください。
セッションセキュリティ不足：認証後にセッション ID を再生成してください。固定化されたセッション ID を維持すると乗っ取られ得ます。

パスワードレス認証 FAQ

パスワードレス認証はパスワードより安全ですか？

正しく実装されていれば Yes です。パスワードレス方式はフィッシング、クレデンシャルスタッフィング、DB 侵害への露出を減らします。ただし安全性は実装次第です。Email OTP は、適切なポリシーがある強固なパスワードより必ずしも安全とは限りません。

パスキーはパスワードレス認証の一種ですか？

はい。パスキーは、プラットフォーム提供の安全な同期機構でデバイス間同期される WebAuthn クレデンシャルで、WebAuthn の安全性と高い利便性を両立します。

パスワードレス認証は MFA 要件を満たせますか？

はい。異なるカテゴリの独立要素が 2 つ含まれる場合に満たせます。パスキーは、デバイス所持と生体／PIN のユーザー確認を組み合わせることで MFA を満たします。TOTP は MFA の 第二要素 になり得ますが、単独では MFA ではありません。

ユーザーがデバイスを紛失したらどうしますか？

安全な再登録手段を提供してください。パスキーなら同期済みの別デバイスから認証できます。非同期クレデンシャルの場合は、厳格な検証を伴う検証済みメール復旧、管理者復旧、信頼済みデバイス承認などを用います。

API はユーザーを直接認証しますか？

いいえ。モダンなアイデンティティアーキテクチャでは、IdP が認証を担いトークンを発行します。API はアクセストークンを検証して認可を強制します。API は認証セレモニーには参加しません。

エンタープライズ環境でもパスワードレスは使えますか？

はい。多くの企業は WebAuthn を SSO やデバイス管理と組み合わせています。エンタープライズでは、管理端末に紐づく非同期 WebAuthn クレデンシャルと、リスクベースのシグナルを好むケースが多いです。

Take the Next Step in Identity Management

パスワードレス認証は、アプリケーションにおける最も一般的なセキュリティギャップを埋めるうえで重要です。WebAuthn やパスキーのようなフィッシング耐性方式を実装するには、堅牢なアイデンティティ基盤が必要になります。

Auth0 のようなサービスを使うと、パスワードレス認証を簡素化でき、開発者はコア機能の開発に集中できます。IAM（Identity and Access Management）に関する追加トピックは Intro to IAM シリーズをご覧ください。

Learn more

これらの資料は一般的な情報提供のみを目的としています。セキュリティ、プライバシー、コンプライアンス、またはビジネスに関する助言は、専門家へ相談してください。本資料の情報のみに依拠しないでください。