認証のテスト方法:Webアプリケーション向け完全ガイド

認証は、最も深刻なアプリケーションセキュリティの脆弱性が潜む領域であり、自動テストのカバレッジが最も不足しがちな部分でもあります。認証フローの不具合は、単にユーザーを不便にさせるだけでなく、ユーザーデータの漏洩、アカウント乗っ取りの可能性、そして法的責任を生じさせます。
AIコーディングツールを使用するチームにとって、認証テストは特に重要です。AIコーディングエージェントが生成する認証フローは、正常系では正しく動作するものの、エッジケースを見落とすことが多くあります。たとえば、トークンの有効期限切れ処理、ログアウト時のセッション無効化、OAuthのstateパラメータの検証、同時セッションの管理などが挙げられます。
このガイドでは、認証テストで実際に必要なことと、それを体系的に実装する方法について説明します。
認証テストがカバーする範囲
認証テストは、アプリケーションがユーザーを正しく識別し、セッション全体を通じてそのIDを維持できることを検証します。複数の層にわたって確認を行います。
機能的な認証:ログインは機能しているか?ユーザーはログアウトできるか?パスワードリセットは正しく動作するか?
セッション管理:セッションは正しく確立・維持・終了されているか?セッショントークンは安全か?
セキュリティ:アプリケーションは認証攻撃に対して耐性があるか?認可チェックは適切に実施されているか?
エッジケース:トークンが期限切れになった場合はどうなるか?ユーザーが新しいデバイスからログインした場合は?セッションが競合した場合は?
認証テストの完全チェックリスト
ログインフロー
- 有効な認証情報でログインが成功し、セッションが確立される
- 無効な認証情報に対して、どのフィールドが誤っているかを明かさない適切なエラーが返される(「メールアドレスが見つかりません」ではなく「メールアドレスまたはパスワードが無効です」など)
- 空の認証情報が適切に処理される
- 極端に長い入力によってサーバーエラーが発生しない
- 連続したログイン失敗後にレート制限が適用される
- フォームベースのログインにCSRF対策が実施されている
セッション管理
- セッショントークンがHttpOnly Cookie(JavaScriptからアクセス不可)またはメモリ上に保存されている(localStorageは使用しない)
- 設定された無操作タイムアウト後にセッションが期限切れになる
- ログアウト時にセッションが無効化される — ログアウト後に古いトークンを再利用できない
- パスワード変更後にセッションが無効化される
- 同時セッションがポリシーに従って動作する(すべて許可、1件に制限など)
パスワードリセット
- メールアドレスが存在する場合にリセットリンクが送信される(未認証ユーザーに対してメールアドレスの存在有無を明かさない)
- リセットトークンが適切な時間(通常1〜24時間)で期限切れになる
- リセットトークンが使い捨てである — パスワード変更後に再利用できない
- 脆弱なパスワードがわかりやすいエラーメッセージとともに拒否される
OAuth / SSOフロー
- 認可リダイレクトにCSRF防止のためのstateパラメータが使用されている
- コールバック時にstateパラメータが検証される
- コールバックハンドラーが認可コードを交換する前に検証を行う
- OAuth認証の失敗時にサーバーエラーを発生させず、適切に処理される
- アカウント連携(OAuthを既存アカウントに接続する)に認証が必要である
保護されたルートへのアクセス
- すべての保護されたルートが未認証リクエストに対して401を返す(またはログインにリダイレクトする)
- すべての保護されたルートが権限不足の認証済みユーザーに対して403を返す
- 認証チェックがUIだけでなくサーバー側で実行される
- Cookieの操作(セッションCookieのクリア)によって正しく未認証状態になる
認証テストの自動化
TestSpriteを使用した認証フローのテスト
TestSpriteのエージェント型テストエンジンは、要件から認証テストケースを自動生成します。認証フローを定義したPRDを読み込むと、以下のテストケースを生成します:
- 有効な認証情報でのログイン
- 無効な認証情報でのログイン(誤ったパスワード、未登録のメールアドレス、空欄フィールド)
- ログアウトおよびセッション無効化の確認
- 未認証状態での保護されたルートへのアクセス
- OAuthフローの完了および失敗時のハンドリング
エンジンはこれらのテストをクラウドサンドボックス上の実際のアプリケーションに対して実行します。テストユーザーを分離することで、テスト同士が干渉したり、永続的な状態が残ったりしないようにしています。
PlaywrightでAuth(認証)をテストする
スクリプトベースのテストでは、Playwrightに認証状態管理機能が組み込まれています:
これにより、一度認証を行うだけで「authenticated」プロジェクト内のすべてのテストに認証状態を再利用でき、テストごとにログインフローを繰り返す必要がなくなります。
APIレベルの認証テスト
APIレベルで認証をテストするには:
AIが生成しやすい認証バグのテストパターン
AIコーディングエージェントが頻繁に誤るパターンを具体的に紹介します:
リソースエンドポイントにおける認可の欠如。AIはCRUDエンドポイント生成時に認証を正しく要求しますが、認証済みユーザーがそのリソースを所有しているかどうかを検証しないことがあります。例えば、/api/orders/:idはログインを要求しても、認証済みユーザーの注文だけでなく、任意の注文をIDで返してしまう可能性があります。
セッションCookieの設定ミス。AIが生成するセッション設定では、セッションCookieにHttpOnly: trueおよびSecure: trueフラグが省略されることが多く、トークンがJavaScriptからアクセス可能になったり、HTTP経由で送信されたりする危険があります。
OAuthのstateパラメータの省略。AIが生成するOAuthフローでは、プロバイダーへのリダイレクトとコールバック処理は実装されますが、stateパラメータの生成と検証が省略されることが多く、CSRFの脆弱性が生じます。
サーバーサイドのセッションを無効化しないログアウト。AIが生成するログアウト処理では、クライアント側のCookieやlocalStorageはクリアしても、サーバーサイドでセッションを無効化しないことがあります。これにより、トークンは有効期限が切れるまで有効なままになります。
これらはすべて、TestSpriteの認証テストカバレッジをアプリケーションに適用することで検出されます。
TestSpriteで認証テストをセットアップする →