ベアラートークンとは？

ほとんどすべての現代アプリのログインや API リクエストの裏側では、静かに仕事をする「ベアラートークン」が存在します。それに気づくことはあまりありませんが、サービスを連携したり、サインインしたり、クラウドからデータを取得するとき、毎回使われています。

このガイドでは、ベアラートークンの役割や重要性、安全な扱い方について説明します。

ベアラートークンとは？#

ベアラートークンとは、一般的に文字列データの一種であり、持ち主が特定のリソースへアクセスできることを証明するものです。重要なのは、そのトークンを「所持する人（bearer）」が追加の証明なしで利用できる点です。

航空券（搭乗券）を例に考えてみましょう。手にした後は、再度身分証明を求められることなく、保安検査を通過し飛行機に搭乗できます。同じように、ベアラートークンを使えば、アプリは毎回身元確認をせずに「API に搭乗」できるのです。

例えば、スマートフォンの Spotify にログインした後は、毎回パスワードを入力しなくても曲を再生できます。アプリはベアラートークンを保存し、Spotify のサーバーに「このリクエストは認可されたユーザーから来ている」と伝えます。

ベアラートークンの仕組み#

ベアラートークンの流れは以下のようなステップに分けられます：

1. ユーザーがログイン

   例えば、銀行アプリにユーザー名とパスワードでログインします。

2. 認証サーバーがトークンを発行

   本人確認ができると、認証サーバーがベアラートークンを返します。以下のような文字列です：

3. クライアントがトークンを利用

   「残高照会」や「送金」ボタンを押すたびに、アプリはトークンを HTTP リクエストヘッダーに含めます：

4. API がトークンを検証

   サーバーはトークンの有効性、期限切れでないか、どの権限を持つか（例：read:balanceやwrite:transfer）などを確認します。

5. アクセス許可

   すべてのチェックを通過すると、サーバーがリクエスト情報を返します。

このモデルは GitHub API など多くのサービスで使われており、開発者は繰り返し認証情報を入力するのではなくベアラートークンで認証を行います。

ベアラートークンが普及した理由#

ベアラートークンは、Web セキュリティの課題を解決したことから利用が広がりました。サーバーベースのセッション管理と違い、トークン自体にリクエスト検証に必要な情報が含まれているため、各ユーザーのセッション情報をサーバー側で保存する必要がありません。

例えば、マイクロサービスアーキテクチャ―（多数のサービスが相互通信する形）では、中央集権的なセッション管理は複雑で非効率です。ベアラートークンなら、各サービスが独立してリクエストを検証でき、システムが軽量かつスケーラブルになります。

例として、Slack の API はベアラートークンに大きく依存しています。Slack ボットを構築すると、すべてのユーザーのセッションを管理せずとも、そのトークンで必要なエンドポイントを呼び出せます。

ベアラートークンの中身#

多くのベアラートークンは JWT（JSON Web Token） 形式で実装されています。これらはユーザー情報や権限などが含まれるエンコードされた文字列です。

サンプル JWT をデコードすると：

この意味は：

• sub：サブジェクト（ユーザー固有のID）
• name：ユーザー名
• iat：発行タイムスタンプ
• exp：有効期限（トークンが失効する時刻）
• scope：許可された権限。ここではメッセージの読み書きが可能。

実際、Jane のトークンに read:messages だけが含まれていれば、アプリはメッセージを取得できても新規送信はできません。

ベアラートークンとアクセストークンの違い#

ベアラートークンと**アクセストークン** は混同しやすい用語ですが、実は密接だが異なる概念です。

アクセストークン：『許可証』#

アクセストークンは、ユーザーが特定リソースにアクセスする権限をもつことを示す認証情報です。以下の属性があります：

• ユーザーが誰か（ID）
• 何を許可されているか（スコープ/権限）
• トークンの有効期限

学校の『許可証』のようなもので、先生（API）に「この生徒は遠足（リソースアクセス）に行ける」と伝えます。

