## 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レスポンスの構造]] — ステータスコードが載っている場所