🐷
API の認証・認可が適切に実装されているか？
API の認証・認可が適切に実装されているか？
背景・概要
APIは外部・内部とのインターフェースとなるため、誰が・どの範囲で・何をできるかを正確に制御する必要がある
特にB2BのSaaSでは、テナントスコープの認証・認可が極めて重要になる
トークン（JWTやOIDC）方式が一般的で、ユーザー属性・スコープの検証が要点
例
- OAuth2.0 + OpenID Connect によるユーザー認証
- JWTにsub（ユーザーID）やtenant_idを含め、各APIでアクセススコープを検証
- 管理者向けと一般ユーザー向けでアクセスポリシーを明確に分離
よくある失敗例
- トークンの期限が無限になっており、使い回しで乗っ取りリスク
- トークンはチェックするが、スコープ（リソースの対象）が未チェック
- 認証エラーと権限エラーのステータスコードが混在していて脆弱性診断に引っかかる
FAQ
Q. 認証と認可って何が違うの？
A. 認証＝誰かを確かめる、認可＝何ができるか制御する。両方必要
Q. API GatewayやIDaaSで全部済む？
A. 一部は可能だが、ビジネスロジックに近い認可（例：他テナント越境チェック）はアプリ側で担保すべきかな
関連観点
📘 本記事は SaaS設計レビュー観点チェックリスト（2025年版） の一部です。
設計観点カテゴリ：🌐 API・権限・セキュリティ
レベル：DeepDive（実装・運用レベル）
推奨読者：設計リーダー / SRE / インフラ設計者 / レビュー担当者
🧭 他の観点もまとめて読みたい方はこちらからどうぞ。
Discussion