JavaScript | Web API：通信・ネットワーク系 － 認証ヘッダ

認証ヘッダは「あなたが誰なのか」をサーバーに伝えるための“身分証”

まずイメージからいきます。
認証ヘッダ（Authentication Header）は、「このリクエストは誰として送っているのか」 をサーバーに伝えるための“身分証”です。

ログイン済みのユーザーとしてアクセスしたい
特定の権限を持ったユーザーとして API を叩きたい
外部サービスの API キーを使ってアクセスしたい

こういった場面で、認証ヘッダが使われます。

そして、認証ヘッダの中心にあるのが Authorization ヘッダ です。
ここを理解すると、API の世界が一気にクリアになります。

Authorization ヘッダの基本構造

「方式 + 資格情報」のセットで送る

Authorization ヘッダは、基本的に次の形をしています。

Authorization: <方式> <資格情報>

例えば、よく見るのがこれです。

Authorization: Bearer abc123token

これは、

方式 → Bearer（ベアラー認証）
資格情報 → abc123token（アクセストークン）

という意味です。

サーバーはこのヘッダを見て、
「このトークンを持っているユーザーは誰か？」
「このユーザーはこの操作をしていいのか？」
を判断します。

Bearer トークン方式が最もよく使われる理由

Bearer トークンとは「持っているだけで権利がある」タイプの鍵

Bearer（ベアラー）という言葉は「持っている人」という意味です。
つまり、Bearer トークンは 「持っているだけで、そのユーザーとして扱われる鍵」 です。

API の世界では、ログイン後にサーバーがアクセストークンを発行し、
それを Authorization ヘッダに付けて API を叩く、という流れが一般的です。

const response = await fetch("https://api.example.com/me", {
  headers: {
    Authorization: "Bearer YOUR_ACCESS_TOKEN",
  },
});

const response = await fetch("https://api.example.com/me", {
  headers: {
    Authorization: "Bearer YOUR_ACCESS_TOKEN",
  },
});

サーバー側はこのトークンを検証し、
ユーザー情報を返したり、操作を許可したりします。

重要：Bearer トークンは「盗まれたら終わり」

Bearer トークンは、
持っているだけで本人として扱われる ため、
盗まれたらそのまま悪用されます。

だからこそ、

どこに保存するか
どのタイミングで送るか
HTTPS で送っているか

といったセキュリティの意識が非常に重要になります。

特に、localStorage に長期保存するのは危険です。
XSS が起きた瞬間に盗まれる可能性があるためです。

Basic 認証は「ユーザー名とパスワードを Base64 で送る」

Basic 認証の仕組み

Basic 認証は、次のようなヘッダを送ります。

Authorization: Basic dXNlcjpwYXNz

dXNlcjpwYXNz は、user:pass を Base64 でエンコードしたものです。

JavaScript で作るとこうなります。

const token = btoa("user:pass");

fetch("https://example.com/secret", {
  headers: {
    Authorization: `Basic ${token}`,
  },
});

const token = btoa("user:pass");

fetch("https://example.com/secret", {
  headers: {
    Authorization: `Basic ${token}`,
  },
});

ただし、Basic 認証はセキュリティ的に弱いので、
HTTPS で使うのが絶対条件です。

Basic 認証は「簡易的な保護」に向いている

Basic 認証は、

社内ツール
簡易的な管理画面
テスト用 API

などでよく使われます。

ただし、パスワードをそのまま送る方式なので、
本番の認証方式としてはあまり使われません。

API キーを Authorization ヘッダで送るケース

外部サービスの API でよくあるパターン

外部サービス（地図 API、翻訳 API、決済 API など）では、
API キーを Authorization ヘッダに載せることがあります。

例えば、

Authorization: Api-Key YOUR_API_KEY

あるいは、

Authorization: Token YOUR_API_KEY

など、サービスごとに形式が違います。

JavaScript ではこう書きます。

fetch("https://api.example.com/data", {
  headers: {
    Authorization: "Api-Key 1234567890abcdef",
  },
});

fetch("https://api.example.com/data", {
  headers: {
    Authorization: "Api-Key 1234567890abcdef",
  },
});

API キーも Bearer トークンと同じく、
盗まれたら悪用される ので取り扱いには注意が必要です。

fetch と認証ヘッダの組み合わせ

認証ヘッダを付けて API を叩く基本形

async function fetchUser(token) {
  const response = await fetch("https://api.example.com/me", {
    headers: {
      Authorization: `Bearer ${token}`,
      Accept: "application/json",
    },
  });

  if (!response.ok) {
    throw new Error(`HTTP error: ${response.status}`);
  }

  return response.json();
}

async function fetchUser(token) {
  const response = await fetch("https://api.example.com/me", {
    headers: {
      Authorization: `Bearer ${token}`,
      Accept: "application/json",
    },
  });

  if (!response.ok) {
    throw new Error(`HTTP error: ${response.status}`);
  }

  return response.json();
}

ここで重要なのは、

Authorization ヘッダは「headers」オブジェクトに入れる
トークンは文字列として埋め込む
HTTPS で通信する

という点です。

クロスオリジンで認証ヘッダを送る場合の注意点

別オリジンにリクエストする場合、
認証ヘッダを送るには CORS の設定が必要です。

サーバー側が、

Access-Control-Allow-Headers: Authorization
Access-Control-Allow-Origin: https://your-frontend.com

などを返さないと、ブラウザがブロックします。

つまり、
認証ヘッダを使うときは、CORS とセットで考える必要がある
ということです。

認証ヘッダを扱うときのセキュリティの基本

トークンは localStorage に保存しないほうが安全

localStorage は JavaScript から自由に読めるため、
XSS が起きた瞬間にトークンが盗まれます。

より安全な方法としては、

HttpOnly Cookie に保存する
短命のアクセストークンを使う
リフレッシュトークンは HttpOnly Cookie に入れる

などがあります。

初心者のうちは、
「トークンは localStorage に置くと危険」という感覚だけ持っておけば十分です。

Authorization ヘッダは「送るべきときだけ送る」

認証ヘッダは、
必要な API にだけ付けるべきです。

全リクエストに付けると、
意図しない場所にトークンが漏れる可能性があります。

特に、外部サイトへのリクエストに誤って付けると危険です。

初心者として認証ヘッダで本当に押さえておきたいこと

Authorization ヘッダは「あなたが誰なのか」をサーバーに伝えるための身分証
Bearer トークンは最も一般的で、持っているだけで本人扱いされる
Basic 認証は簡易的だが、パスワードを送る方式なので HTTPS が必須
API キーも Authorization ヘッダで送ることが多い
認証ヘッダを送るときは CORS の設定が必要になる場合がある
トークンは盗まれたら終わりなので、保存場所と扱い方に注意する

認証ヘッダは、
「API と安全に会話するための鍵」
と言ってもいい存在です。

もし次に学ぶ余裕があれば、
「Bearer トークンとリフレッシュトークンの仕組み」
「Cookie ベースの認証との違い」
などに進むと、さらに理解が深まります。