パスワードレス認証とは、パスワードを必要とせずにユーザーの本人確認を行う認証方式です。共有シークレットの代わりに、所持しているもの（デバイスやワンタイムコード）や本人そのもの（指紋やFace IDなど）を利用します。

開発者にとっては、パスワードレス認証によってログインフローを簡素化できるうえ、パスワードの保存や管理に伴う攻撃対象領域を縮小するのに役立ちます。また、パスワードのリセット対応、アカウントロックアウトの解除、認証情報漏えいの監視といった運用上の負担も軽減できます。さらに、パスワード疲れを減らし、サポートへの問い合わせを削減することで、ユーザーエクスペリエンス（UX）の向上にもつながります。

Verizonの「2025年度データ漏洩/侵害調査報告書（DBIR）」によると、認証情報の悪用は依然として侵害の最も一般的な初期侵入経路であり、全体の22%を占めています。

最新の実装では、FIDO2、WebAuthn、デバイスベースの暗号化技術といった標準規格を活用することで、パスワードを不要にしながら、セキュリティと使いやすさを両立した認証を実現できます。

パスワードは、ユーザーと開発チームの双方にとって、セキュリティ上の脆弱性や運用負荷の原因となります。パスワードを使用する場合は、適応型ハッシュアルゴリズム（Argon2、bcrypt、PBKDF2）を用いたセキュアな保管、漏えいの監視、アカウントロックポリシーの実装が必要です。また、パスワードに関する問い合わせは、ヘルプデスクへの問い合わせ件数を増加させる大きな要因でもあります。

ユーザーは複数のサイトで同じパスワードを使い回すことが少なくありません。パスワードの使い回しは、情報漏えいによって流出した認証情報を別のサービスへの不正アクセスに悪用する、クレデンシャルスタッフィング攻撃を可能にします。

パスワードレス認証で、以下に挙げる3つの主な課題を解決できます。

• セキュリティ：パスワードは、フィッシング、クレデンシャルスタッフィング、リプレイ攻撃、データベースからの情報漏洩に対して脆弱です。攻撃者は、ソーシャルエンジニアリング、マルウェア、データベースの侵害などを通じてパスワードを窃取できるからです。パスワードレス認証、特にWebAuthnのような非対称暗号化を利用する認証方式では、共有シークレットそのものが不要になるため、共有シークレットに起因する攻撃ベクトルを排除できます。WebAuthnでは秘密鍵がデバイス外へ送信されることがないため、認証情報のリモート窃取は事実上不可能です。
• UX：パスワードのリセットは、ユーザーが重要な操作を途中で断念する原因となるほか、大量のサポート問い合わせを発生させる可能性があります。ユーザーはパスワードを忘れることが多く、ログイン失敗やサポート依頼の増加につながります。パスワードレス認証では、使い慣れたデバイス機能（Face IDや指紋認証）や、簡単な認証方法（ワンタイムコード）を利用できるため、ユーザーの負担を軽減してコンバージョン率を向上させることができます。
• 開発者の負担：パスワードの保存と管理には、適切な計算負荷を設定したセキュアなハッシュ化の実装、ソルトの生成、漏えいの監視が必要です。また、パスワードリセット機能には、Eメール基盤、トークン管理、有効期限の管理が求められます。さらに、アカウントロックアウトポリシーを実現するには、ログイン失敗回数の追跡やロック解除の仕組みも必要です。パスワードレス認証を利用すれば、こうした実装要件が不要になるか大幅に削減できるため、開発者はアプリケーション本来の機能開発に注力できるようになります。

パスワードレス認証は、一般的に次のような流れで実行されます。

1. 本人確認：ユーザーは、所持要素（デバイス、ハードウェアキー、Eメールアドレス、電話番号など）の管理権、または生体要素（生体認証など）を提示することで、本人確認を行います。
2. サーバー側での検証：認証サーバーは、暗号署名（非対称方式）や、一定時間のみ有効なコード（OTP方式）を使用して、その証明を検証します。
3. トークンの発行：ユーザーが認証を完了すると、クライアントはPKCEを使用して、認可コードをトークンエンドポイントに提示し、トークンと引き換えます。トークンエンドポイントは、ユーザーのアイデンティティクレームを含むIDトークンと、APIへのアクセスを認可するためのアクセストークンを返します。これらのトークンがフロントチャネル経由で返されることはありません。
4. セッションの確立：アプリケーションは、セキュアなHttpOnly Cookieまたはサーバー側のセッションストレージを使用してセッションを確立します。

