認証と認可
What — 認証は「誰か」、認可は「していいか」の別々の検査
API サーバーはリクエストを2段階で検査する。 **認証（Authentication）**は「このリクエストの主は誰か」をトークンなどの証拠で確かめる工程。 **認可（Authorization）**は「確認できたその主に、この操作を許すか」を権限設定と照らして判定する工程。
順番は必ず認証→認可。誰か分からない相手の権限は調べようがない。
| 答える問い | 落ちたときのコード | 直し方 | |
|---|---|---|---|
| 認証 | お前は誰だ | 401 | トークンを付け直す・再発行する |
| 認可 | それをしていいのか | 403 | 権限やスコープを付与してもらう |
どちらで落ちたかはステータスコードで読み分ける。判定するのは常にサーバー側で、クライアントは選べない。
How — 具体のサービスでの置き場所
認証の証拠はクライアントが毎回リクエストに載せるもの、認可の権限はサービス側に事前に登録されているもの。
| サービス | 認証＝毎回提示する証拠 | 認可＝事前に登録された権限 |
|---|---|---|
| BigQuery | gcloud auth login・サービスアカウントキー | IAM ロール（データ閲覧者 など） |
| Slack API | Bot トークン（xoxb-…） | インストール時に承認した OAuth スコープ |
直す場所も分かれる。401 はコードやコマンド側、403 は管理画面の側の作業になる。
関連
- API — API まわりの地図
- 認証トークンの3層 — 認証の「証拠」を支える OAuth2 / JWT / Bearer の役割分担
- エラーレスポンス — 401/403 以外も含めたエラーの3段読み
- HTTPレスポンスの構造 — ステータスコードが載っている場所
Table of contents