たとえば、クラウドストレージサービスにログインすると、read:files のスコープを持つアクセストークンが発行され、それが「このユーザーはファイルの読み取りはできるが削除はできない」と伝えます。

ベアラートークン：『配布フォーマット』#

ベアラートークンは、アクセストークンの一種です。bearer とは「トークンの使用方法」を示し、提示した人が追加の証明なくリソースへアクセスできます。

要するに：

• すべてのベアラートークンはアクセストークンです。
• しかし、すべてのアクセストークンがベアラートークンである必要はありません。

他にもホルダー・オブ・キー・トークン（holder-of-key tokens） などが存在し、これらはトークンに加えて秘密鍵の所持証明が求められます。ベアラートークンはこの追加ステップが不要なため、シンプルですが盗まれた場合のリスクも高くなります。

実際の例#

• アクセストークン（一般）：署名付きデータであり、クライアントが秘密鍵も保有していることの証明が求められる場合があります。
• ベアラートークン（特定）：現在ほとんどの OAuth 2.0 実装ではベアラーフォーマットのアクセストークンが発行されます。例えば Google OAuth は Authorization: Bearer <token> ヘッダーで使うアクセストークンを返します。

つまり、OAuth の解説などで「アクセストークン」と出てきた場合、特に明記されてなければほぼベアラートークンを指します。

他のトークン種との比較#

さらに明確にするため、ベアラートークンとよく使われる他のタイプを比べてみましょう：

• リフレッシュトークン（refresh token）：アクセストークンの有効期限切れ時に新規発行を受けるために使います。リフレッシュトークンは通常ベアラートークンではありません、なぜなら直接 API ではなく認可サーバーとの安全な受け渡し専用だからです。
• IDトークン（ID token）：認証目的（誰であるかの証明）で使われます。メールアドレスや名前、ユーザーIDなどの情報を持ちます。システムによっては ID トークンもベアラー型の場合がありますが、アクセストークンとは用途が違います。
• API キー（API key）：アプリケーションの識別用で、よりシンプルな認証手段です。多くの場合、API キーも「所持者が使えるベアラートークン的な」挙動をします。

ベアラートークンとアクセストークンは対立概念ではなく、関係性は：

• 多くのアクセストークンがベアラートークンである
• ベアラートークンは「トークンの使い方」を表す（提示すればアクセスできる）
• 実用上「アクセストークン」と「ベアラートークン」はほぼ同じ意味で使われますが、厳密には強調点が違います

JWT アクセストークン（ベアラートークン）の検証方法#

ベアラートークンの検証は、API を無許可アクセスから防ぐ最前線です。トークンが JWT の場合、検証はローカルで高速に行えます。API は毎回発行元へ問い合わせせず、トークンだけで確認できます。

検証の基本的な考え方#

1. トークンを解析する
2. 署名を発行者の公開鍵で検証する
3. issuer, audience, 有効期限, not-before などの基本クレームを確認する
4. 独自ルール（スコープ、役割、トークンタイプ等）を適用する
5. 機密性の高い操作では失効リストやセッション状態も参照する

検証チェックリスト（JWT）#

API ゲートウェイやミドルウェア構築時の手順書として活用してください。

• 署名

  ヘッダー指定のアルゴリズム（例：RS256）で署名を検証。発行者の JWKS エンドポイントから「kid」で鍵を選んでキャッシュします。

• Issuer（iss）

  トークンの iss 値と信頼できる発行元 URL が完全一致し、スキームも適切か確認します。

• Audience（aud）

  トークンが自分の API 向けであることを確かめます。https://api.example.com のような識別子や論理名で比較します。

• Expiration（exp）と Not-Before（nbf）

  期限切れトークンは拒否。nbf を考慮し開始前は使えないように。時計のズレは30～60秒程度許容。

• Issued-At（iat）

  デバッグや厳密運用で古すぎるトークン拒否時に有用。

• トークンタイプ

  必ずアクセストークンであることを確認。一部プロバイダーは typ: "at+jwt" などを付与。API アクセスに ID トークンを受け入れないこと。

