APIセキュリティ入門：REST・認証・認可
APIの認可 誰に何を許すか
この回でやること
認証が済んだ後の判定です。誰に何を許すかという、APIの認可の考え方の枠組みを固めます。具体の穴は続く章で扱います。
- 読む 約 7 分
- 最後にクイズ 1 問
このレッスンで学ぶこと
認可は、認証で誰かが決まった相手に、その操作とその対象を許すかを決める判定です。この回は考え方の枠組みまでを固め、具体の穴と直し方は続く章で扱います。
読み終えるころには、tanakaのトークンで他人の番号を送ったとき、サーバーが何を確かめるべきかを言えるようになります。
認証と認可は、別の段
入門編で、認証と認可は別物だと学びました。APIでもこの区別はそのまま効きます。トークンが正しいことは、送り主が誰かを示すだけです。その人に目の前のリクエストを許してよいかは、まだ何も決まっていません。
プレーンテキスト
認証 このトークンは tanaka のものだ → 誰か が決まる
認可 tanaka に /api/orders/1043 を見せてよいか → 何を許すか正しいトークンを持っているからといって、すべてを許してよいわけではありません。ここを混ぜると、「ログインできた人は何でもできる」作りになります。
判定は、リクエストごとに三つを見る
認可の判定は、リクエストが来るたびに次を確かめる作業だと考えると見通しがよくなります。
- 誰か。認証で確定した送り主
- どの操作か。メソッドとエンドポイントの組。この役割にこの操作を許すか
- どの対象か。
/api/orders/1043の1043。この対象はこの人のものか
三つ目まで見るのが要点です。tanakaに注文の閲覧を許していても、それは「tanaka自身の注文」に限る話で、他人の1043まで許した覚えはないはずです。操作の側だけを見て対象を見ないと、ここが抜けます。
画面の出し分けは認可ではない
この章の最初に見たとおり、画面がボタンを出さないことは防御になりません。管理者向けの項目を隠しても、APIは/admin/usersへのリクエストを受けます。認可は必ずサーバー側、信頼境界の内側で行います。
操作の側の抜け（機能単位の認可）と、対象の側の抜け（オブジェクト単位の認可）、そして複数の出店者が混じる作りでの仕切りは、続くAPI認可の章でそれぞれ攻撃と直し方を見ます。ここでは、認可は毎回・サーバーで・操作と対象の両方を、という枠組みを持ち帰ってください。
手を動かすときは、練習用の環境で、tanakaのトークンのまま/api/orders/に他人の番号を入れて送り、返りを見ます。何が起きるかの読み解きは、次の章の最初で扱います。