非対称方式（WebAuthn、パスキー）は、認証情報がリモート環境へ不正に持ち出されることを防ぎます。一方、EメールOTP、SMSコード、TOTPではシークレット情報を使用するため、攻撃者による傍受や侵害の対象となる可能性があります。

WebAuthn（FIDO2）

WebAuthnでは、ブラウザやデバイスが非対称の鍵ペアを生成します。秘密鍵はデバイス内に保持され、外部に送信されることはありません。サーバーには公開鍵のみが保存されます。認証時には、サーバーがチャレンジを発行し、デバイスが秘密鍵を使ってそのチャレンジに署名することで、鍵を公開せずに正当な所持者であることを証明します。

WebAuthnは、最新のブラウザやオペレーティングシステムにネイティブに統合されており、強力な暗号学的保証を提供します。ユーザーは、デバイスに搭載された生体認証センサーやハードウェアセキュリティキーを使用して認証を行います。

パスキー

パスキーは、プラットフォームが提供する認証情報マネージャーを利用して、ユーザーの複数のデバイス間で同期されるWebAuthn認証情報です。ユーザーは、生体認証やデバイスのPINを使用して認証を行い、QRコードをスキャンすることで別のデバイスからも認証できます。

パスキーは、WebAuthnの暗号学的なセキュリティを維持しながら、認証情報の同期によって利便性を向上させています。ユーザーのアカウントが侵害された場合、同期の仕組みによって攻撃対象領域が広がる可能性がありますが、基盤となる暗号学的な保護機能は維持されます。

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

• EメールOTP：ユーザーはEメールで認証コードを受け取ります。セキュリティはユーザーのEメールアカウントの保護状況によって変わります。サインアップ時のコンバージョン率やアカウント復旧フローを重視する消費者アプリケーションに適しています。
• SMS OTP：SIMスワップ攻撃やメッセージの傍受に対して脆弱です。代替手段がない場合を除き、高い保証レベルが求められる場面での利用は避けるべきです。
• 時間ベースのワンタイムパスワード（TOTP）：認証アプリがローカルでコードを生成するため、コードが傍受されるリスクはありません。ただし、TOTPはリアルタイムのフィッシング攻撃やリレー攻撃（中間者攻撃）には依然として脆弱です。攻撃者がユーザーをだまして悪意のあるサイトに現在有効なTOTPコードを入力させることができれば、そのコードを約30秒の有効期間内に正規のサービスへ即座に中継できます。TOTPは一部のコンプライアンスシナリオではMFAの要件を満たしますが、フィッシング耐性があるわけではありません。

マジックリンク

ユーザーは1回だけ使用できる認証リンクをEメールで受け取ります。そのリンクをクリックすると認証が完了します。マジックリンクはユーザーエクスペリエンスを簡素化できますが、Eメールアカウントのセキュリティに依存し、フィッシングに対する保護も限定的です。厳格な有効期限（通常は5～15分）と1回限りの使用制約を設けたうえで、消費者向けアプリケーションに導入するのに適しています。

通知をプッシュ

認証アプリが登録済みデバイスに承認リクエストを送信します。ユーザーはコードを入力する代わりに、「承認」または「拒否」を選択します。プッシュ通知による承認は、TOTPよりも優れたUXを提供します。ただし、攻撃者がプッシュリクエストを送り付け、ユーザーが誤って承認することを狙う多要素認証（MFA）疲れ攻撃に対しては脆弱なままです。ユーザー教育や異常検知が求められるエンタープライズ環境に適しています。

パスワードレス認証には複数の認証方式が含まれます。パスキーはその具体的な実装の1つであり、MFAはセキュリティ要件を表す概念です。これら概念の関係を以下の表に示します。

コンセプト	定義	例
パスワードレス認証	パスワードを使用しないあらゆる認証方式	WebAuthn、パスキー、マジックリンク、TOTP、EメールOTP
パスキー	ユーザー検証機能を備え、複数のデバイス間で同期されるWebAuthn認証情報	Face IDや指紋による認証
MFA （Multi-Factor Authentication）	異なるカテゴリに属する2つ以上の独立した認証要素を使用する認証方式	パスワード + TOTP、またはパスキー単体（所持要素 + 生体要素）