• スコープ/権限

  scope や roles などプロバイダー固有クレームを参照し、最小権限を各エンドポイントで強制。

• Subject（sub）

  安定したユーザーまたはクライアント ID。リソースの紐付けや監査に活用。

• リプレイ・失効（推奨）

  機密操作では jti の denylist やセッション記録を短期参照して、ログアウトや侵害疑い後の防止策に。

ベアラートークンのセキュリティリスク#

ベアラートークンは「持っている人が使える」ため、家の鍵のように厳重に扱う必要があります。誰かに盗まれれば、鍵を交換するまでドアを自由に開けられてしまいます。

主なリスクは：

• トークンの窃盗 — トークンを localStorage などに保存しておくと、悪意ある拡張機能などから盗まれる恐れがあります。2018年には幾つかのブラウザ拡張が localStorage のトークンを盗み売却した事件が発覚しました。
• リプレイ攻撃 — 攻撃者が通信を傍受しトークンを取得すれば、その有効期限内は繰り返し利用可能です。HTTPS なしでは非常に簡単に成立します。
• 長期有効トークン — 期限が数週間～数ヶ月もあると、攻撃者が悪用する機会が広がります。

開発者がベアラートークンをうっかり public な GitHub リポジトリにコミットし、攻撃者がそれをスキャンしてすぐに悪用した実例もあります。

ベアラートークンのベストプラクティス#

ベアラートークンを安全に運用するには、ベストプラクティスの遵守が重要です。各ポイントを例とともに紹介します：

1. 必ず HTTPS を使う

公共 Wi-Fi で平文 HTTP 送信を想像してみてください。ネットワークを傍受するだけで誰でもトークンを盗みあなたになりすませます。

2. 短命なアクセストークンを利用

多くのプラットフォームではトークンの有効期限を1時間程度に設定しています。Google OAuth トークンも通常1時間以内で失効します。

3. リフレッシュトークンは慎重に取り扱う

リフレッシュトークンは、ユーザー再ログインせず新しいアクセストークンを取得できますが、安全なサーバー上の暗号化 DB などに厳重に保存する必要があります（クライアント側保存は避ける）。

4. スコープは最小権限に限定

アプリがカレンダー閲覧だけ必要な場合、write:calendar など不要な権限はリクエストしないでください。漏洩時の被害が最小化できます。

5. 必要なときはトークンを失効

多くの SaaS アプリではユーザー自身がアクティブセッションを確認・失効可能です。GitHub もいつでも Personal Access Token の失効ができます。

6. 利用状況を監視

トークン利用ログは不審な挙動検知に役立ちます。同じトークンが数分間でロンドンとニューヨークから使われたら要注意です。

ベアラートークンと他の認証方法の比較#

ベアラートークンと他の代表的認証方式を比較してみましょう：

• クッキー＆セッション

  従来のウェブサイトはサーバー側セッション保存＋クッキー参照型が主流です。ブラウザアプリには合いますが、API やモバイルアプリにはやや非効率です。例えば Facebook デスクトップは主にクッキー方式、スマホ API はトークン方式を使います。

• API キー

  API キーはアプリ自体を一意に識別しますが、ユーザー情報は含みません。例えば天気アプリの API キーでは、どのユーザーが予報を閲覧しているかは分かりません。一方、ベアラートークンはユーザー個別情報を含められるため、より多用途です。

• 相互 TLS（mTLS）

  高度なセキュリティが求められる一部システムでは、クライアントとサーバーの双方に証明書を導入する「相互 TLS」方式を使います。より安全ですが、一般的な SaaS での大規模運用には難があります。ベアラートークンは利便性とセキュリティのバランスがちょうど良いです。

まとめ#

• ベアラートークンはシンプルかつ強力。「持っている人はアクセスできる」が基本です。
• OAuth 2.0 や OIDC フロー、とくに API やモバイルアプリで広く採用されています。
• セキュリティは運用次第：短命化・スコープ、HTTPS、失効管理が大切です。
• すべての場面に最適なわけではありませんが、SaaS や API ではセキュリティと利便性のバランスが良い選択肢です。