マイクロサービスアーキテクチャにおける認証（Authentication）と認可（Authorization）

このシリーズでは、マイクロサービスアーキテクチャにおいて認証（Authentication）と認可（Authorization）を実装する方法を扱う。
今回の記事では、全体概要とあわせて単一アプリケーション（モノリシック）との違いを説明する。

---

例示アプリケーション: RealGuard.io

RealGuard.ioは商用セキュリティシステムのプラットフォームで、セキュリティ機器の制御とアラームを管理する。
ユーザーは販売会社、顧客企業、監視サービス提供事業者に所属しており、それぞれ異なるアクセス権限を持つ。

---

モノリシックアーキテクチャでの認証と認可

モノリシック構造は1つのアプリケーションとデータベースで構成され、認証はセッショントークンで実装される。
認可は次のような構造で行われる:

isAllowed(user, operation, resource)  

例:

isAllowed(user, "disarm", SecuritySystem(ID))  

---

認可モデル4種類

1. RBAC: ロールベースアクセス制御 – ユーザーに付与されたロールで権限を決定
2. ReBAC: リレーションシップベースアクセス制御 – ユーザーとリソースの関係でアクセスを決定
3. ABAC: 属性ベースアクセス制御 – ユーザー、リソース、環境の属性で決定
4. 混合モデル: 上記3つを組み合わせて複合的なポリシーを実装可能

---

認可の例とロール別権限

Operation	Required Role
getAlarmSystem()	SecuritySystemViewer
armSystem()	SecuritySystemArmer
disarmSystem()	SecuritySystemDisarmer
cancelSystem()	SecuritySystemAlarmCanceller

特定のロールに加えて、勤務時間の制約（ABAC）や通知リストに含まれているかどうかなど、追加条件が適用されることもある。

---

認可検証の場所

1. ネットワークインフラ: サービスメッシュ、ingress controller などで簡単な権限チェックが可能
2. REST API ハンドラー: リクエストレベルの coarse-grained な認可処理
3. ドメインロジック: 複雑な条件ベースの認可処理
4. DBアクセス層: SQL内部で認可フィルタリングを実施（大規模処理に効果的）

---

UIでの認可

UIは認可を強制することはできないが、ユーザー権限に応じてボタンや機能を表示したり無効化したりすることで、UXを最適化できる。

---

マイクロサービスアーキテクチャでの認証

BFF（Backend For Frontend）がログインとセッション管理を担当する。
各マイクロサービスは独立して実行されるため、ユーザー情報にセッションから直接アクセスできず、JWTなどのトークンでユーザー情報を渡す必要がある。

---

マイクロサービスアーキテクチャでの認可

BFF → SecurityService の順にリクエストが渡され、次の3つの場所で認可検証が可能である:

1. BFF: セッション情報をもとに、パスやメソッドに応じたリクエストレベル認可が可能
2. Inter-service Network: サービスメッシュがJWTベースの認可の一部を実行
3. 各サービス内部: ドメインロジックとDBアクセス層で認可を実行

---

分散認可の難しさ

各サービスは必要な情報を自前のDBに持っていないため、認可のために他サービスのAPI呼び出しが必要になることがある。
これをJWTで解決しようとする方法もあるが、トークンサイズと検証コストが問題になる。

---

まとめ

• 認証はユーザーの本人確認、認可は権限の判定
• isAllowed(user, operation, resource) パターンが認可の核心
• RBAC、ReBAC、ABAC の3つの認可モデルを組み合わせて実装
• モノリシックでは単一DBアクセスで認可が容易だが
• マイクロサービスでは認可に必要なデータが分散しており、実装はより複雑になる