画面のある一般的な Web アプリで、認証の実装として妥当なのはどれですか。
画面のあるアプリは標準のセッション認証、SPA やモバイルからのAPIは Sanctum です。パスワードは Hash 経由で bcrypt ハッシュとして保存し、平文も可逆な暗号も使いません。
面接官が見ているのは使ったものを説明できるか。仕組みを理解しているか。
よくある答えと、面談でどう見られるか
- 標準のセッション認証を使い、パスワードは Hash ファサードでハッシュ化して保存する
その通りです。認証成功時にセッションIDが再生成されるので、セッション固定攻撃も標準で防がれています。 - パスワードを暗号化して保存し、ログイン時に復号して比較する
復号できる形で保存してはいけません。漏洩時に全パスワードが読めます。ハッシュ（不可逆）を使います。 - 認証を自前で実装し、セッションも独自に管理する
車輪の再発明であり、かつセキュリティ事故の温床です。「なぜ標準を使わなかったのか」を必ず突かれます。 - JWT を発行してブラウザの localStorage に保存する
SPA では選択肢になりますが、画面のあるアプリでは不要に複雑です。localStorage は XSS で読めるので、Cookie より不利な面もあります。
面接官は何を見ているか
- 使った仕組み（セッション / Sanctum / Passport / 自前）を挙げた
- なぜそれを選んだかを言えた
- パスワードの保存方法（ハッシュ）に触れた
模範解答
画面のあるアプリなら標準のセッション認証、SPA やモバイルからのAPIなら Sanctum を使います。パスワードは Hash ファサード経由で bcrypt ハッシュとして保存し、平文もリバーシブルな暗号も使いません。認証成功時にセッションIDが再生成されるので、セッション固定攻撃も標準で防がれています。
ここからどう深掘りされるか
この問いに答えられた場合、面談は次の質問に進みます。
観点をすべて押さえられた場合
Sanctum と Passport はどう使い分けますか。一部しか触れられなかった場合
セッション認証とトークン認証は、何が違いますか。