日本語
ベアラートークンとは？
ベアラートークンとは何か、OAuth 2.0 や JWT における動作、アクセストークンとの違い、ベストプラクティスについて解説します。
Guamian
Product & Design
Product & Design
ベアラートークンとは何か、OAuth 2.0 や JWT における動作、アクセストークンとの違い、ベストプラクティスについて解説します。
ほとんどすべての現代アプリのログインや API リクエストの裏側では、静かに仕事をする「ベアラートークン」が存在します。それに気づくことはあまりありませんが、サービスを連携したり、サインインしたり、クラウドからデータを取得するとき、毎回使われています。
このガイドでは、ベアラートークンの役割や重要性、安全な扱い方について説明します。
ベアラートークンとは、一般的に文字列データの一種であり、持ち主が特定のリソースへアクセスできることを証明するものです。重要なのは、そのトークンを「所持する人（bearer）」が追加の証明なしで利用できる点です。
航空券（搭乗券）を例に考えてみましょう。手にした後は、再度身分証明を求められることなく、保安検査を通過し飛行機に搭乗できます。同じように、ベアラートークンを使えば、アプリは毎回身元確認をせずに「API に搭乗」できるのです。
例えば、スマートフォンの Spotify にログインした後は、毎回パスワードを入力しなくても曲を再生できます。アプリはベアラートークンを保存し、Spotify のサーバーに「このリクエストは認可されたユーザーから来ている」と伝えます。
ベアラートークンの流れは以下のようなステップに分けられます：
ユーザーがログイン
例えば、銀行アプリにユーザー名とパスワードでログインします。
認証サーバーがトークンを発行
本人確認ができると、認証サーバーがベアラートークンを返します。以下のような文字列です：
クライアントがトークンを利用
「残高照会」や「送金」ボタンを押すたびに、アプリはトークンを HTTP リクエストヘッダーに含めます：
API がトークンを検証
サーバーはトークンの有効性、期限切れでないか、どの権限を持つか（例：read:balanceやwrite:transfer）などを確認します。
アクセス許可
すべてのチェックを通過すると、サーバーがリクエスト情報を返します。
このモデルは GitHub API など多くのサービスで使われており、開発者は繰り返し認証情報を入力するのではなくベアラートークンで認証を行います。
ベアラートークンは、Web セキュリティの課題を解決したことから利用が広がりました。サーバーベースのセッション管理と違い、トークン自体にリクエスト検証に必要な情報が含まれているため、各ユーザーのセッション情報をサーバー側で保存する必要がありません。
例えば、マイクロサービスアーキテクチャ―（多数のサービスが相互通信する形）では、中央集権的なセッション管理は複雑で非効率です。ベアラートークンなら、各サービスが独立してリクエストを検証でき、システムが軽量かつスケーラブルになります。
例として、Slack の API はベアラートークンに大きく依存しています。Slack ボットを構築すると、すべてのユーザーのセッションを管理せずとも、そのトークンで必要なエンドポイントを呼び出せます。
多くのベアラートークンは JWT（JSON Web Token） 形式で実装されています。これらはユーザー情報や権限などが含まれるエンコードされた文字列です。
サンプル JWT をデコードすると：
この意味は：
sub：サブジェクト（ユーザー固有のID）name：ユーザー名iat：発行タイムスタンプexp：有効期限（トークンが失効する時刻）scope：許可された権限。ここではメッセージの読み書きが可能。実際、Jane のトークンに read:messages だけが含まれていれば、アプリはメッセージを取得できても新規送信はできません。
ベアラートークンと**アクセストークン** は混同しやすい用語ですが、実は密接だが異なる概念です。
アクセストークンは、ユーザーが特定リソースにアクセスする権限をもつことを示す認証情報です。以下の属性があります：
学校の『許可証』のようなもので、先生（API）に「この生徒は遠足（リソースアクセス）に行ける」と伝えます。
たとえば、クラウドストレージサービスにログインすると、read:files のスコープを持つアクセストークンが発行され、それが「このユーザーはファイルの読み取りはできるが削除はできない」と伝えます。
ベアラートークンは、アクセストークンの一種です。bearer とは「トークンの使用方法」を示し、提示した人が追加の証明なくリソースへアクセスできます。
要するに：
他にもホルダー・オブ・キー・トークン（holder-of-key tokens） などが存在し、これらはトークンに加えて秘密鍵の所持証明が求められます。ベアラートークンはこの追加ステップが不要なため、シンプルですが盗まれた場合のリスクも高くなります。
<token> ヘッダーで使うアクセストークンを返します。つまり、OAuth の解説などで「アクセストークン」と出てきた場合、特に明記されてなければほぼベアラートークンを指します。
さらに明確にするため、ベアラートークンとよく使われる他のタイプを比べてみましょう：
ベアラートークンとアクセストークンは対立概念ではなく、関係性は：
ベアラートークンの検証は、API を無許可アクセスから防ぐ最前線です。トークンが JWT の場合、検証はローカルで高速に行えます。API は毎回発行元へ問い合わせせず、トークンだけで確認できます。
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 やセッション記録を短期参照して、ログアウトや侵害疑い後の防止策に。
ベアラートークンは「持っている人が使える」ため、家の鍵のように厳重に扱う必要があります。誰かに盗まれれば、鍵を交換するまでドアを自由に開けられてしまいます。
主なリスクは：
開発者がベアラートークンをうっかり public な GitHub リポジトリにコミットし、攻撃者がそれをスキャンしてすぐに悪用した実例もあります。
ベアラートークンを安全に運用するには、ベストプラクティスの遵守が重要です。各ポイントを例とともに紹介します：
公共 Wi-Fi で平文 HTTP 送信を想像してみてください。ネットワークを傍受するだけで誰でもトークンを盗みあなたになりすませます。
多くのプラットフォームではトークンの有効期限を1時間程度に設定しています。Google OAuth トークンも通常1時間以内で失効します。
リフレッシュトークンは、ユーザー再ログインせず新しいアクセストークンを取得できますが、安全なサーバー上の暗号化 DB などに厳重に保存する必要があります（クライアント側保存は避ける）。
アプリがカレンダー閲覧だけ必要な場合、write:calendar など不要な権限はリクエストしないでください。漏洩時の被害が最小化できます。
多くの SaaS アプリではユーザー自身がアクティブセッションを確認・失効可能です。GitHub もいつでも Personal Access Token の失効ができます。
トークン利用ログは不審な挙動検知に役立ちます。同じトークンが数分間でロンドンとニューヨークから使われたら要注意です。
ベアラートークンと他の代表的認証方式を比較してみましょう：
クッキー＆セッション
従来のウェブサイトはサーバー側セッション保存＋クッキー参照型が主流です。ブラウザアプリには合いますが、API やモバイルアプリにはやや非効率です。例えば Facebook デスクトップは主にクッキー方式、スマホ API はトークン方式を使います。
API キー
API キーはアプリ自体を一意に識別しますが、ユーザー情報は含みません。例えば天気アプリの API キーでは、どのユーザーが予報を閲覧しているかは分かりません。一方、ベアラートークンはユーザー個別情報を含められるため、より多用途です。
相互 TLS（mTLS）
高度なセキュリティが求められる一部システムでは、クライアントとサーバーの双方に証明書を導入する「相互 TLS」方式を使います。より安全ですが、一般的な SaaS での大規模運用には難があります。ベアラートークンは利便性とセキュリティのバランスがちょうど良いです。