パスキーは、フィッシング耐性のある単一の認証手段として、一般的に従来のMFAに求められるセキュリティ要件を満たす、あるいはそれを上回るレベルのセキュリティを提供します。これは、所持要素（秘密鍵を保持するデバイス）とユーザー検証要素（生体認証またはPIN）を1回の認証操作の中で組み合わせているためです。

WebAuthnは、現在最もセキュアなパスワードレス認証の実装方式で、認証情報の窃取を防ぐために非対称暗号化を利用しています。

• 登録：アプリケーション（WebAuthnのリライングパーティとして動作）は、ユーザーの認証器に認証情報の作成を要求します。認証器は、そのアプリケーションのドメイン専用に非対称鍵のペアを生成します。サーバーには、公開鍵、認証情報ID、メタデータ（コンプライアンス要件で必要な場合は認証器のアテステーション情報など）が保存されます。秘密鍵が認証器のデバイス外へ出ることはありません。また、ユーザーがプラットフォーム認証器から秘密鍵を手動でエクスポートすることもできません。このデバイスに紐付いた分離構造が、WebAuthnの根本的なセキュリティ保証を支えています。
• 認証：サーバーは、一意の暗号学的チャレンジ（通常はランダムな値）を生成します。認証器は、デバイス内にセキュアに保存された秘密鍵を使用して、このチャレンジに署名します。サーバーは、その認証情報に対応する、保存していた公開鍵を使用して署名を検証します。認証器は、署名をアプリケーションのドメインに暗号学的にバインドするため、その署名付きレスポンスは他のサイトでは無効になります。このドメインへのバインドによって、フィッシング攻撃を防止できます。たとえユーザーが悪意のあるサイトで認証を試みた場合でも、署名付きレスポンスは正規のドメインでしか機能しないためです。
• トークンの発行：認証が成功すると、アイデンティティプロバイダーはトークンを発行します（通常はPKCEを使用したOpenID ConnectやOAuth 2.0などのセキュアなプロトコルを利用）。発行されるトークンには、一般的にユーザーのアイデンティティクレームを含むIDトークンと、APIの認可に使用するアクセストークンが含まれます。
• セッションの確立：アプリケーションは、Secure属性とSameSite属性が設定されたセキュアなHttpOnly Cookie、またはサーバー側のセッションストレージを使用してセッションを確立します。クロスサイトスクリプティング（XSS）の脆弱性があるため、トークンをlocalStorageやsessionStorageに保存しないでください。また、セッション固定化攻撃を防ぐため、認証成功直後に新しいセッションIDを生成する必要があります。

• フィッシング耐性：OTPやマジックリンクよりも、WebAuthnやパスキーを優先して採用してください。非対称暗号化では、ドメインに紐付いたチャレンジを利用するため、本質的にフィッシング耐性があります。
• トークンの保存：Secure属性とSameSite属性が設定されたHttpOnly Cookieか、バックエンドのセッションストレージを使用してください。localStorageやsessionStorageの使用は避けてください。
• PKCE：認可コードの盗聴を防ぐため、すべてのクライアントタイプでPKCEを使用したAuthorization Code Flowを採用してください。
• レート制限：OTPエンドポイントにはレート制限を適用してください。6桁のコードの組み合わせは100万通りしかありません。IPアドレス、ユーザー、エンドポイント、時間枠ごとに制限を設ける必要があります。
• セッションセキュリティ：セッション固定化攻撃を防ぐため、認証の成功後にセッションIDを再生成してください。また、アイドルタイムアウト（30分）と絶対有効期限（8～24時間）を設定してください。
• デバイス紛失時の復旧：セキュアな再登録手段を提供してください。パスキーの場合、ユーザーは同期済みの別のデバイスから認証できます。同期されない認証情報の場合は、確認済みEメールアドレスによる復旧、管理者による復旧、または信頼済みデバイスによる承認などを利用します。
• アテステーション：認証器のアテステーションは、ハードウェア検証が規制要件として求められる場合（FIPS認証など）にのみ利用してください。アテステーションを導入すると複雑になり、普及の妨げになる可能性があります。

