Bearer Token（ベアラートークン）とは？読み方・Authorization: Bearerの書き方とJWTとの違い

Bearer Token（ベアラートークン）は、「持っている人なら誰でも使える」性質を持つアクセストークンです。APIを呼ぶときにAuthorization: Bearer <トークン>というヘッダーで送り、サーバーはトークンが有効か、その操作を許す権限を含むかを検証して処理を許可します。送り手が正当な持ち主かどうかは確かめません。

本記事では、仕様であるRFC 6750（2012年10月）の定義を軸に、GitHub APIでの使用例、ヘッダーの書き方、トークンの発行元、サーバーが返す401・403の意味、アクセストークン・JWT・APIキーとの違い、盗まれたときの被害を抑える方法を整理します。コード例はcurl 8.7.1・Node.js 26.5.0・Java 25（OpenJDK 25.0.4.1）で2026年10月17日に実行して確かめたものです。Spring Securityの挙動は7.1.1のソースで確認しました。

まとめ：Bearer Tokenの要点

• 読み方は「ベアラートークン」。bearerは「持参人」の意味で、トークンを持っている者が使える点が名前の由来です。
• RFC 6750の定義では、使う側に暗号鍵の所持証明（proof-of-possession）を求めません。盗まれると、盗んだ側もそのまま使えます。
• 送り方の基本はAuthorization: Bearer <トークン>。「Bearer」と値の間は半角スペースです。URLのクエリに載せる方法はRFC 9700（2025年1月）で禁止されました。
• Bearerは「持っていれば使える」トークンの性質と、その送り方（HTTP認証スキーム）を指し、JWTは「トークンのデータ形式」です。JWTをBearerとして送る組み合わせが一般的で、両者は対立する概念ではありません。
• 「アクセストークン」はAPIを呼ぶ資格情報という役割の名前で、Bearerはその使い方の性質です。アクセストークンの多くはBearer型ですが、鍵に結びつけたDPoPトークンはBearerではありません。
• 失敗時、サーバーはWWW-Authenticate: Bearerヘッダーで理由を返します。期限切れや改ざんは401のinvalid_token、権限不足は403のinsufficient_scopeです。
• 漏えい対策の基本は、HTTPSの徹底・1時間以下の短い有効期限・送信先の限定です。リスクが高いクライアントでは、トークンを鍵に結びつけるDPoP（RFC 9449）を検討します。

Bearer Tokenの意味と読み方：持っている者が使える通行証

読み方は「ベアラートークン」、bearerは「持参人」の意味

Bearerは「ベアラー」と読みます。英語のbearerは「持参人」「運ぶ人」を指す語で、Bearer Tokenは「持参した人に効力が生じるトークン」という意味になります。チケットや回数券と同じで、窓口は持ってきた人の身元を確かめず、券が本物かどうかだけを見ます。

日本語では「ベアラートークン」「Bearerトークン」「Bearer認証」と表記が分かれますが、指しているものは同じです。「Bearer認証」はHTTPの認証スキームとしてのBearerを指す呼び方で、トークンを送る仕組み全体を表します。

「Bearer認証」が確かめるのは本人ではなく権限

「Bearer認証」と呼ばれますが、サーバーがトークンで確かめているのは「誰か」より「何をしてよいか」です。認証（authentication）は利用者が本人かを確かめる処理、認可（authorization）はリソースへのアクセスを許すかを決める処理で、Bearer Tokenは認可の結果を運ぶ入れ物にあたります。OAuth 2.0のRFC 6749もアクセストークンを「クライアントに発行された認可を表す文字列」と定義しています。認可コードフローでは利用者がトークンの発行前にログインして同意しますが、クライアントクレデンシャルフローのように利用者のログインを伴わない発行方法もあります。APIはトークンの有効性と、そのトークンに対応する権限を検証してアクセスを許可します。

