【ITニュース解説】Do not construct authentication policy inside a login helper

システム開発において、ユーザーがサービスにログインする機能は非常に重要である。ログイン処理は、単に正しいパスワードが入力されたかどうかを検証するだけでなく、その裏側で多くのセキュリティや利便性に関わるルール（ポリシー）が適用されている。例えば、アカウントが有効であるか、メールアドレスの確認は済んでいるか、パスワードは最新のセキュリティ基準でハッシュ化されているか、セッション（ログイン状態）の管理はどうするか、といったことだ。これらのルールを総称して「認証ポリシー」と呼ぶ。

多くのアプリケーションフレームワーク（Webアプリケーション開発を助ける土台となるソフトウェア）には、これらの複雑な認証ポリシーを一元的に管理するための仕組みが備わっている。通常、「コンテナ」と呼ばれる場所で、認証マネージャーなどのサービスが設定され、アプリケーション全体で共通のルールが適用されるようになっている。しかし、ある特定の場所、例えばログイン処理の一部を担当する「ログインヘルパー」のような小さな部品が、このフレームワークが用意した認証マネージャーを使わず、自分で新しい認証マネージャーを直接作ってしまうと、大きな問題が発生することがある。

ニュース記事では、この問題を「ログインヘルパーが正しいパスワードを検証できたとしても、認証ポリシーの一部を迂回してしまう」と指摘している。これは、new AuthManager(...) のように、アプリケーションコードが認証マネージャーを直接インスタンス化する際に起こる。このようにローカルで作成されたオブジェクトは、パスワードなどの資格情報にアクセスできるかもしれないが、コンテナで設定されている「アカウントの有効性チェック」「パスワードのアップグレードサービス」「セッションルール」「プリンシパルファクトリ（ユーザーの権限などを管理する仕組み）」といった重要なポリシーを自動的に継承できない。結果として、アプリケーション全体では「メールアドレスが未検証のアカウントはログインできない」というポリシーが設定されていても、ログインヘルパーが直接作成した認証マネージャーにはそのポリシーが適用されず、未検証アカウントでもログインできてしまう、といったセキュリティ上の穴が生まれてしまう可能性があるのだ。

認証マネージャーは単なるパスワード検証ユーティリティではない。それは、アカウントのアクティブ状態、メールアドレスの検証要件、資格情報の移行や再ハッシュ化、セッションの生成とローテーション、セッションの取り消し、機密性の高い資格情報フィールドへの監査付きアクセスなど、様々なポリシーを担っている。Anokiiというシステムの事例では、以前、ログインヘルパーの中で$auth = new AuthManager($internalFields);のように新しい認証マネージャーを直接作っていた。このローカルなオブジェクトは資格情報を読み込むことはできたが、コンテナに紐付けられた認証マネージャーに付随するサービスを維持できなかった。この問題を解決するため、Anokiiはログインヘルパーがフレームワークから設定済みの認証マネージャーを受け取るように変更した。この変更は見た目の問題ではなく、アプリケーションのアーキテクチャに関わる根本的な違いを生み出し、ヘルパーがアプリケーションの他の部分と同じ認証ポリシーを使用するようになった。

この解決策の核心は、「依存性注入（Dependency Injection）」と呼ばれる設計パターンにある。アプリケーションの起動時に、サービスプロバイダ（サービスを提供する役割を担う部分）が、コンテナからAuthManagerのインスタンスを解決し、それをログインコントローラやワークスペースコントローラに渡す。これにより、ログイン、ログアウト、現在のパスワード確認といった全ての機能が、常に同じ設定済みの認証サービスを使用する。この設計により、アプリケーション全体で単一の、一貫した認証ポリシーの境界を確立できる。もし認証マネージャーが利用できない場合、アプリケーションは起動時（組み立て時）にエラーを発生させ、問題を明確にする。これにより、アプリケーションが脆弱な状態に陥ることを防ぎ、問題が早期に発見できるようになる。

また、ニュース記事では「認証（Authentication）」と「認可（Authorization）」の明確な分離の重要性も強調している。認証は「あなたは誰か」を検証するプロセスであり、認可は「あなたは何ができるか」を判断するプロセスだ。これらはしばしば同じアカウント情報を使うが、同じ権限で処理すべきではない。Anokiiの事例では、機密性の高いアカウントメンテナンス用の内部フィールドリーダーは、資格情報の検証や機密フィールドへの制御されたアクセスをサポートするが、これはHTTPコントローラが「現在のユーザーがダッシュボードを開いて良いか」を判断するための適切な抽象化ではない。修理後、ダッシュボードへのアクセス許可は、フレームワークの「プリンシパルファクトリ」から取得した「変更不可能なアカウントプリンシパル」を使って判断されるようになった。これにより、「資格情報の検証と保護された認証フィールドの読み取り」と「HTTPアカウントの権限決定」という二つの異なる懸念事項が明確に分離され、それぞれの役割が明確になった。

認可に関する問題が起きた際のエラー処理についても重要な指摘がある。プリンシパルファクトリのような認可サービスが欠落している場合、それは単なるアクセス拒否（「このアカウントには権限がありません」）ではなく、アプリケーション自体の構成エラーである。このような状況で一般的な「403 Forbidden」（アクセス禁止）を返してしまうと、「アカウントに要求された権限がない場合」と「アプリケーションが必要なサービスをマウントできていないため権限を評価できない場合」という二つの異なる状態の区別が曖昧になってしまう。そのため、後者の構成エラーの場合は「LogicException」のような例外をスローしてアプリケーションを停止させるべきだ。これにより、本番環境で問題が発生した際に、その原因を正確に診断できるようになる。ユーザーに「アクセスできません」と伝えるべきでないのは、アプリケーションがそもそもアクセス権限の判断すらできていない場合である。

このような複雑な認証と認可のポリシーが正しく機能していることを確認するためには、単に「正しいパスワードでログインできるか」だけでなく、より広範囲な統合テストが必要になる。記事では、以下のような多くのシナリオをカバーするテストの例を挙げている。正しいパスワードでのダッシュボード表示、セッションへのアカウントIDと世代の記録、HTTPプリンシパルによる必要な権限の付与、間違ったパスワードの拒否、無効なアカウントの拒否、権限のないアカウントの拒否、未検証アカウントの拒否、繰り返し失敗した場合の制限（スロットリング）、匿名リクエストのログインページへのリダイレクト、古いセッション世代の無効化、ログイン時のセッションIDのローテーション、ログアウト時のセッション破棄などだ。さらに、メンテナンス専用の機能がHTTPフローで誤って使われていないかを検証するテストも加えることで、設計上の境界が守られていることを証明できる。

最後に、認証コードをレビューする際のポイントとして、new AuthManager(...)、new AuthorizationService(...)、new SessionManager(...) のように、ポリシーを持つサービスが直接構築されていないかを確認することを推奨している。アプリケーションが既にコンテナ内でこれらのサービスを設定しているにもかかわらず、直接オブジェクトを作成している場合は疑わしいと考えるべきだ。その場合、ローカルで構築されたオブジェクトが、コンテナで設定された認証ポリシーのうち何を失ってしまうのかを理解し、実際に設定された適格性チェック、権限解決、セッションローテーション、取り消し、スロットリング、ログアウトといった全ての機能が、実際のHTTPパスを通してカバーされる統合テストを作成することが重要である。認証ポリシーはアプリケーション全体の境界で管理されるべきであり、ログインヘルパーのような個別の部品が、独自の、より小さなポリシー境界を密かに作ってしまうことは避けるべきだ。