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

Authorization ヘッダーとは

Authorization ヘッダーは、HTTPリクエストで認証情報をサーバに送るためのヘッダーです。

API認証では、次のような形をよく見ます。

GET /api/user HTTP/1.1
Host: api.example.com
Authorization: Bearer xxxxx.yyyyy.zzzzz

これはBearer schemeでcredentialsを提示している形です。提示しただけで本人確認やアクセス許可が完了するわけではなく、APIはトークンの有効性を検証し、対象リソースへの権限を別に判断します。

Bearer の形

Bearer Token を送るときは、次の形になります。

Authorization: Bearer <token>

JavaScriptの fetch で書くとこうです。

const token = getAccessToken();

const res = await fetch("https://api.example.com/user", {
  headers: {
    Authorization: `Bearer ${token}`,
  },
});

APIサーバはこのヘッダーを読み、トークンを検証します。

app.get("/api/user", (req, res) => {
  const credential = readBearerCredential(req.headers.authorization);
  const principal = verifyAccessToken(credential);
  authorizeProfileRead(principal);
  res.json({ id: principal.id });
});

readBearerCredential、verifyAccessToken、authorizeProfileReadは処理を説明するための仮名です。実装では認証基盤やフレームワークの公式ライブラリを使い、scheme、署名またはintrospection、発行者、利用先、期限、scopeなどをAPI仕様に従って検証します。

Cookie 認証との違い

Cookie認証では、ブラウザがCookieを自動で送ります。

GET /mypage HTTP/1.1
Cookie: session_id=abc123

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

ブラウザから送る場合の注意

SPAがAPIを直接呼ぶ構成では、アプリがaccess tokenをAuthorizationヘッダーへ入れます。

// API呼び出し時
fetch("https://api.example.com/orders", {
  headers: {
    Authorization: `Bearer ${accessToken}`,
  },
});

この例は保存方法を示していません。localStorageへ長期保存するなどJavaScriptから読める場所に置くと、XSS時に窃取される可能性があります。保存と更新は認証基盤が推奨する構成に従います。

BFF 構成での使い方

BFF構成では、ブラウザは直接外部APIを呼びません。

ブラウザはCookieでBFFへアクセスし、BFFがサーバ側で Authorization ヘッダーを付けてAPIを呼びます。

// BFF / サーバ側
const res = await fetch("https://api.example.com/orders", {
  headers: {
    Authorization: `Bearer ${accessToken}`,
  },
});

この場合、accessToken はブラウザに露出しません。ユーザーごとのtokenを固定の環境変数へ置くのではなく、BFFのサーバー側セッションなどで、利用者・期限・更新情報と結び付けて管理します。

よくある誤解

Authorization ヘッダーなら CSRF 対策はいらない？

ブラウザが自動で付けるCookieとは違い、Authorization ヘッダーは通常アプリコードが明示的に付けます。そのため、Cookie認証と同じ形のCSRFとは性質が違います。

ただし、XSSがあればアプリコードの文脈でAPIを呼ばれる可能性があります。CSRFが問題になりにくいから安全、という意味ではありません。

Cookie より Authorization の方が常に安全？

そうではありません。

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

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

まとめ

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

• Authorization: Bearer <token> がよく使われる
• Cookieと違い、通常はアプリが明示的に送る
• Bearerを提示しただけでは本人確認・認可は完了しない
• BFF構成では、サーバ側がAPIへ Authorization ヘッダーを付ける
• 危険性は「トークンをどこに保存するか」に大きく左右される

scheme、Basic認証、401と403、WWW-Authenticateまで含む全体像は、canonical記事のAuthorization ヘッダー - Basic / Bearer / API Keyを参照してください。

参考リソース

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

次に読む記事

• Bearer Token とは何か
• JWT を localStorage に置くなと言われる理由
• BFF とは何か

×

PR

×

PR