認証 vs 認可

一番のつまずきを先回り: 認証と認可は別物

この2つは名前が似ていて(どちらもAuthで始まる)混同されますが、まったく別の段階です。空港でたとえます。

• 認証(Authentication) = パスポートを見せて『私は確かに山田太郎です』と本人確認する段階。『あなたは誰か』
• 認可(Authorization) = 搭乗券を見せて『あなたはビジネスクラスのラウンジに入れます』と権限を確認する段階。『あなたは何をしてよいか』

身分が確認できても(認証OK)、ファーストクラスには入れない(認可NG)ことがあります。逆に、誰か分からない人にいきなり権限は出せないので、必ず認証が先、認可が後です。

図を描画中...

『ログインは通るのに、他人の注文が見えてしまう』——これは認証は成功しているが認可が抜けている状態で、OWASP Top 10 の1位 A01 Broken Access Controlそのものです。

代表的な方式と使い分け

方式	何をするか	向いている場面	注意点
セッション(Cookie)	サーバがセッションIDを発行し、状態をサーバ側で保持	同一ドメインのWebアプリ。即ログアウトさせたい時	サーバ側ストアが必要。Cookieに HttpOnly/Secure/SameSite を付ける
JWT	署名付きトークンに情報を入れ、クライアントが持ち歩く。サーバはステートレスで検証	マイクロサービス間、SPA、API	即時失効が困難(短い有効期限+リフレッシュで緩和)。署名はされるが暗号化はされない(中身は読める→機密を入れない)
OAuth 2.0	『認可』を他サービスに委譲する枠組み	『Googleアカウントで連携』、API代理アクセス	OAuth単体は認可であって認証ではない
OIDC	OAuth2.0 の上に『認証』を載せた層。ID Token(JWT)で本人確認	ソーシャルログイン、SSO	本人確認したいなら OAuth単体でなく OIDC を使う
mTLS	クライアントとサーバが互いに証明書を提示して相互認証	サービス間通信、ゼロトラスト	証明書の配布・更新の運用が重い

セッション vs JWT(面接の定番対決)

図を描画中...

• セッション: サーバが『誰がログイン中か』を覚えている。だから『今すぐ強制ログアウト』が確実に効く。ただし複数サーバに分散すると、その状態を共有ストア(Redis等)に置く必要がある。
• JWT: トークン自体に情報が入っているので、サーバは何も覚えなくていい(ステートレス)→水平スケールが楽。ただし一度配ったトークンは有効期限が来るまで止めにくい。だから有効期限を短くし、リフレッシュトークンで更新する設計にします。

つまずきポイント

• 『JWTはどこに保存する?』——localStorage はJavaScriptから読めるので、XSS(後述)を食らうとトークンを盗まれます。HttpOnly Cookie ならJSから読めず安全ですが、今度はCSRF対策(SameSite等)が別途必要になります。一長一短。
• JWTは暗号化ではなく署名。中身(ペイロード)はBase64でデコードすれば誰でも読めます。だからパスワードなどの機密を入れてはいけません。『改ざんされていないことの保証』であって『中身を隠す』ものではない、と理解しましょう。
• OAuth ≠ 認証。OAuthは『このアプリにあなたのGoogleカレンダーを読む許可を与える』という認可の委譲の仕組み。本人確認(認証)が目的なら、その上の層であるOIDCを使います。