ログインした本人の認証結果をアプリが確認するには、OpenID ConnectのIDトークンを検証します。プロフィールなどの情報は、アクセストークンでUserInfoエンドポイントを呼び出して取得することもできます。用途の分け方はOIDCのIDトークンとOAuth 2.0との違いで解説しています。

RFC 6750の定義：暗号鍵の所持証明を求めないトークン

Bearer Tokenを定めた仕様はRFC 6750「The OAuth 2.0 Authorization Framework: Bearer Token Usage」です。第1.2節の定義は次のとおりです。

A security token with the property that any party in possession of the token (a “bearer”) can use the token in any way that any other party in possession of it can. Using a bearer token does not require a bearer to prove possession of cryptographic key material (proof-of-possession).

要点は後半にあります。トークンを使うときに暗号鍵を持っていることの証明が要らないため、実装は単純になります。その代わり、ログやブラウザ履歴から漏れたトークンは第三者がそのまま使えます。本記事の後半で扱う対策は、すべてこの性質から出てくるものです。

OAuth 2.0との関係：トークン応答のtoken_typeが「Bearer」

Bearer TokenはOAuth 2.0の一部として定義されました。OAuth 2.0のRFC 6749がトークンを「どう発行するか」を定め、RFC 6750がそのトークンを「どう送るか」を定める分担です。認可サーバーのトークンエンドポイントは、次のような応答でBearer Tokenを返します（RFC 6750 第4章の例）。

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "access_token":"mF_9.B5f-4.1JqM",
  "token_type":"Bearer",
  "expires_in":3600,
  "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
}

token_typeがBearerなら、クライアントはaccess_tokenの値をBearerスキームで送ります。expires_inは有効期間の秒数で、この例では1時間です。期限が切れたらrefresh_tokenで新しいアクセストークンを取り直します。更新の設計はリフレッシュトークンの更新フローと寿命・ローテーション設計で詳しく扱っています。OAuth 2.0全体の流れはOAuth 2.0の仕組みと認可フローの解説を参照してください。

Bearer Tokenの使用例：GitHub REST APIを呼ぶ流れ

実在のAPIで流れを追うと、使われ方がつかめます。GitHubのREST APIを個人用アクセストークン（PAT）で呼ぶ場合は次の3段階です。

1. GitHubの設定画面でPATを発行する。スコープ（許す操作）と有効期限はここで決まる
2. APIを呼ぶリクエストにAuthorization: Bearer <PAT>を付ける
3. GitHubがトークンの有効性と権限を確かめ、成功すれば結果を返す。無効な資格情報では通常401、権限不足では403や404などを返す

curl -H "Authorization: Bearer $GITHUB_TOKEN" \
     -H "Accept: application/vnd.github+json" \
     https://api.github.com/user

2026年10月17日に、形式だけ似せた無効なトークンを送ったところ、応答はステータス401で、本文は"message": "Bad credentials"でした。ヘッダーを付けずに送ると、同じ401で"Requires authentication"になります。どちらの応答にも、後で説明するRFC 6750のWWW-Authenticateヘッダーは付いていませんでした。失敗理由をJSONの本文だけで返すAPIもあるため、クライアントはステータスコードと本文の両方を見て判断します。

Authorization: Bearerの書き方：ヘッダー・curl・JavaScript

ヘッダーの構文は「Bearer」＋半角スペース＋トークン

RFC 6750は、Authorizationヘッダーに載せる値の構文を次のように定めています。

b64token    = 1*( ALPHA / DIGIT /
                  "-" / "." / "_" / "~" / "+" / "/" ) *"="
credentials = "Bearer" 1*SP b64token

「Bearer」の後に1個以上の半角スペースを置き、英数字と- . _ ~ + /、末尾の=だけでできたトークンを続けます。実際のリクエストは次の形です。

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM

