Bearer
What — ログインと引き換えに発行される通行証
Bearer トークンの実体は、ログイン成功と引き換えにサーバーが発行する、期限付きのただの長い文字列。 毎回 ID・パスワードを送る代わりに、この文字列をヘッダに載せて「さっきログインした本人です」と示す。
流れは3ステップで固定。
- ログインする（ID・パスワードを送るのはこの1回だけ）
- サーバーがトークンを発行して返す（例：
eyJhbGci...。有効期限つき） - 以降のリクエストは毎回ヘッダに載せる。期限が切れたら取り直す
curl -H "Authorization: Bearer eyJhbGci..." https://api.github.com/user
Bearer は「持参人」の意味で、サーバー側のルールは 「この文字列を持ってきた人を本人とみなす」。 持ち主かどうかの照合はしない。 盗まれるとそのまま成りすまされるので、通信は必ず HTTPS にする。 有効期限が数分〜数時間と短いのも、盗まれたときの被害を期限までで打ち切るため。
APIキーとの使い分け
前提：どちらで名乗るかは叩く側が選ぶのではなく、API 側がドキュメント（Authentication 節）で指定している。 自分で選ぶ場面が来るのは、API を作る側になったとき。
読み分けの軸は「発行の引き金がログインかどうか」。
| APIキー | Bearer トークン | |
|---|---|---|
| 発行される場面 | 開発者が管理画面で1回発行 | ユーザーがログインするたび自動発行 |
| 誰の身分証か | アプリ・スクリプト | ログインした本人 |
| 期限 | 基本なし（漏れたら手で失効） | 数分〜数時間で自動失効 |
| 典型例 | YouTube Data API・OpenAI API | 「GitHub でログイン」した後の操作 |
cron やスクリプトが人間不在で黙々と叩くなら APIキー、ログインしたユーザー本人として操作するなら Bearer、と場面で読み分ける。
落とし穴 — 401 と 403 で打つ手が違う
- 401 — トークンを出していない・期限切れ・書式ミス → 取り直す
- 403 — トークンは有効だが、その操作の権限がない → 権限（scope）を見直す
関連
Table of contents