Sanctum と Passport はどう使い分けますか。
分岐点は第三者アプリに自社アカウントでのアクセスを許可するかどうかです。許可するなら OAuth2 が要るので Passport、自社の SPA やモバイルだけなら Sanctum で足ります。
面接官が見ているのは「名前は知っている」で止まっていないか。
これは「画面のある一般的な Web アプリで、認証の実装として妥当なのはどれですか。」への追撃質問です。
よくある答えと、面談でどう見られるか
- 第三者アプリにアクセスを許可するなら Passport（OAuth2）、自社SPA・モバイルなら Sanctum
分岐点はまさにそこです。要らないのに Passport を入れると、運用する概念が無駄に増えます。 - Passport の方が新しいので、常に Passport を選ぶ
新旧ではなく用途で選びます。Sanctum の方が後発かつ軽量です。 - Sanctum は開発用、Passport は本番用
どちらも本番で使います。役割が違います。 - 両方入れて併用するのが標準的な構成
通常は併用しません。認証の入口が二重になり、事故のもとです。
面接官は何を見ているか
- Passport が OAuth2 のフルスタック実装だと言えた
- Sanctum は軽量なトークン／SPA向けだと言えた
- 「サードパーティにアクセスを許可するか」が分岐点だと指摘できた
模範解答
分岐点は「第三者のアプリに自社アカウントでのアクセスを許可するか」です。許可するなら OAuth2 が要るので Passport。認可サーバーとしての機能が一式入っています。自社のSPAやモバイルアプリだけなら Sanctum で十分で、こちらはSPA向けのCookieベース認証とシンプルなAPIトークンだけの軽い作りです。公式も「OAuth2 がどうしても必要なら Passport、SPA・モバイル・APIトークンなら Sanctum」という切り分けを書いていて、Sanctum は OAuth2 をサポートしないと明言しています。要らないのに Passport を入れると、運用する概念が無駄に増えます。
なお Sanctum の2機能は独立していて、片方だけ使って構いません。SPA 認証の方はトークンを一切使わず、Laravel の web ガードのセッションCookieをそのまま使うので、CSRF 保護が効き、XSS でトークンを抜かれる経路もありません。