よくある誤りは3つです。「Bearer」と値の間のスペース抜け（Bearermf_9...）、コロンの追加（Bearer: ...）、トークンを引用符で囲むこと。いずれも構文から外れるため、サーバーに拒否されます。多くの実装は401を返しますが、RFC 6750は形式不正のリクエストを400（invalid_request）で返すことも認めています。

なお、HTTPの仕様（RFC 9110 第11.1節）は認証スキーム名を大文字小文字を区別しないトークンとしています。bearerと小文字で送っても仕様上は同じ意味ですが、文字列を完全一致で比べる実装も残っています。送る側はBearerと書くのが確実です。

curlとJavaScript（fetch）で送る方法

curlでは-Hでヘッダーを直接書くか、--oauth2-bearerオプションを使います。手元のcurl 8.7.1で、どちらも同じAuthorization: Bearer mF_9.B5f-4.1JqMがサーバーに届くことを確認しました。

curl -H "Authorization: Bearer mF_9.B5f-4.1JqM" https://api.example.com/resource

# 同じヘッダーを付ける専用オプション
curl --oauth2-bearer mF_9.B5f-4.1JqM https://api.example.com/resource

Node.jsのfetchでは、headersにAuthorizationを渡します。次の例は環境変数API_TOKENからトークンを読むNode.js用のコードです。実行前にAPI_TOKENを設定し、例示URLをトークンの送信先として許可した実際のAPIに置き換えてください。ブラウザにはprocess.envが無いため、トークンはログイン処理で受け取った値を変数から渡します。

const token = process.env.API_TOKEN;
if (!token) throw new Error("API_TOKEN is not set");

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

トークンはソースコードに直書きせず、環境変数やシークレット管理から読み込みます。GitHub REST APIの公式ドキュメントには、JWTを渡す場合はAuthorization: tokenではなくBearerを使う必要があると書かれています。

ボディとクエリで送る方法が非推奨になった経緯

RFC 6750は、ヘッダー以外に2つの送り方も定義していました。現在はヘッダーを使うのが前提です。

フォームボディで送れるのは、ASCII文字だけでできたContent-Type: application/x-www-form-urlencodedの単一パートのボディを、POSTのようにボディの意味が定義されたメソッドで送る場合に限られます（GETは不可）。しかもRFC 6750は、ブラウザがAuthorizationヘッダーを扱えない場面以外ではこの方法を使うべきでない（SHOULD NOT）としています。URLクエリの方法は、RFC 6750の時点で「URLがログに残る可能性が高い」として非推奨でした。OAuthのセキュリティ指針であるRFC 9700はこれを「Clients MUST NOT pass access tokens in a URI query parameter」と禁止に引き上げました。2026年9月に公開されたOAuth 2.1 draft-16（RFCになる前の草案で、内容は未確定）では、クライアントがクエリで送ることを禁じたうえで、リソースサーバーもクエリのトークンを無視しなければならないと定めています。

WebSocketの接続URLやダウンロードリンクなど、ヘッダーを付けにくい場面でクエリに載せたくなることがあります。その場合も長期トークンをそのまま載せず、数十秒で失効する使い捨てのチケットを別途発行して渡すのが安全です。

Bearer Tokenの取得先と生成方法：発行元3種と自前発行時の乱数

API利用者がトークンの文字列を自作することはありません。トークンは認可サーバーやサービスの認証基盤が発行し、APIを提供するリソースサーバーが検証します。小規模なサービスでは、同じサーバーが発行と検証を兼ねることもあります。利用者から見た取得先は大きく3つです。

• OAuth 2.0の認可サーバー：認可コードフローやクライアントクレデンシャルフローを経て、トークンエンドポイントが発行します。手順は認可コードフローの実装手順と検証設計で解説しています。
• サービスの管理画面：GitHubの個人用アクセストークンや、X APIの開発者ポータルで発行するBearer Tokenのように、画面操作で払い出すものです。作成手順はGitHub PATの作成方法と有効期限、X APIの使い方と実装を参照してください。
• 自社APIの認証基盤：Amazon CognitoやAuth0などのIDaaS、または自前のログイン処理が発行します。

