Authorization ヘッダーとは何か - API に認証情報を送る方法

入門 | 8分 で読める | 2026.06.14

公式ドキュメント

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を自動で送ります。

GET /mypage HTTP/1.1
Cookie: session_id=abc123

Authorizationヘッダーでは、アプリケーションコードが明示的にトークンをヘッダーへ入れます。

観点CookieAuthorization ヘッダー
送信者ブラウザが自動送信アプリが明示的に送信
代表例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が問題になりにくいから安全、という意味ではありません。

そうではありません。

Authorization ヘッダーに入れるトークンを localStorage に保存すると、XSS時に盗まれやすくなります。HttpOnly Cookie の方がトークン窃取に強い場面もあります。

安全性は、ヘッダーの種類だけでなく、保存場所、送信範囲、有効期限、失効方法で決まります。

まとめ

Authorization ヘッダーは、APIに認証情報を送るためのHTTPヘッダーです。

  • Authorization: Bearer <token> がよく使われる
  • Cookieと違い、通常はアプリが明示的に送る
  • SPAではブラウザがトークンを持ち、ヘッダーに入れる実装が広まった
  • BFF構成では、サーバ側がAPIへ Authorization ヘッダーを付ける
  • 危険性は「トークンをどこに保存するか」に大きく左右される

参考リソース

  • 公式ドキュメント - Authorization ヘッダーとは何か - API に認証情報を送る方法 を確認するための一次情報

次に読む記事

← 一覧に戻る
PR
PR
PR
PR