ログイン機能の作り方を調べていると、「クッキーとセッション」の話のあとに、当たり前のように「トークン認証」や「JWT」という言葉が出てきます。スマホアプリやモダンなWebサービスでは、こちらのほうが主流になりつつあります。でも、名前だけ聞くと難しそうで、セッションと何が違うのか分かりにくいところです。
結論から言うと、トークン認証とは「ログイン済みであることを証明するパスポートのようなトークンを、通信のたびに一緒に送って本人確認する方式」です。この記事では、その仕組みと、昔ながらのセッション認証との違い、JWTの正体、なぜ今トークンが増えたのか、そして盗まれたときのリスクと対策まで、専門用語を噛み砕いて整理します。
結論：トークンは「ログイン済みを証明するパスポート」
トークン認証の流れは、旅行のパスポートに例えると分かりやすいです。
- ユーザーがIDとパスワードでログインに成功する。
- サーバがそのお礼として「トークン」という証明書を発行して渡す。
- ブラウザやアプリは、このトークンを自分の手元に保存しておく。
- 次回以降、ページを開いたりデータを取りに行くたびに、このトークンを一緒に送る。
- サーバは送られてきたトークンを見て、「これは誰のもので、まだ有効か」を確認し、ログイン状態だと判断する。
一度パスポートを受け取れば、入国のたびにパスポートを見せるだけで通れます。毎回パスポート発行窓口まで並び直す必要はありません。トークン認証も同じで、ログインは最初の1回だけ。あとは手元のトークンを提示し続けることで、ログインした状態が保たれます。
前提となるクッキーやセッションの基礎は、Cookieとはであわせて確認しておくと、この先の違いがすっきり理解できます。
セッション認証との違い：名簿を持つか、毎回証明書を確認するか
トークン認証を理解する近道は、昔ながらの「セッション認証」と並べて比べることです。どちらも目的は同じで「ログイン中の人を見分ける」ことですが、見分け方が違います。
セッション認証は、サーバ側が「今ログインしている人の名簿」を持つ方式です。ログインした人ごとに管理番号を振って名簿に書き留め、ブラウザには番号だけを渡します。次回はその番号を受け取り、サーバが名簿を照らし合わせて「ああ、この人ね」と確認します。詳しくはWebのログイン機能はどう作られている?で扱っています。
一方トークン認証は、サーバが名簿を持ちません。トークンそのものに必要な情報を持たせておき、送られてきたトークンが本物かを毎回その場で確認するだけです。
| 観点 | セッション認証 | トークン認証 | |---|---|---| | 誰の情報を、どこが覚える | サーバが名簿として覚える | トークン自体が情報を持ち、サーバは覚えない | | 毎回の確認 | 名簿と照合する | 送られたトークンが正しいか検証する | | サーバを増やしたとき | 名簿の共有が必要で手間 | 検証方法が同じなら使い回しやすい | | 主に向く場面 | 1つのWebサイトの中で完結 | アプリや複数サービスをまたぐ |
JWTとは：トークンの代表的な形式
トークン認証の話でよくセットで出てくるのが「JWT」です。ジョット、またはジェイダブリューティーと読みます。難しく身構えなくて大丈夫で、JWTは「トークンの代表的な書き方(形式)の一つ」だと思ってください。
JWTの中身には、たとえば次のような情報が詰められています。
- 誰のトークンか(ユーザーを識別する情報)
- いつまで有効か(有効期限)
- 発行したのはどこか
そしてJWTには「電子的なサイン(署名)」が付いています。これがあることで、もし誰かがトークンの中身を書き換えて「自分は管理者だ」などと偽ろうとしても、サインが合わなくなり、改ざんに気づける仕組みになっています。
つまりJWTは、中身を見れば誰の何かが分かり、かつ書き換えられていないかを確かめられるパスポート、というイメージです。サーバが名簿を持たなくても本人確認できるのは、この署名付きの仕組みがあるからです。
なぜ今トークン認証が増えたのか
昔は1つのWebサイトの中でログインが完結していたので、サーバが名簿を持つセッション認証で十分でした。では、なぜ今トークン認証が広がったのでしょうか。理由は、Webの使われ方が変わったからです。
- スマホアプリが当たり前になった。アプリはブラウザの外で動くので、ブラウザ前提のクッキーより、手元に持って毎回送れるトークンが扱いやすい。
- ページを切り替えずに動くWebアプリ(SPAと呼ばれる形)が増え、画面の裏で頻繁にデータをやり取りするようになった。
- 1つのサービスが、認証・決済・地図など複数のサーバやAPIに分かれて連携するようになった。
こうした構成では、サーバが1人ずつ名簿で覚える方式だと、サーバを増やしたときに名簿の共有が重荷になります。トークンなら、それぞれのサーバが同じやり方でトークンを確認できるので、規模が大きくなっても仕組みが増えすぎず、身軽に広げやすいのです。APIをまたいだ連携そのものについては、APIとはもあわせて読むと立体的に理解できます。
注意点とリスク：パスポートは盗まれると悪用される
便利な一方で、トークンには気をつけるべき弱点があります。それは「トークンが盗まれると、なりすまされてしまう」ことです。
パスポートを落として拾われると、拾った人があなたのふりをして入国できてしまうのと同じです。トークンは「ログイン済みの証明」そのものなので、盗んだ人はパスワードを知らなくても、そのトークンを送るだけであなたとして操作できてしまいます。
被害を抑えるために、実際のサービスでは次のような工夫がなされています。
- 有効期限を短くする。パスポートに期限を設け、盗まれても短時間で使えなくする。
- 更新の仕組み(リフレッシュ)を用意する。期限が切れたら、裏で安全に新しいトークンを発行し直し、ユーザーは何度もログインし直さずに済むようにする。
- 2段階認証を組み合わせる。トークンだけでなく、スマホ通知やコードなど「もう一つの確認」を足して、なりすましを起きにくくする。
- 保存場所に気をつける。トークンを、悪意あるスクリプトから読み取られにくい場所に置く。
初心者がAI開発でやりがちな誤り
最近は、生成AIに手伝ってもらいながらログイン機能を作る人が増えました。ここでつまずきやすいのが、認証まわりの落とし穴です。動くものはできても、安全でない作りになっていることがあります。
- トークンを安全でない場所に置いてしまう。とりあえず動かすことを優先して、外から読み取られやすい場所に保存したまま公開してしまう。
- 有効期限を無限にしてしまう。期限切れの再ログインが面倒だからと期限を外すと、一度盗まれたトークンがいつまでも使える状態になる。
- 期限切れの処理を作り込まない。トークンが切れたときの案内や更新の流れがなく、ユーザーが突然操作できなくなる。
AIは「動くコード」を素早く出してくれますが、「どこまで安全に配慮すべきか」までは、こちらが問いを立てないと出てきにくいものです。認証と、認証と混同しやすい「認可(権限)」の考え方は、AIで作ったアプリのサーバは安全か(認証と認可)で具体的に整理しています。
次の一歩
トークン認証は、クッキーとセッションの基礎を押さえたうえで学ぶと、違いがくっきり見えてきます。まだセッションのイメージが曖昧なら、CookieとはとWebのログイン機能はどう作られている?を先に読んでおくと、この記事の比較がより腹落ちします。そのうえで、AIで作ったアプリのサーバは安全か(認証と認可)に進むと、認証まわりの安全性まで一続きで理解できます。
まとめ
- トークン認証とは、ログイン済みを証明するパスポートのようなトークンを、通信のたびに送って本人確認する方式。
- セッション認証はサーバが名簿を持って照合するのに対し、トークン認証はトークン自体に情報を持たせ、毎回その場で検証する。
- JWTはトークンの代表的な形式。中身に誰・期限などの情報を持ち、署名で改ざんに気づける。
- スマホアプリ・SPA・複数サービス連携が増え、サーバに状態を持たない身軽さから広がった。
- 盗まれるとなりすましにつながるため、有効期限を短く、更新の仕組み、2段階認証、保存場所への配慮とセットで使うのが基本。
独学でつまずきやすいのは、トークンやセッションといった知識そのものよりも、それを「何をどの順番で学ぶか」です。ログインの仕組みから安全な作り方まで、あなたの目標から逆算した学ぶ順番の一部として、1対1で一緒に整理できます。