RFC 6750はトークンの中身の形式を決めていません。ランダムな文字列（opaqueトークン）でも、署名付きのJWTでもかまいません。opaqueトークンを自前で発行する場合は、予測できない乱数から作ります。次の2つはどちらも32バイトの暗号学的乱数を、Bearerの構文で使える文字だけで表したものです。

# OpenSSL 4.0.3：44文字（末尾に=が付く）
openssl rand -base64 32

# Python：43文字のURLセーフな文字列
python3 -c "import secrets; print(secrets.token_urlsafe(32))"

連番やUUID v1、時刻から作った値は推測されるので使いません。発行したトークンはハッシュ化して保存し、照合時もハッシュ同士を比べると、データベースが漏れてもトークンそのものは漏れません。発行から失効・ローテーションまでの運用はAPIキー管理の発行・保管・失効とローテーションが詳しく扱っています。

サーバー側の検証とエラー応答：401・403とWWW-Authenticate

WWW-Authenticateで返す3つのエラーコード

検証に失敗したとき、リソースサーバーはWWW-Authenticate: Bearerヘッダーに理由を入れて返します。RFC 6750が定めるエラーコードは次の3つです。

期限切れのトークンを送ったときの応答例は次のとおりです。

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example",
                  error="invalid_token",
                  error_description="The access token expired"

クライアントはerrorの値で次の動きを変えます。invalid_tokenならトークンを取り直して再送してよいとRFCは書いています。insufficient_scopeは取り直しても同じスコープなら結果が変わらないため、要求するスコープを見直します。エラーメッセージの「401 Authorization Required」「トークンが無効です」で確認する候補は、このinvalid_tokenか、ヘッダーそのものが届いていないケースです。プロキシやロードバランサーがAuthorizationヘッダーを落としていないかも確認対象になります。

Javaで検証サーバーとクライアントを動かした結果

Java標準ライブラリだけで、Bearerヘッダーを検証するサーバーと、それを呼ぶクライアントを1ファイルにまとめました。java BearerDemo.javaでそのまま実行できます。

import com.sun.net.httpserver.HttpServer;
import java.net.InetSocketAddress;
import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.nio.charset.StandardCharsets;
import java.security.MessageDigest;

public class BearerDemo {
    static final String EXPECTED = "mF_9.B5f-4.1JqM";

    public static void main(String[] args) throws Exception {
        HttpServer server = HttpServer.create(new InetSocketAddress("127.0.0.1", 8080), 0);
        server.createContext("/resource", ex -> {
            String h = ex.getRequestHeaders().getFirst("Authorization");
            int status;
            if (h == null || !h.regionMatches(true, 0, "Bearer ", 0, 7)) {
                ex.getResponseHeaders().add("WWW-Authenticate", "Bearer realm=\"example\"");
                status = 401;
            } else if (!MessageDigest.isEqual(
                    h.substring(7).trim().getBytes(StandardCharsets.US_ASCII),
                    EXPECTED.getBytes(StandardCharsets.US_ASCII))) {
                ex.getResponseHeaders().add("WWW-Authenticate",
                    "Bearer realm=\"example\", error=\"invalid_token\"");
                status = 401;
            } else {
                status = 200;
            }
            ex.sendResponseHeaders(status, -1);
            ex.close();
        });
        server.start();

        HttpClient client = HttpClient.newHttpClient();
        String[] headers = { null, "Bearer wrong-token", "Bearer " + EXPECTED, "bearer " + EXPECTED };
        for (String h : headers) {
            HttpRequest.Builder b = HttpRequest.newBuilder(URI.create("http://127.0.0.1:8080/resource"));
            if (h != null) b.header("Authorization", h);
            HttpResponse<Void> res = client.send(b.build(), HttpResponse.BodyHandlers.discarding());
            System.out.println((h == null ? "(no header)" : h) + " -> " + res.statusCode() + " "
                + res.headers().firstValue("WWW-Authenticate").orElse(""));
        }
        server.stop(0);
    }
}