方法	適した用途	セキュリティ上のトレードオフ
パスキー	消費者アプリ、最新のブラウザ、認証頻度の高いユースケース	同期の仕組みは、クラウドアカウントのセキュリティに依存する
WebAuthn（同期なし）	エンタープライズアプリ、管理対象デバイス、最高レベルのセキュリティが求められる場合	ユーザーは新しいデバイスから簡単に認証できない
EメールOTP	ユーザーの負担を最小限に抑えたサインアップ、アカウント回復	セキュリティはEメールアカウントの保護状況に依存する
TOTP	セキュリティは中程度で、利便性とのバランスを重視する場合	リアルタイムのフィッシング攻撃に対して脆弱
SMS OTP	代替手段としてのみ利用	SIMスワッピング攻撃やメッセージの傍受に対して脆弱

• TOTPにフィッシング耐性があると考えること：TOTPコードは、プロキシ攻撃を利用したリアルタイムのフィッシングによって攻撃者に窃取される可能性があります。
• 不適切なレート制限：複数の軸で適切なレート制限を設けなければ、攻撃者は6桁のコードを総当たり攻撃で容易に突破することができます。
• 認証情報の不適切な保存：保存するのは公開鍵のみにしてください。秘密鍵をバックアップしたり、手動で同期したりしてはいけません。
• 脆弱な復旧フロー：必要になってからではなく、事前にセキュアな再登録手段を用意しておいてください。サポート担当者を含めてテストを実施してください。
• 不十分なセッションセキュリティ：認証後はセッションIDを再生成してください。再生成が行われない場合、セッションIDを固定した攻撃者によってセッションが乗っ取られる可能性があります。

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

はい。適切に実装されていれば、パスワードレス認証でフィッシング、クレデンシャルスタッフィング、データベース侵害によるリスクを軽減できます。ただし、セキュリティは実装次第です。たとえば、適切なポリシーが適用された強力なパスワードと比較した場合、EメールOTPのほうが本質的に安全であるとは限りません。

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

はい。パスキーはWebAuthn認証情報の一種であり、プラットフォームが提供するセキュアな同期機能を利用して複数のデバイス間で同期されるため、WebAuthnのセキュリティと高い利便性を両立しています。

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

はい。2つの独立した認証要素が使用される場合は満たせます。パスキーは、デバイスの所持要素と、生体認証またはデバイスPINを組み合わせることで、MFAの要件を満たします。TOTPはMFAの第2要素として利用できますが、単独ではMFAにはなりません。

ユーザーがデバイスを紛失した場合はどうなりますか？

セキュアな再登録手段を提供してください。パスキーの場合、ユーザーは同期済みの別のデバイスから認証できます。同期されない認証情報の場合は、厳格な本人確認を伴う確認済みEメールアドレスによる復旧、管理者による復旧、または信頼済みデバイスによる承認などを利用します。

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

いいえ。最新のアイデンティティアーキテクチャでは、認証はアイデンティティプロバイダーが担当し、その後トークンを発行します。APIはアクセストークンを検証し、認可を実施します。API自体は認証プロセスには関与しません。

パスワードレス認証はエンタープライズ環境でも機能しますか？

はい。多くの企業では、WebAuthnをシングルサインオン（SSO）やデバイス管理機能と組み合わせて活用しています。エンタープライズ向けのユースケースでは多くの場合、管理対象デバイスに紐付けられた同期なしのWebAuthn認証情報と、リスクベースのシグナルを組み合わせる方法が好まれます。

パスワードレス認証は、アプリケーションにおける最も一般的なセキュリティ上の弱点を解消するうえで重要な役割を果たします。WebAuthnやパスキーのようなフィッシング耐性のある方式を導入するには、堅牢なアイデンティティプラットフォームが必要です。

Auth0のようなサービスを利用することで、パスワードレス認証を簡素化できるため、開発者はアプリケーション本来の機能開発に集中できるようになります。アイデンティティとアクセス管理に関連するその他のトピックについては、「IAM入門」シリーズをご覧ください。

詳細を見る

これらの資料は一般的な情報提供のみを目的としています。本資料の利用者は、自身の責任において、自身の専門アドバイザーからセキュリティ、プライバシー、コンプライアンス、またはビジネスに関する助言を得るものとし、本資料に記載された情報のみに依存すべきではありません。