MENU
プログラムとツールの使い方を、実務目線で分かりやすく整理
  1. ホーム
  2. プログラム
  3. PostmanでBearer Token認証を試す手順。APIの送信設定と401対処まで実務向けに整理

PostmanでBearer Token認証を試す手順。APIの送信設定と401対処まで実務向けに整理

プログラム

PostmanでBearer Token認証を試す手順。APIの送信設定と401対処まで実務向けに整理

Postmanで認証付きAPIを試したいなら、まず押さえるべきポイントはシンプルです。AuthorizationタブでBearer Tokenを選び、トークン本体だけを入力する。これでPostmanがAuthorization: Bearer <token>ヘッダーを自動で付けて送信します。

API連携の確認、受け入れテスト、障害切り分けでは、この設定を正しく入れられるかどうかで結果が大きく変わります。とくに初心者がつまずきやすいのは、Bearerまで含めて貼り付けてしまうこと、環境ごとにトークンを分けていないこと、401を見てもどこを確認すべきか分からないことです。

  • この記事でできること: PostmanでBearer Token認証を設定し、認証付きAPIを安全に試せる
  • 向いている場面: APIの疎通確認、社内APIの検証、OAuth 2.0で取得したアクセストークンの手動テスト
  • 対象読者: Postmanを使い始めた人、APIテストを業務で触り始めた人
  • 確認時点: 2026年4月25日
  • 前提: Postmanの現行ドキュメントに基づく手順。画面はWeb版とデスクトップ版で細部が異なる場合があります

ここがポイント: Bearer Token認証では、Postmanの入力欄に入れるのは通常トークン文字列だけです。Bearerという接頭辞はPostman側が付けます。

目次

Bearer Token認証とは何か

Bearer Token認証は、APIに対してアクセストークンを送り、そのトークンを持つクライアントにアクセスを許可する方式です。OAuth 2.0系のAPI、社内の認証ゲートウェイ配下のAPI、SaaS連携APIでよく使われます。

Postman公式ドキュメントでも、Bearer TokenはAuthorizationタブから設定でき、送信時にAuthorizationヘッダーへ自動反映されると案内されています。つまり、毎回ヘッダーを手で書かなくても、UIから安全に試せます。

どんな場面で使うのか

  • ログインAPIや認証サーバーで取得したアクセストークンを使って、本番相当のAPIを検証したいとき
  • フロントエンドやバッチの前に、API単体でレスポンスやエラー内容を確認したいとき
  • 401 Unauthorizedが、トークン不備なのか権限不足なのかを切り分けたいとき

PostmanでBearer Tokenを設定する基本手順

まずは1件のリクエストで試すのが確実です。

手順1: リクエストを作成する

新しいHTTPリクエストを作成し、対象APIのURLとメソッドを入力します。たとえばGETなら、GET https://api.example.com/v1/users/me のような形です。

手順2: Authorizationタブを開く

リクエスト画面のAuthorizationタブを開き、Auth TypeのプルダウンからBearer Tokenを選びます。

ここをNo Authのままにすると、トークンを持っていてもAuthorizationヘッダーが付きません。まず最初に見るべき場所です。

手順3: Token欄にトークン本体を入力する

Token欄にアクセストークンを貼り付けます。

入力例:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.example.payload

このとき重要なのは、Bearerを含めないことです。PostmanはBearer Token認証を選ぶと、自動でAuthorization: Bearer <token>の形にします。

誤った入力例:

Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.example.payload

この状態で送ると、ヘッダーが二重になり、API側で弾かれることがあります。

手順4: Sendしてレスポンスを確認する

Sendを押したら、最低でも次の3点を見ます。

  • ステータスコード: 200台なら認証通過の可能性が高い
  • レスポンスボディ: 認証後のデータ、またはエラーメッセージ
  • Headers: Authorizationヘッダーが想定どおり付いているか

401なら、まずトークン自体ではなく送信形式を疑うのが実務では近道です。

まず試せる最小サンプル

社内APIや本番APIでいきなり試す前に、Bearerヘッダーが送れているかだけ確認したいなら、テスト用エンドポイントを使うと切り分けが早くなります。

例: Bearerヘッダーの送信確認

リクエスト例:

GET https://httpbingo.org/bearer
Authorization: Bearer test-token-123

Postmanでの設定は次のとおりです。

  • Method: GET
  • URL: https://httpbingo.org/bearer
  • Authorization: Bearer Token
  • Token: test-token-123

期待する見え方:

  • 正しく送れれば200 OK
  • Bearerヘッダーが無い、または形式が崩れていれば401 Unauthorized

この確認の意味は大きいです。ここで通るなら、Postmanの設定はほぼ正しいので、次に疑うべきはAPI側の権限、トークン期限、スコープ不足に絞れます。

入力例と出力の見方

たとえば実務では、次のように変数化しておくと使い回しやすくなります。

URL: {{base_url}}/v1/users/me
Token: {{access_token}}

成功時のレスポンス例:

{
  "id": 101,
  "name": "Taro Example",
  "email": "taro@example.com"
}

失敗時のレスポンス例:

{
  "error": "Unauthorized"
}

ここで見るべきなのは、JSONの形そのものよりも、認証が通って業務データに進めたか、認証段階で止められているかです。

実務では変数で管理したほうが安全

トークンを毎回ベタ書きすると、貼り間違いも起きますし、画面共有やスクリーンショットで漏えいしやすくなります。Postman公式ドキュメントでも、変数やVaultの利用が案内されています。

環境変数に入れる

環境ごとにAPIのURLやトークンが違うなら、Environmentを使うのが基本です。