OpenJDK 25.0.4.1での実行結果です。

(no header) -> 401 Bearer realm="example"
Bearer wrong-token -> 401 Bearer realm="example", error="invalid_token"
Bearer mF_9.B5f-4.1JqM -> 200
bearer mF_9.B5f-4.1JqM -> 200

ヘッダーが無いときはerrorを付けない、誤ったトークンにはinvalid_tokenを付ける、というRFC 6750の区別がそのまま出ています。スキーム名はregionMatches(true, ...)で大文字小文字を区別せずに判定しているので、4行目の小文字bearerも通ります。トークンの照合にMessageDigest.isEqualを使っているのは、比較にかかる時間から一致した文字数を推測されないようにするためです。

このサンプルは固定文字列と比べるだけの学習用です。本番では、JWTなら署名・exp（期限）・aud（宛先）に加えて、信頼する発行者（iss）との一致と、許可した署名アルゴリズム（algがnoneなら拒否）も検証し（RFC 9068 第4章）、opaqueトークンなら、認可サーバーのイントロスペクション（RFC 7662）への問い合わせや、発行元と共有するトークン管理情報との照合などで有効性を検証します。JWTの検証手順はJWTの構造・署名検証の仕組み、IDaaSで組む例はCognitoでのJWT検証までの実装手順で扱っています。

Spring Securityの既定の解釈：スペースは1個、クエリとボディは無効

Javaの実務では、検証を自前で書かずにSpring Securityのリソースサーバー機能に任せることが多くなります。既定のBearerTokenAuthenticationFilterは、DefaultBearerTokenResolverでヘッダーからトークンを取り出します。7.1.1（2026年8月20日リリース）のソースでは、大文字小文字を区別しない次の正規表現で照合しています。

^Bearer (?<token>[a-zA-Z0-9-._~+/]+=*)$

同じ正規表現をJava 25で動かした結果です。

[Bearer mF_9.B5f-4.1JqM] -> match
[bearer mF_9.B5f-4.1JqM] -> match
[Bearer  mF_9.B5f-4.1JqM] -> malformed
[Bearer: mF_9.B5f-4.1JqM] -> malformed
[Bearer "mF_9.B5f-4.1JqM"] -> malformed

RFC 6750の構文は「Bearer」の後に1個以上のスペースを認めていますが、Spring Securityはちょうど1個しか受け付けません。スペースが2個のヘッダーはinvalid_token（Bearer token is malformed）で拒否されます。前の節の自作サーバーはtrim()で余分なスペースを許すので、同じヘッダーでも実装によって結果が分かれます。送る側は「Bearer」＋半角スペース1個に揃えておくのが安全です。ほかの既定値も厳しめです。

• URLクエリ（access_tokenパラメータ）とフォームボディからの読み取りは既定で無効。setAllowUriQueryParameter(true)などで明示しない限り読まない
• 有効にしても、クエリはGETのときだけ、ボディはGET以外かつapplication/x-www-form-urlencodedのときだけ読む
• 読み取りが有効な送信方法で、ヘッダーとクエリなど複数の場所からトークンを取得した場合はinvalid_request（Found multiple bearer tokens in the request）で拒否する

Spring Bootでの認証の組み立て全体はSpring Bootの認証実装：カスタムAuthenticationProviderの作り方で扱っています。

Bearer TokenとJWT・APIキー・Basic認証の違い

比較されがちな4つは、そもそも分類の軸が違います。Bearer Tokenは「持っていれば使える」性質のトークンで、BearerとBasicはそれぞれを送るHTTP認証スキームの名前です。JWTはトークンのデータ形式、APIキーは資格情報の種類を指します。

