認証・認可は『間違えると致命的な領域』
認証（誰か）と認可（何ができるか）は、自前実装が最も難しく、間違えると致命的なセキュリティ事故に繋がる領域です。本記事では、認証・認可の実装パターンを編集部の視点で整理します。個別のセキュリティ判断は専門家にご相談ください。セキュリティエンジニアへの転身ガイド もご参考に。
認証と認可の違い
(1) 認証（Authentication）：あなたは誰か。(2) 認可（Authorization）：あなたは何ができるか。(3) 順序：認証→認可。(4) 混同しやすい：別々に設計する。(5) 独立した責務：別のシステムにすることも。REST API設計 もご参考に。
主要な認証方式
(1) セッション認証：サーバー側で状態保持。(2) JWT（JSON Web Token）：ステートレスなトークン。(3) OAuth 2.0：第三者アクセス許可の枠組み。(4) OpenID Connect（OIDC）：OAuth 上の認証層。(5) パスキー（WebAuthn）：パスワードレス。Supabase活用ガイド もご参考に。
セッション認証の基本
(1) ログイン後にセッション ID を発行。(2) Cookie に保存：HttpOnly・Secure・SameSite。(3) サーバー側で状態管理：DB・Redis 等。(4) ログアウト時に破棄。(5) シンプルで安全：迷ったらセッション認証。「JWT のほうが今っぽい」は誤解で、セッション認証は今でも有力な選択肢です。
JWT の使い所と注意点
(1) ステートレス：サーバー側で状態保持しない。(2) 署名で改竄検出：HMAC・RS256 等。(3) 失効の難しさ：発行後の取り消しが難しい。(4) localStorage に置かない：XSS リスク。(5) 適切な短い有効期限：リフレッシュトークンと組み合わせ。JWT は便利ですが「失効できない」が大きな弱点で、セッション認証より安全とは限りません。
OAuth 2.0 の基本
(1) 第三者アクセス許可：「○○として API にアクセスを許可」。(2) 主要フロー：Authorization Code Flow（PKCE）。(3) 暗黙的フローは非推奨：Code Flow を使う。(4) スコープ：アクセス範囲の制限。(5) リフレッシュトークン：再発行用。APIマネタイズ戦略 もご参考に。
OpenID Connect（OIDC）
(1) OAuth 2.0 上の認証層：「誰か」を扱う。(2) ID Token：ユーザー情報を含む JWT。(3) 主要 IdP：Google・Microsoft・Auth0 等。(4) 標準化された実装：ライブラリが充実。(5) SSO（シングルサインオン）：複数サービスで共通ログイン。IT・Web業界の職種完全マップ もご参考に。
認可の実装パターン
(1) RBAC（ロールベース）：role でアクセス制御。(2) ABAC（属性ベース）：属性で柔軟に制御。(3) ReBAC（関係ベース）：所有関係で制御。(4) ポリシーエンジン：OPA・Cedar 等。(5) サービス分離：認可サービスを別に。規模が大きくなったら認可サービスを別に切り出すのが現代的です。
セキュリティの落とし穴
(1) JWT 検証の漏れ：none アルゴリズム攻撃。(2) セッション固定攻撃：ログイン後の ID 再生成漏れ。(3) CSRF 対策の漏れ：SameSite Cookie・CSRF トークン。(4) 過度な権限付与：最小権限の原則。(5) パスワードの平文保存：bcrypt 等でハッシュ。セキュリティエンジニアへの転身ガイド もご参考に。
マネージドサービスの活用
(1) Auth0/Okta/Clerk/Supabase Auth：認証 SaaS。(2) NextAuth.js/Lucia Auth：フレームワーク統合。(3) 自前実装の正当化：規制・特殊要件がある場合のみ。(4) SaaS 利用のメリット：脆弱性対応・スケール。(5) ベンダーロックイン：抽象化層で軽減。「認証は自前で書かない」が現代の鉄則です。SaaS MVPの作り方 もご参考に。
失敗しがちなパターン
(1) 自前実装：脆弱性を作り込む。(2) JWT を万能視：失効問題を見落とす。(3) OAuth と認証の混同：OAuth は認可の枠組み。(4) パスワード規則の弱さ：強度不足。(5) 多要素認証なし：単要素は危険。対策は、(1)マネージド利用、(2)JWT の限界を理解、(3)OIDC を使う、(4)強い規則、(5)MFA 必須化、です。転職戦略完全ハブ もご活用ください。