## What — ログインと引き換えに発行される通行証 Bearer トークンの実体は、**ログイン成功と引き換えにサーバーが発行する、期限付きのただの長い文字列**。 毎回 ID・パスワードを送る代わりに、この文字列をヘッダに載せて「さっきログインした本人です」と示す。 流れは3ステップで固定。 1. ログインする（ID・パスワードを送るのはこの1回だけ） 2. サーバーがトークンを発行して返す（例：`eyJhbGci...`。有効期限つき） 3. 以降のリクエストは毎回ヘッダに載せる。期限が切れたら取り直す ```bash 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）を見直す** ## 関連 - [[API]] — API まわりの地図 - [[JWT]] — トークン文字列の中身の書式 - [[curl]] — `-H` でヘッダを付ける方法 - [[認証トークンの3層]] — OAuth2・Bearer・JWT の関係の全体図