おすすめの変数名:

  • base_url
  • access_token
  • tenant_id
  • api_version

設定後は、リクエストURLやAuthorization欄で次のように参照できます。

{{base_url}}/v1/orders
{{access_token}}

これなら、開発環境と本番環境の切り替えも速くなります。URLだけ本番、トークンだけ検証環境、という事故も減らせます。

Vaultを使う

より安全に扱いたいなら、Postman Vaultを使う方法があります。Vaultのシークレットはローカルに保持され、Postman Cloudへ同期されません。

とくに次の場面では有効です。

  • 本番トークンをチーム共有変数に置きたくない
  • 画面上で値を隠したまま使いたい
  • 複数APIの認証情報をまとめて管理したい

ただし、Vaultはローカル保存なので、サインアウトや端末移行時にそのまま残らない点は把握しておく必要があります。必要ならエクスポート手順も確認しておくべきです。

コレクションに認証を持たせると管理が楽になる

同じAPI群を何本も試すなら、各リクエストでBearer Tokenを設定するより、Collection単位で認証を持たせるほうが管理しやすくなります。

Inherit auth from parentを使う場面

たとえばユーザーAPI、注文API、在庫APIが同じ認証基盤を使うなら、CollectionにBearer Tokenを設定し、各リクエストではInherit auth from parentを使います。

この形にすると、次のメリットがあります。

  • トークンの更新箇所が1か所で済む
  • 新しいリクエストを追加しても設定漏れが減る
  • フォルダ単位で認証を分ける運用もしやすい

実務でリクエスト数が増えるほど、この差は効きます。

401 Unauthorizedになったときの確認ポイント

Bearer Token認証で詰まりやすいのは、コードではなく設定ミスです。確認は上から順に行うと早いです。

1. Bearerまで貼り付けていないか

もっとも多いミスです。PostmanのBearer Token欄にBearer abc...と入れると、ヘッダーが壊れます。

2. トークンの期限が切れていないか

OAuth 2.0のアクセストークンは短命なことが多く、しばらく置いた後に401になるのは珍しくありません。取得直後に同じAPIで再試行すると切り分けしやすくなります。

3. 必要な権限スコープが入っているか

認証は通っても、必要スコープが無ければアクセス拒否されるAPIがあります。ユーザー情報は見られるのに更新系だけ失敗するなら、ここを疑います。

4. Environmentの切り替え先が正しいか

開発環境のURLに本番トークン、あるいはその逆になっていないかを見ます。Postmanで変数を使う運用では、環境の選択ミスが地味に多いです。

5. API仕様がBearer以外を要求していないか

APIによっては次のような違いがあります。

  • Authorization: Bearer <token> を要求する
  • x-api-key: <key> を要求する
  • Authorization: Token <token> のように独自接頭辞を要求する

Postman公式ドキュメントでも、独自の接頭辞が必要な場合はBearer Tokenではなく、API KeyでAuthorizationヘッダーを組む方法が案内されています。

Bearer TokenとJWT Bearerは同じではない

ここも混同しやすい点です。

Bearer Token

すでに発行済みのアクセストークンを、そのまま送る方式です。普段のAPIテストで使うのはこちらです。

JWT Bearer

Postman側でJWTを生成して送るための設定です。署名アルゴリズムやペイロード、秘密鍵の扱いが関わるため、用途が違います。

すでに認証基盤から受け取ったトークンを試すだけなら、通常はBearer Tokenを選びます。画面上でJWT Bearerが見えても、安易に選ばないほうが混乱しません。

代替手段との使い分け

Bearer Token設定が合わないケースもあります。無理に一つの方法へ寄せず、API仕様に合わせて切り替えるのが実務的です。

Headersタブで直接次のように書く方法です。

Authorization: Bearer {{access_token}}

向いている場面:

  • ヘッダーを細かく制御したい
  • 接頭辞がBearer以外
  • 一時的に送信内容を明示したい

API Key認証を使う方法

Authorizationというキー名で独自形式を送りたいときに便利です。

例:

Authorization: Token abcdef123456

この場合はBearer Token設定ではなく、API Keyを選んでキー名をAuthorizationにするほうが素直です。

安全に扱うための注意点

認証付きAPIの検証では、送信できること以上に、漏らさないことが重要です。

  • トークンをスクリーンショットや録画に映さない
  • チーム共有のCollection変数に本番トークンを置きっぱなしにしない
  • 退職者や異動者が使っていた共有環境を放置しない
  • 可能ならVaultかローカル変数を使う
  • 記事、Wiki、チケットへ実トークンを貼らない

短時間だけ使う検証トークンでも、権限が強ければ事故になります。「試験用だから大丈夫」は通用しないと考えたほうが安全です。

迷ったときの最短チェックリスト

最後に、Bearer Token認証がうまくいかないときの確認順を短くまとめます。

  • AuthorizationタブでBearer Tokenを選んでいるか
  • Token欄にBearerを含めず、トークン本体だけ入れているか
  • ステータスコードが401か403かを見分けているか
  • トークンの期限と権限スコープを確認したか
  • EnvironmentのURLとトークンの組み合わせが正しいか
  • 独自接頭辞が必要ならAPI Keyや手書きヘッダーへ切り替えたか

PostmanでBearer Token認証を試す作業自体は数分で終わります。ただし、実務で差が出るのは、設定を再利用できる形で残すことと、401が出たときに送信形式・期限・権限のどこから切り分けるかを決めておくことです。次に見るべきなのは、トークン取得元の仕様と、APIごとの必要スコープです。

参照リンク

プログラム
API Bearer Token HTTP JSON JWT Postman アクセストークン エラー対処 認証
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！
目次