APIでの認可処理 (Authorization)
誰がどのように、システムが持つリソースを取得・変更して良いのかの権限チェックを認可処理といい、システム上では何らかの認可処理が必要となります。
認可処理について、チームによって異なる方法を取っていたり、共通の認識がなかったりすると、チェックの漏れや重複が発生し問題となります。本章では、マイクロサービスアーキテクチャを前提とした、単純な認可処理の方針を定めています。
- 認可処理はどこで行うか? → 該当データのオーナーとなるマイクロサービスの API を境界として、API の実装に認可処理を含める。
- 認可処理はいつ必要があるか? → デフォルトでは行うが、行わないことを API 単位で表明して認可処理をスキップすることもできる。
全ての API のエンドポイントは、以下の二つのいずれかに分類できます。
exposable…呼び出し元のユーザーに基づいたデータの取得・変更の権限チェックが行われているもの(デフォルト)unexposable…そのような制御が行われておらず、任意のデータの取得・変更が行えるもの ... internal
exposable な API は暗黙的に「呼び出し元のユーザー」という入力をインターフェイスに持ちます。例えば、プロフィール情報の取得 API であれば、つながりなどの公開範囲設定に応じて返すプロフィール情報が変わるように実装します。
unexposable な API は日時のバッチ処理からの呼び出し(システム内部での処理)や管理画面など、入力内容も含めて API 呼び出し全体が信頼できると仮定できる前提で用意するものです。
これらの分類は、直接的な認可処理に限らず、API の責務全体を定義します。例えば、ActiveRecord で生成される updated_at はシステムの内部情報なので、仕様として公開することを意図していない限り exposable な API で返すべきではありません。