アクセストークンとの違い：アクセストークンは「保護されたリソースにアクセスするための資格情報」という役割の名前で（RFC 6749 第1.4節）、Bearer Tokenは「持っていれば使える」という使い方の性質を表す名前です。OAuth 2.0で発行されるアクセストークンの多くはBearer型なので、ほぼ同じ意味で使われます。ただし、後述のDPoPで鍵に結びつけたアクセストークンは、トークン応答のtoken_typeがDPoPになり（RFC 9449 第5章）、Bearerとしては扱われません。「アクセストークン＝Bearer Token」ではなく、「Bearer型のアクセストークンが主流」という関係です。

JWTとの違い：JWT（RFC 7519）はクレームを載せるデータ形式で、アクセストークンとして使うときは署名付きにします（RFC 9068）。Bearer Tokenの中身として使われる代表的な形式です。「JWTかBearerか」を選ぶ場面はなく、「Bearerで送るトークンをJWTにするか、opaqueにするか」を選びます。JWTは認可サーバーに問い合わせずに、署名と発行者・宛先・期限のクレームを確かめて検証できる反面、発行後に取り消しにくい性質があります。

APIキーとの違い：APIキーをAuthorization: Bearerで送るサービスも多く、ヘッダーだけでは区別できません。違いは寿命と発行経路です。APIキーは管理画面で発行して長期間使い回すことが多いのに対し、OAuthのアクセストークンは期限付きで発行するのが一般的です。発行の経路も、ユーザーの同意を得る認可コードフローと、ユーザーが関与しないクライアントクレデンシャルフローがあります。

Basic認証との違い：Basic認証は、IDとパスワードをコロンでつないだ文字列全体をBase64にして毎回送ります。Base64は暗号化ではないので、漏れればパスワードそのものが知られます。Bearer Tokenが漏れても、パスワードまでは知られません。ただし、期限内に許可された操作でデータを盗まれたり変更されたりすると、その被害はトークンの失効後も残ります。

方式をどう選ぶかは、公開範囲や第三者への権限委譲の有無で決まります。判断の順序はAPI認証の設計と方式選定マトリクスにまとめています。トークンの発行・検証を含む認証基盤の構築を任せたい場合は、弊社の認証基盤・ID管理システム開発でもご相談を受け付けています。

漏れたら使われる弱点と対策：有効期限・保存場所・DPoP

Bearer Tokenが盗まれると何が起きるかは、2022年4月の実例が分かりやすいです。GitHubの発表によると、HerokuとTravis CIが連携用に保管していたGitHubのOAuthユーザートークンが盗まれ、攻撃者はそれを使ってnpmを含む数十の組織からデータをダウンロードしました。GitHubは自社のシステムから漏れたものではないとしています。トークンを持っていたことだけで正規の連携アプリとして通ってしまい、GitHubは両社に該当アプリのトークンをすべて失効させるよう求めました。

RFC 6750第5.3節の推奨事項：TLS・短い期限・宛先の限定

RFC 6750の第5.3節は、Bearer Tokenを扱う実装への推奨をまとめています。最も重いのは最初の項目で、ほかの項目はすべてこの具体化です。

• トークンを意図しない相手に漏らさない（最重要）
• 常にTLS（https）で送り、サーバー証明書のチェーンを検証する
• 平文で送られうるCookieに保存しない。Cookieに置くならCSRF対策を併用する
• 有効期限を短くする。ブラウザで動くクライアントには1時間以下を推奨
• 宛先（audience）を限定し、特定のリソースサーバーでしか使えないようにする
• ページのURLに載せない

ブラウザでの保存先（メモリ・localStorage・HttpOnly Cookie）は、XSSとCSRFのどちらを重く見るかで答えが変わります。比較はJWTの記事の保存場所の章、サーバー側でセッションを持つ設計はセッション管理の実装と保存先選定、モバイルアプリではflutter_secure_storageによるトークン保存が参考になります。

