Authorization ヘッダーとは
Authorization ヘッダーは、HTTPリクエストで認証情報をサーバに送るためのヘッダーです。
API認証では、次のような形をよく見ます。
GET /api/user HTTP/1.1
Host: api.example.com
Authorization: Bearer xxxxx.yyyyy.zzzzz
これは「このトークンを持っているので、APIアクセスを許可してください」という意味です。
Bearer の形
Bearer Token を送るときは、次の形になります。
Authorization: Bearer <token>
JavaScriptの fetch で書くとこうです。
const token = localStorage.getItem("access_token");
const res = await fetch("https://api.example.com/user", {
headers: {
Authorization: `Bearer ${token}`,
},
});
APIサーバはこのヘッダーを読み、トークンを検証します。
app.get("/api/user", (req, res) => {
const auth = req.headers.authorization;
const token = auth?.replace("Bearer ", "");
const user = verifyToken(token);
res.json({ id: user.id });
});
Cookie 認証との違い
Cookie認証では、ブラウザがCookieを自動で送ります。
GET /mypage HTTP/1.1
Cookie: session_id=abc123
Authorizationヘッダーでは、アプリケーションコードが明示的にトークンをヘッダーへ入れます。
| 観点 | Cookie | Authorization ヘッダー |
|---|---|---|
| 送信者 | ブラウザが自動送信 | アプリが明示的に送信 |
| 代表例 | Cookie: session_id=... | Authorization: Bearer ... |
| CSRF | 起きやすいので対策が必要 | 自動送信されないため性質が違う |
| XSS時 | Cookie値はHttpOnlyで隠せる | トークン保存場所によって盗まれる |
ポイント: Authorization ヘッダー自体が危険なのではありません。問題は、そのヘッダーに入れるトークンをブラウザのどこに保存するかです。
SPA で広まった使い方
React、Vue、Angular などのSPAでは、ブラウザが直接APIを呼びます。そのため、ログイン後に受け取ったトークンをブラウザに保存し、API呼び出し時に Authorization ヘッダーへ入れる実装が広まりました。
// ログイン後
localStorage.setItem("access_token", result.access_token);
// API呼び出し時
fetch("https://api.example.com/orders", {
headers: {
Authorization: `Bearer ${localStorage.getItem("access_token")}`,
},
});
この構成は実装が分かりやすい一方、トークンをJavaScriptから読める場所に置きやすいという課題があります。
BFF 構成での使い方
BFF構成では、ブラウザは直接外部APIを呼びません。
ブラウザはCookieでBFFへアクセスし、BFFがサーバ側で Authorization ヘッダーを付けてAPIを呼びます。
// BFF / サーバ側
const res = await fetch("https://api.example.com/orders", {
headers: {
Authorization: `Bearer ${accessToken}`,
},
});
この場合、accessToken はブラウザに露出しません。サーバ側の環境変数、セッション、シークレットストアなどで管理できます。
よくある誤解
Authorization ヘッダーなら CSRF 対策はいらない?
ブラウザが自動で付けるCookieとは違い、Authorization ヘッダーは通常アプリコードが明示的に付けます。そのため、Cookie認証と同じ形のCSRFとは性質が違います。
ただし、XSSがあればアプリコードの文脈でAPIを呼ばれる可能性があります。CSRFが問題になりにくいから安全、という意味ではありません。
Cookie より Authorization の方が常に安全?
そうではありません。
Authorization ヘッダーに入れるトークンを localStorage に保存すると、XSS時に盗まれやすくなります。HttpOnly Cookie の方がトークン窃取に強い場面もあります。
安全性は、ヘッダーの種類だけでなく、保存場所、送信範囲、有効期限、失効方法で決まります。
まとめ
Authorization ヘッダーは、APIに認証情報を送るためのHTTPヘッダーです。
Authorization: Bearer <token>がよく使われる- Cookieと違い、通常はアプリが明示的に送る
- SPAではブラウザがトークンを持ち、ヘッダーに入れる実装が広まった
- BFF構成では、サーバ側がAPIへ
Authorizationヘッダーを付ける - 危険性は「トークンをどこに保存するか」に大きく左右される
参考リソース
- 公式ドキュメント - Authorization ヘッダーとは何か - API に認証情報を送る方法 を確認するための一次情報