アクセストークン

概要（サマリー）

アクセストークンとは、ログインや認可を済ませた利用者・アプリに対して発行される、一定期間・一定範囲のアクセスを許可する一時的な「通行証」のような文字列のことである。

たとえば、テーマパークで入口の窓口にチケットとパスポートを見せて本人確認を済ませると、代わりにリストバンドを巻いてもらえる。それ以降は、各アトラクションでリストバンドを見せるだけで入場でき、毎回パスポートを出す必要はない。アクセストークンはこのリストバンドに近い。最初のOAuthによる認可などが済めば、その後のリクエストはトークンを提示するだけで通る。

毎回IDとパスワードを送らずに済むので安全性と利便性が高まる一方、トークン自体が「通行証」なので、盗まれると他人になりすまされてしまう。だから有効期限を短くしたり、安全な場所に保管したりといった扱いが重要になる。

詳細解説

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

Webサービスやアプリでは、ログイン後にも何度もサーバーへリクエストを送る。このとき毎回IDとパスワードを送る設計にすると、通信のたびにパスワードが流れることになり、盗み見のリスクが上がる。

そこで、最初の1回だけ本人確認（二要素認証を含むログインなど）を行い、成功したらサーバーがアクセストークンを発行する。以降はそのトークンを提示するだけで「すでに確認済みの相手だ」と判断できる。パスワードそのものを何度も露出させずに済むのが大きな利点である。

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

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

1. 利用者がIDとパスワードなどでログイン（またはOAuthで連携を許可）する
2. サーバーが本人確認に成功し、アクセストークンを発行して返す
3. アプリはトークンを保管する
4. 以降のリクエストでは、トークンを一緒に送る
5. サーバーはトークンを検証し、正しければ処理を許可する

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

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

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

アクセストークンには、たいてい短い有効期限が設定されている。数分〜数時間で切れることも多い。これは、万が一盗まれても悪用できる時間を短くするためである。

ただし、期限が切れるたびにログインし直すのは不便だ。そこで「リフレッシュトークン」という別のトークンをセットで発行する方式がよく使われる。アクセストークンが切れたら、リフレッシュトークンを使って新しいアクセストークンを取得し直す。役割を分けることで、利便性と安全性のバランスを取っている。

リフレッシュトークンは長めに使えることが多いため、漏れると新しいアクセストークンを繰り返し取得される危険がある。アクセストークン以上に厳重に保管し、必要に応じて失効できるようにしておくことが重要である。

JWTという形式

アクセストークンの中身の形式として、JWT（ジョット、JSON Web Token）がよく使われる。JWTは「利用者ID」「有効期限」「権限の範囲」などの情報を一定の形式でまとめ、改ざんを検知できる署名を付けた文字列である。

サーバーは署名を確認することで、「このトークンは自分が発行した正規のものか」「期限内か」を判断できる。なお、署名は改ざんを防ぐためのもので、中身を秘密にする暗号化とは別である。JWTの中身は誰でも読めることが多いため、パスワードのような秘密情報をトークンに入れてはいけない。

APIキーとの違い

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

どちらも秘密情報として扱う必要があるが、アクセストークンは「期限が来たら入れ替わる短期の通行証」、APIキーは「基本的に固定の鍵」とイメージすると違いをつかみやすい。

どこに保管するかが重要

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

• Cookieに保存する場合は、HttpOnly でJavaScriptからの読み取りを防ぎ、Secure でHTTPS通信に限定し、SameSite やCSRF対策で外部サイトから勝手に送られるリスクを下げる
• フロントエンドのJavaScriptから簡単に読める場所に長期間置かない
• ログやURLのクエリ文字列にトークンを残さない（履歴やアクセスログから漏れるため）
• 不要になったトークンは無効化（失効）できる仕組みを用意する

AIコーディングとの関係

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

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

ログイン後のアクセストークンは、JavaScriptから読めるlocalStorageではなく、
HttpOnly属性付きのCookieに保存する構成にしてください。
トークンの有効期限とリフレッシュトークンによる再取得も実装してください。

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

よくある勘違い

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

同じではない。APIキーは利用元を識別するための基本的に固定の鍵で、アクセストークンは認証・認可の結果として発行される短期間の通行証である。有効期限や使われ方が異なる。

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

そうとは限らない。JWT形式のトークンは署名で改ざんを検知できるが、中身自体は誰でも読めることが多い。秘密情報をトークンに含めてはいけない。

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

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

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

避けたほうがよい。URLはブラウザ履歴、サーバーのアクセスログ、リファラなどに残りやすく、そこからトークンが漏れることがある。基本は Authorization ヘッダーなどで送る。

まとめ

• アクセストークンは、認証・認可後に発行される一時的な通行証のような文字列である。
• リクエストごとにパスワードを送らず、トークンを提示してアクセス許可を確認する。
• 有効期限を短くし、必要に応じてリフレッシュトークンで再発行する設計がよく使われる。
• APIキーとは異なり、利用者や認可範囲に紐づく短期的な認証・認可情報として扱われる。
• 漏えいすると悪用されるため、保存場所、Cookie属性、ログ出力、URLへの付与に注意する必要がある。

情報ソース

• RFC 6750 — The OAuth 2.0 Authorization Framework: Bearer Token Usage（英語）
• RFC 7519 — JSON Web Token (JWT)（英語）
• OWASP Cheat Sheet Series - JSON Web Token Cheat Sheet

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

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