ログインすると届く3つのトークンを、見せる相手・確かめる人・期限・漏れたときの危なさ・置き場所の順に、1枚の図を動かしながら見ていきます。
ログインの仕組みを調べると、IDトークン・アクセストークン・リフレッシュトークンの3つが必ず出てきます。どれも「長い文字列」で、どれも「JWT」と呼ばれがちなので、違いがぼやけやすいところです。
いちばん大事な違いは、誰に見せるためのものかです。IDトークンはアプリに「誰がログインしたか」を伝えます。アクセストークンは API に「この API を使ってよいか」を示します。リフレッシュトークンは、トークンを出した窓口（認可サーバー）にだけ見せて、新しいトークンを取り直すために使います。
見せる相手が違えば、確かめる人も、期限も、漏れたときの危なさも、置き場所も変わります。この作品では、1枚の図を動かしながら、その5つを順に見ていきます。
例として、写真を見せるアプリ photo.example を考えます。あなたの写真は、別のサーバー api.example（API）に置いてあり、アプリはそこから写真を取ってきて表示します。
ログインを受け付けるのは、アプリでも API でもなく、login.example という窓口です。正式には認可サーバー（OpenID Connect では OpenID プロバイダー）と呼びます。Google や Microsoft、Auth0、Supabase Auth などが、この役をよく引き受けています。
図の右上が窓口、右下が API、左があなたのブラウザとアプリです。この先、トークンを出すのはいつも窓口で、受け取って使う側が3者いる、という形はずっと変わりません。
まず言葉を1つ整理します。JWT（JSON Web Token、RFC 7519）は、トークンの書き方の形式です。「IDトークン」「アクセストークン」が役割の名前であるのとは、話の段が違います。
JWT は、ドット（.）で区切った3つの部分でできています。ヘッダーには署名の方式、ペイロードには中身（「クレーム」と呼ぶ項目の集まり）、最後の署名には「上の2つを書き換えていない」ことの証拠が入ります。
3つのトークンのうち、IDトークンは必ず JWT です（OpenID Connect がそう決めています）。アクセストークンは JWT のこともあれば、意味の無い乱数のこともあります。リフレッシュトークンは、たいてい乱数です。だから「JWT のリフレッシュトークン」という言い方は、多くの場合あまり正確ではありません。
JWT の各部分は base64url という方式で文字に置き換えてあるだけです。元に戻すのに鍵は要りません。jwt.io のようなサイトに貼れば、誰でも中身を読めます。
中身はこのような JSON です。iss は発行した窓口、sub はログインした人の ID、aud は受け取る相手（audience）、exp は期限です。
署名が守ってくれるのは「書き換えていない」ことだけで、「読めない 」ことではありません。だから、パスワードや API の秘密鍵のような値はペイロードに入れません。読まれては困る情報を運びたいときは、暗号化した形式（JWE）という別の仕組みを使います。
exp は「1970年1月1日からの秒数」で書きます。図の 1792026900 は、日本時間の2026年10月15日 10時15分です。
JWT の署名は、多くの場合 RS256 や ES256 という方式で作ります。窓口は秘密鍵で署名し、それと対になる公開鍵を誰でも取れる場 所に置きます。この公開鍵の一覧を JWKS（JSON Web Key Set）と呼びます。
受け取る側（アプリや API）は、JWKS から公開鍵を取ってきて、署名が合うかを手元で確かめます。合えば「窓口が出したもので、途中で書き換えられていない」と分かります。1文字でも書き換えると署名は合いません。
ポイントは、確かめるたびに窓口へ問い合わせなくてよいことです。公開鍵は手元に置いておけるので、API はリクエストのたびに窓口と通信せずに済みます。速くて、窓口が止まっていても動けます。ただしこの「問い合わせない」性質が、あとで「取り消しにくい」という弱点にもなります。
なお、窓口と受け取る側が同じ秘密の値を共有する HS256 という方式もあります。この場合は確かめる側も署名を作れてしまうので、窓口と受け取る側が同じ組織の中にいるときに限って使います。
あなたがアプリの「ログイン」を押すと、ブラウザは窓口のページに移ります。ID とパスワードを入れるのは窓口のページで、アプリはあなたのパスワードを一度も見ません。これがこの仕組みのそもそもの目的です。
ログインがうまくいくと、窓口からアプリにトークンが届きます。OpenID Connect でログインし、オフラインアクセス（後で取り直すこと）も許可していれば、IDトークン・アクセストークン・リフレッシュトークンの3つです。
実際の手順では、間に「認可コード」の受け渡しが1回はさまります。窓口はまずブラウザ経由で短い使い捨てのコードをアプリに渡し、アプリが裏の通信でそのコードをトークンに引き換えます。トークンそのものをブラウザのアドレス欄に通さないための工夫です。この作品ではそこを省いて、「3つ届く」から話を進めます。
IDトークンは OpenID Connect が決めたトークンで、窓口がアプリに宛てて書いた「この人がログインしました」という証明書です。
中で大事なのは3つです。sub はこの人の ID で、窓口の中で変わらない番号です（メールアドレスは変わることがあるので、人を見分けるには sub を使います）。aud は受け取るアプリ自身の ID（client_id）です。nonce は、アプリがログインを始めるときに作って窓口に渡した合言葉で、IDトークンにそのまま書き戻されてきます。
名前やメールアドレスのような個人の情報が入ることもあります。中身は誰でも読めるので、そのぶん、漏れたときには個人情報が漏れたことになります。
IDトークンを確かめるのはアプリです。少なくとも次の5つを見ます。
署名が、窓口の JWKS にある公開鍵で合うこと。iss が、ログインを頼んだ窓口（login.example）であること。aud に自分の client_id が入っていること。exp を過ぎていないこと。nonce が、自分がログインを始めたときに作った値と同じであること。
aud を見ないと、別のアプリ宛てに出された IDトークンを持ち込まれたときに通してしまいます。nonce を見ないと、以前に盗まれた IDトークンを使い回されても気づけません。どれも省いてよい項目ではありません。自分で書かず、窓口が勧めるライブラリに任せるのが安全です。
5か所を確かめたら、アプリは「この人は user_8f2a だ」と分かります。ここでIDトークンの役目はほぼ終わりです。
この先ログインの状態を覚えておくのは、アプリ自身のセッションです。アプリは自分のサーバーに「このセッションは user_8f2a」と記録し、ブラウザにはその番号を入れた Cookie を渡します。次からは、この Cookie でログイン中だと分かります。
よくある誤解は「IDトークンの exp が切れたらログアウトになる」というものです。IDトークンの 期限は「ログインした、という証明書」としての期限で、ログインの状態がいつまで続くかはアプリのセッションが決めます。
写真を取りに行くとき、アプリは API へのリクエストにアクセストークンを付けます。Authorization: Bearer に続けて書くのが決まった形です（RFC 6750）。
アクセストークンは、建物の入館証に近いものです。受付（窓口）で一度もらえば、あとは部屋（API）に入るたびに見せるだけです。部屋の側は、入館証が本物で期限内かを見れば、受付に電話して確かめる必要はありません。
アクセ ストークンが JWT でない（ただの乱数の）場合は、API は手元では確かめられないので、窓口のイントロスペクション（RFC 7662）という口に「このトークンはまだ有効か」を問い合わせます。こちらは毎回問い合わせが要るかわりに、窓口で無効にした瞬間から通らなくなります。
アクセストークンを確かめるのは API です。JWT の場合、確かめ方は IDトークンとよく似ています。署名、iss、exp を見て、`aud` が自分（https://api.example） であることを確かめます。
違いは、最後に `scope`（範囲）を見ることです。このトークンは photos:read（写真を読む）だけを許しています。写真を消すリクエストに使われたら、API は断ります。アクセストークンが答えるのは「誰か」よりも「この API を、この範囲で使ってよいか」です。
署名の方式（ヘッダーの alg）は、API の側で決め打ちしておきます。トークンに書いてある方式をそのまま信じると、none（署名なし）や、公開鍵を共有の秘密として使わせる手口で、偽のトークンを通してしまうことがあります。
「Bearer」は「持参人」という意味です。アクセストークンは持参人払いの小切手のようなもので、持っている人が誰であっても使えます。API には、正しい持ち主が送ってきたのか、盗んだ人が送ってきたのかの見分けがつきません。
だから、アクセストークンが漏れると、期限が来るまで、あなたになりすまして API を使われます。ログやエラー画面にトークンを書き出してしまう、URL のクエリに載せて履歴やリファラに残る、ブラウザに紛れ込んだスクリプトに読まれる、といった経路があります。
これを防ぐ仕組みとして、トークンを特定の鍵の持ち主に縛る方式もあります（DPoP、RFC 9449）。盗まれても、対になる秘密鍵が無ければ使えません。ただ、まずは「漏らさない」「漏れても短い」が基本です。
JWT のアクセストークンは、API が手元だけで確かめられるのが長所でした。裏を返すと、窓口で「このトークンは無効にした」と決めても、API はそれを知りません。期限（exp）が来るまでは通ってしまいます。
図は、10時に発行したトークンが10時5分に漏れた場合です。期限が15分なら、悪用できるのは10分で終わります。期限が24時間なら、翌日の10時まで悪用され続けます。
取り消しの一覧（拒否リスト）を API に配って、期限前でも止める作り方もあります。ただ、それでは「問い合わせなくてよい」長所が薄れます。多くの場合は、アクセストークンの期限を短くし、期限が来たら取り直すほうを選びます。その取り直しに使うのが、リフレッシュトークンです。
期限は仕様では決まっておらず、窓口の設定で決まります。短いほど漏れたときの被害は小さく、そのぶん取り直しの回数が増えます。
よくある目安は、IDトークンが数分〜1時間、アクセストークンが5分〜1時間です。たとえば Google はアクセストークンも IDトークンも1時間、Supabase Auth はアクセストークンが既定で1時間です。
リフレッシュトークンは数日から、期限なしまで幅があります。Google のリフレッシュトークンには決まった期限がなく、6か月使われないと失効します。Supabase Auth のリフレッシュトークンも時間では切れず、1回使うと使えなくなります。長く生きるかわりに、使い方で切れる仕組みを持たせるのがふつうです。この「使い方で切れる」がどう働くかは、少し後で見ます。
アクセストークンの期限が切れると、API は 401（認証が必要）を返します。するとアプリは、リフレッシュトークンを窓口に出して、新しいアクセストークンをもらいます。
このとき、あなたにパスワードをもう一度聞く必要はありません。画面の裏で取り直しが済むので、あなたから見ると「ずっとログインしたまま」に見えます。短い期限と使い勝手を両立させるのが、リフレッシュトークンの役目です。
401 を待たずに、exp が近づいたら先に取り直しておく作りもよく使われます。どちらにしても、リフレッシュトークンを受け取るのは窓口だけです。API に見せることはありません。
リフレッシュトークンは、窓口のトークン発行の口（/token）に送ります。中身はたいてい意味の無い乱数で、窓口が自分の台帳（データベース）で「誰の、どのアプリの、いまも有効なトークンか」を引くための番号札です。
確かめるのは窓口です。台帳にあるか、取り消されていないか、そして送ってきたアプリが本当にそのアプリかを見ます。サーバーで動くアプリなら、窓口に登録した秘密の値（クライアントシークレット）なども一緒に出すので、リフレッシュトークンだけを盗んでも使えません。
台帳にある以上、窓口はいつでも1枚ずつ取り消せます。アクセストークンが「取り消しにくい」のと正反対です。長く生かすものだから、取り消せる形で持たせているわけです。
一方で、ブラウザやスマホのアプリは、秘密の値を安全に持てません（配ったアプリの中身は誰でも覗けるからです）。こうしたアプリでは、リフレッシュトークンだけで新しいアクセストークンを取り直せてしまいます。
その場合、リフレッシュトークンが漏れると、攻撃者は自分で新しいアクセストークンを何度でも作れます。アクセストークンを短くした意味が、まるごと無くなります。アクセストークンの写しは期限で止まりますが、リフレッシュトークンの写しは、誰かが気づいて止めるまで止まりません。
そこで窓口の側には、リフレッシュトークンが盗まれても被害を広げないための仕組みが求められます。OAuth のセキュリティの指針（RFC 9700）は、ブラウザやスマホのアプリに出すリフレッシュトークンについて、次の「入れ替え」か、鍵の持ち主に縛る方式（DPoP など）のどちらかを求めています。
リフレッシュトークンの入れ替え（ローテーション）では、リフレッシュトークンを使うたびに、新しいアクセストークンと一緒に新しいリフレッシュトークンが返ってきます。古いほうはそこで使用済みになり、二度と通りません。
窓口は、同じログインから続く一連のリフレッシュトークンを1つの系列として覚えていて、「いまの1枚」がどれかを知っています。アプリは、毎回届く新しい1枚に差し替えて持ち続けます。
これだけだと、盗んだ人が持ち主より先に使えば、盗んだ人のほうが「いまの1枚」を手に入れてしまいます。そこで次のページの仕組みと組み合わせます。
入れ替えをしていると、持ち主と攻撃者が同じ1枚を持っている状態は長く続きません。どちらかが先に使えば、もう一方が持っているのは使用済みの1枚になります。
そこで窓口は、使用済みのリフレッシュトークンが届いたら、盗まれたと判断して、その系列をまるごと取り消します。図では、攻撃者が使用済みの 1 を出したので、いまの 3 も取り消しになりました。
持ち主もログインし直しになりますが、攻撃者を締め出せます。どちらが本物か窓口には分からないので、両方とも止めるのが安全な側の倒し方です。Auth0 や Supabase Auth など、多くの窓口がこの検出を備えています。
ここまでくると、よくある間違いが見えてきます。IDトークンをアクセストークンの代わりに API に送ることです。どちらも JWT で、どちらにも sub が入っているので、つい使えそうに見えます。
しかし IDトークンの aud はアプリ（photo.example）で、API 宛てではありません。API が aud を確かめていれば、401 で断るのが正しい動きです。別のアプリ宛ての IDトークンを持ち込まれても通してしまう、という穴を作らないためです。
JWT 形式のアクセストークンには、ヘッダーの typ を at+jwt にする決まりもあります（RFC 9068）。API がこれも確かめれば、IDトークンを取り違える余地はさらに減ります。
ここまでを「漏れたらどうなるか」で並べ直すと、図のようになります。
いちばん危ないのはリフレッシュトークンです。長く生き、何度でも新しいアクセストークンに換えられるので、止めるまで被害が続きます。次がアクセストークンで、期限が来るまで、あなたとして API を使われます。
IDトークンは、正しく作られたシステムでは API の鍵にはならないので、漏れて起きるのは 主に名前やメールアドレスが読まれることです。ただし、前のページの間違い（API が IDトークンを受け入れている）があると、アクセストークンと同じ危なさに変わります。
扱い方の基本は「長く生きるものほど、手の届かない場所に置く」です。
ブラウザの localStorage は便利ですが、ページの中で動く JavaScript なら何でも読めます。ページに悪意のあるスクリプトが紛れ込む（XSS）と、そこにあるトークンはそのまま持ち出されます。期限の短いアクセストークンなら被害も短く済みますが、リフレッシュトークンを置くと、被害は止めるまで続きます。
リフレッシュトークンは、アプリのサーバー側に置くか、ブラウザに置くなら HttpOnly の Cookie にします。HttpOnly を付けた Cookie は JavaScript から読めません。HTTPS でだけ送る Secure と、よそのサイトからの送信を絞る SameSite も付けます。どのトークンも、URL やログには書き出しません。
いまブラウザのアプリに勧められている形が BFF（Backend for Frontend）です。アプリの側に小さなサーバーを1つ置き、トークンはすべてそのサーバーが持ちます。
ブラウザに渡るのは、HttpOnly のセッションの Cookie だけです。ブラウザがアプリのサーバーに頼むと、サーバーが自分の持っているアクセスト ークンを付けて API を呼び、期限が切れればサーバーがリフレッシュトークンで取り直します。ブラウザの JavaScript には、どのトークンも一度も渡りません。
IETF のブラウザ向けアプリの指針（草案）も、いちばん安全な形としてこの BFF を挙げています。サーバーを置けない場合でも、少なくともリフレッシュトークンの入れ替えを使い、アクセストークンはメモリ（変数）にだけ置く、というところまでは守ります。
ログアウトでやることは3つです。窓口の取り消しの口（revocation、RFC 7009）にリフレッシュトークンを送って無効にすること。アプリ自身のセッションを消すこと。ブラウザの Cookie を消すことです。
リフレッシュトークンは台帳にあるので、取り消せばその場で使えなくなります。一方、手元に残ったアクセストークンは、JWT であれば期限まで通ります。図では、残りの9分は API に通ってしまいます。
ここでも、アクセストークンの期限を短くしておく理由が効いてきます。「ログアウトしたのに、しばらく使える」時間を短くできるのは、期限の長さだけです。
3つとも、出すのは窓口（認可サーバー）です。違うのは、見せる相手と、確かめる人です。
IDトークンは、アプリが「誰がログインしたか」を知るためのもので、アプリが確かめ、確かめたらアプリのセッションに置き換えます。アクセストークンは、API が「使ってよいか」を判断するためのもので、API が確かめます。期限は短く、持っている人なら誰でも使えます。リフレッシュトークンは、アクセストークンを取り直すためのもので、窓口だけが確かめます。長く生きるので、漏れたときに一番危なく、入れ替えと取り消しで守ります。
扱い方は「長く生きるものほど、ブラウザから遠ざける」「IDトークンを API に送らない」「署名だけでなく aud と exp まで確かめる」の3つを覚えておけば、大きく外すことはありません。
ログインするとコメントできます。
読み込み中…
権利侵害・不適切な内容の連絡: [email protected]