アクセストークン

Access Token

security development beginner

利用者やアプリに許可された範囲・期間で、APIなどの保護された機能へアクセスするための認可情報。

概要（サマリー）

アクセストークンとは、利用者やアプリに許可された範囲・期間で、APIなどの保護された機能へアクセスするための認可情報である。

たとえば、テーマパークで特定エリアへの入場が許可された人に、利用可能な場所と時間が決められたリストバンドを渡す場面を考えるとわかりやすい。アクセストークンはこのリストバンドに近く、提示された側は「誰か」だけでなく、「どの機能を、どの期間まで利用できるか」を確認する。

アクセストークンは、親ページのトークンで整理している意味のうち、認証・認可分野で使われるものである。特にBearerトークンは、持っている人が利用できる性質を持つため、漏えいすると許可された操作を第三者に実行される危険がある。有効期限、権限範囲、対象APIを必要最小限にし、安全に保管・送信することが重要である。

詳細解説

なぜパスワードを毎回送らないのか

Webサービスやアプリでは、利用者やアプリがサーバーへ何度もリクエストを送る。このとき、保護された機能を利用するたびに利用者のパスワードを直接扱う設計は避ける必要がある。

そこで、OAuthなどでは、認可サーバーが許可された範囲や有効期間などに基づいてアクセストークンを発行する。クライアントはそのトークンをリソースサーバーへ提示し、保護されたAPIへアクセスする。アクセストークンは認可情報であり、それ自体が利用者の本人確認方法を示すとは限らない。

アクセストークンが使われる流れ

ざっくり言うと、次のような流れになる。

利用者またはアプリが、必要なアクセス許可を求める
認可サーバーが許可内容を確認し、クライアントへアクセストークンを発行する
クライアントは、保護されたAPIへのリクエストにトークンを付ける
リソースサーバーが有効期限、許可範囲、対象APIなどを検証する
条件を満たしていれば、要求された処理を許可する

HTTPリクエストでは、次のように Authorization という項目へ付けて送る方式がよく使われる。これは「Bearer（持参人）方式」と呼ばれ、「このトークンを持っている人を正規利用者とみなす」という意味になる。

GET /api/profile HTTP/1.1
Host: example.com
Authorization: Bearer eyJhbGciOiJIUzI1Ni... (省略)

有効期限とリフレッシュトークン

アクセストークンには有効期限を設定するのが一般的である。具体的な長さはサービスやリスクによって異なるが、必要以上に長くしないことで、漏えい時に悪用される期間を抑えられる。

期限が切れるたびに利用者へ操作を求めると不便なため、「リフレッシュトークン」を使って新しいアクセストークンを取得する構成もある。ただし、すべてのサービスがリフレッシュトークンを発行するわけではない。

リフレッシュトークンが漏れると、新しいアクセストークンを取得される危険がある。公開クライアントでは、送信元を制約する仕組みや、使用するたびに新しい値へ交換して再利用を検知する「リフレッシュトークンローテーション」などの対策が重要になる。

JWTという形式

アクセストークンの形式は一つではない。サーバー側で内容を参照する不透明なランダム文字列の場合もあれば、JWT（ジョット、JSON Web Token）のように、トークン自体へ情報を持たせる形式の場合もある。「アクセストークン＝JWT」ではない。

署名付きJWTでは、署名、発行者、対象API、有効期限、権限の範囲などを適切に検証する必要がある。署名は改ざん検知のためのもので、中身を秘密にする暗号化とは別である。一方、JWTには暗号化された形式も存在するため、「JWTは必ず読める」とも限らない。いずれの場合も、不要な秘密情報をトークンへ含めるべきではない。

APIキーとの違い

アクセストークンはAPIキーと混同されやすいが、性格が違う。ざっくり整理すると次のようになる。

種類	主な性格	有効期限	主な使い手
アクセストークン	許可されたAPI・操作・期間などを表す認可情報	有効期限を持つことが多い	利用者の代理となるアプリ、またはアプリ自身
APIキー	APIを利用するプロジェクトやアプリなどを識別する情報	サービスの設計による	アプリやサーバー