送信者制約トークン：DPoP（RFC 9449）とmTLS（RFC 8705）

どれだけ短命にしても、有効期間中に盗まれたBearer Tokenは使えてしまいます。盗まれたトークン単体での再利用を防ぐのが、トークンを特定の送り手に結びつける送信者制約（sender-constrained）トークンです。RFC 9700は、アクセストークンのリプレイ対策として「Sender-constrained access tokens … SHOULD be used」と推奨しています。

代表的な方式は2つです。DPoP（RFC 9449、2023年9月）は、クライアントが持つ秘密鍵でリクエストごとに署名した証明（DPoP proof）をDPoPヘッダーに付けます。アクセストークンはAuthorization: DPoP <トークン>とDPoPスキームで送り、スキーム名もBearerとは別になります。mTLS（RFC 8705）は、TLSのクライアント証明書にトークンを結びつけます。ただし万能ではありません。RFC 9449自身が、XSSでクライアント上のコードを乗っ取られた場合は攻撃者が正規の鍵でDPoP proofを作れるため防げないと明記しています。

導入の判断は次の線引きをおすすめします。SPAやモバイルアプリのように端末からトークンが漏れやすく、金融・医療・管理者権限など被害が大きいAPIでは、DPoPを採用する価値があります。一方、社内のサーバー間通信で有効期限が数分程度なら、導入の手間に見合わないことが多く、Bearerのまま運用する選択もあります。その場合も、トークンをログに出さない、宛先を限定するといった漏えい経路の管理が前提です。DPoPは認可サーバーとリソースサーバーの両方が対応していないと使えず、証明の再利用を防ぐ仕組みも要るため、採用するIDaaSやフレームワークが対応しているかを先に確かめてください。

よくある質問

Bearer Tokenの読み方と意味は？

「ベアラートークン」と読みます。bearerは「持参人」の意味で、持っている人なら誰でも使えるトークンであることを表します。

アクセストークンとベアラートークンの違いは何ですか？

アクセストークンはAPIを呼ぶための資格情報という役割、ベアラートークンは持っていれば誰でも使えるという性質を指します。OAuth 2.0のアクセストークンの多くはBearer型ですが、DPoPで鍵に結びつけたものはアクセストークンであってもBearerではありません。

Bearer TokenとJWTは何が違いますか？

Bearerはトークンの性質と送り方（認証スキーム）、JWTはトークンのデータ形式です。JWTをBearer Tokenとして送るのが一般的な組み合わせで、どちらか一方を選ぶものではありません。

Bearer Tokenの有効期限はどれくらいが目安ですか？

RFC 6750は、ブラウザで動くクライアントなど漏えいしやすい環境には1時間以下の短命なトークンを推奨しています。期限切れ後は、リフレッシュトークンを受け取っていればそれで取り直し、無ければ（クライアントクレデンシャルフローなど）同じフローでトークンを取得し直します。

Bearer Tokenで401が返るときは何を確認すればよいですか？

まずWWW-Authenticateヘッダーのerror値を見ます。invalid_tokenなら期限切れ・失効・形式不正のいずれかです。error値が無い場合は、トークン未送信や未対応の認証方式に加え、APIがこのヘッダーでエラー理由を返さない可能性もあります。レスポンス本文とAPIの公式仕様も確認してください。「Bearer」の後のスペース抜けや、プロキシがAuthorizationヘッダーを削っていないかも確認してください。

関連記事

• JWTとは？構造・署名検証の仕組みとセッション・OAuth/OIDCとの違いを実装視点で解説
• OAuth 2.0とは？仕組み・認可フローと認証・認可の違いをわかりやすく解説
• リフレッシュトークンとは？更新フローと寿命・ローテーション設計を実装者向けに解説
• API認証の設計｜方式選定マトリクスとトークン寿命・監査ログの決め方
• APIキー管理とは？発行・保管・失効とローテーションの実装を解説