どちらも漏えい対策が必要だが、役割はサービスによって異なる。名前だけで安全性や権限を判断せず、発行元の仕様、有効期限、許可範囲、失効方法を確認する必要がある。

どこに保管するかが重要

アクセストークンは通行証なので、保管場所を誤ると漏えいする。一般的には次のような点に注意する。

BFF（Backend for Frontend）構成などでセッション用のCookieを使う場合は、HttpOnly、Secure、適切なSameSite設定やCSRF対策を組み合わせる
フロントエンドのJavaScriptから読める保存領域へ長期間置くと、XSSによって盗まれる危険がある
ログやURLのクエリ文字列にトークンを残さない（履歴やアクセスログから漏れるため）
不要になったトークンは無効化（失効）できる仕組みを用意する

最適な保管方法は、サーバー中心のWebアプリ、SPA、モバイルアプリなどの構成によって異なる。Cookieへアクセストークンを直接保存すれば常に安全になるわけではないため、利用する認証基盤の公式ガイドと脅威モデルに合わせて設計する。

AIコーディングとの関係

AIにログイン機能やAPI連携のコードを書いてもらうと、アクセストークンの発行・保存・送信を含むコードが出てくることが多い。意味を理解していないと、トークンを安全でない場所に保存するコードをそのまま使ってしまう危険がある。

AIへ依頼するときは、保管方法やセキュリティ要件まで具体的に伝えるとよい。

OAuth 2.0を使うブラウザアプリの認可処理を設計してください。
BFF構成とSPA単体構成の違い、XSS・CSRF・トークン漏えいのリスクを比較し、
採用する方式、有効期限、権限範囲、失効方法の理由も説明してください。

また、AIにエラー相談をするときに、本物のアクセストークンを貼ってはいけない。トークンは有効期限内ならそのまま悪用できてしまう。エラーメッセージ、使っている認証方式、該当コードの構造だけを共有し、トークンの値は Bearer ...REDACTED のように伏せること。

よくある勘違い

アクセストークンとAPIキーは同じもの？

同じではない。APIキーはプロジェクトやアプリなどの利用元を識別する目的で使われることが多い。一方、アクセストークンは許可されたAPI、操作、期間などを表す認可情報である。ただし具体的な役割はサービスごとに異なるため、発行元の仕様を確認する必要がある。

アクセストークンは暗号化されているから中身は見られない？

そうとは限らない。署名付きJWTは中身を読み取れることが多いが、暗号化されたJWTも存在する。また、アクセストークンがJWTではなく不透明な文字列の場合もある。形式にかかわらず、不要な秘密情報を含めず、安全に扱う必要がある。

一度発行したら期限まで安全？

期限内でも、盗まれれば悪用される。だからこそ期限は短く設定され、漏えいに気づいたら失効させる仕組みが用意される。「期限内＝絶対安全」ではない。

トークンをURLに付けて渡しても大丈夫？

避けるべきである。URLはブラウザ履歴、サーバーのアクセスログ、リファラなどに残りやすく、そこからトークンが漏れることがある。Bearerトークンは、原則としてHTTPS上の Authorization ヘッダーで送る。

まとめ

アクセストークンは、許可されたAPI・操作・期間などを表す認可情報である。
Bearerトークンは、所有者が利用できる性質を持つため、保存時・通信時の漏えい対策が必要である。
アクセストークンの形式はJWTとは限らず、不透明な文字列の場合もある。
有効期限、権限範囲、対象APIを必要最小限にし、必要に応じて失効やリフレッシュトークンの保護を行う。
保管方法はアプリ構成によって異なるため、Cookieやブラウザ保存領域を一律に選ばず、脅威モデルに基づいて判断する。

情報ソース

より詳しくAIに聞いてみよう

アクセストークンとは何かを、中学生でもわかるように例えつきで説明してください。
アクセストークンとAPIキーの違いを、初心者向けに整理してください。
アクセストークンとリフレッシュトークンの役割分担を、具体例つきで教えてください。
JWT（JSON Web Token）の中身と署名の仕組みを、初心者向けにやさしく説明してください。
アクセストークンを安全に保管する方法（Cookieの属性など）を教えてください。