ログインするとなぜずっとログイン状態のままなのか — Cookie、セッション、トークン

ウェブサイトに一度ログインすると、そのあとはページをあちこち移動しても、ログイン状態がそのまま維持されます。カートに入れた商品も残っていて、自分の名前も画面の上にずっと表示されています。当たり前すぎて、疑問に思ったことがないかもしれません。ところが実は、これは勝手に起きることではありません。

「なぜ何度もログアウトされるの」「自動ログインはどうなっているの」「Cookie をブロックすると、なぜログインできないの」といった質問の答えは、すべて一つの束につながっています。この記事では、ログイン状態が維持される仕組みを、Cookie、セッション、トークンという三つの言葉で解きほぐしていきます。コードは出てきません。

ウェブはもともと、さっき見た人さえ覚えていません #

まずは意外な事実から押さえます。ウェブは基本的に、ユーザーを覚えないように作られています。

ウェブブラウザとサーバーは、HTTP という約束で会話します。ところが、この会話には変わった性質があります。リクエスト一つ一つを、互いに別物として扱うという点です。さっきある画面を見せたサーバーでも、すぐ次のリクエストが入ってくると、その人を初めて見る客のように扱います。直前に何があったかを、基本的には覚えていません。

この性質のおかげでウェブは単純で丈夫に動きますが、そのままにしておくと困った点が出てきます。ログイン画面で ID とパスワードを正しく入れても、次の画面に移った瞬間、サーバーはその人が誰だったかを忘れてしまいます。ページを移るたびにもう一度ログインしなければならないなら、誰もそんなサービスは使わないでしょう。だから「この人はさっきログインしたあの人だ」という事実を、どこかに持ち歩かせる方法が必要です。

Cookie は、ブラウザが保管する小さなメモです #

この問題を解く最初の道具が Cookie です。Cookie は、サーバーがブラウザに手渡す小さなメモだと考えればよいです。

ログインに成功すると、サーバーは「この人は確認済み」という印が入ったメモをブラウザに手渡します。ブラウザはこのメモを受け取って保管しておき、同じサイトにリクエストを送るたびに、自動的に一緒に差し出します。サーバーは入ってきたリクエストについたメモを見て、さっきのあの人だと気づきます。ページを移ってもログインが維持されるのは、このメモがリクエストごとについて回るからです。

遊園地の入り口で手首に巻いてくれるバンドに似ています。一度入場を確認されてバンドをつければ、中で乗り物に乗るたびにチケットを切り直さなくても、手首を見せれば足ります。Cookie をブロックするとログインできない理由もここにあります。バンドを受け取るのを拒んだようなもので、サーバーが毎回誰なのかを確かめるすべがなくなります。

セッションは、情報をサーバーが持ち、番号札だけを手渡します #

Cookie に何を入れるかによって、方式が分かれます。その一つがセッションです。

セッション方式では、大事な情報をサーバーが直接保管します。誰がログインし、どんな権限を持っているかをサーバー側の保管庫に入れておき、ユーザーに手渡す Cookie には、その保管庫を指す番号札だけを入れます。服屋にコートを預けて、番号札だけを受け取るのと同じです。コートにあたる実際の情報は店が保管し、客は番号札だけを持ち歩いて、出るときに差し出します。この番号札をセッション ID と呼びます。

この方式の長所は、コントロールしやすいことです。サーバーが情報を握っているので、問題が起きればその番号札を無効にして、すぐにログアウトさせられます。その代わり、ユーザーが増えると、サーバーが保管すべき情報も一緒に増えていきます。

トークンは、情報をユーザーに持ち歩かせます #

もう一つの方式がトークンです。セッションと反対に、情報をサーバーが握る代わりに、ユーザーにまるごと持たせて送り出します。

ログインに成功すると、サーバーは「この人は誰で、何ができる」という内容が入った札を発行します。この札がトークンです。ユーザーはそのあとリクエストごとにこの札を一緒に差し出し、サーバーは札が偽造されていない本物かどうかだけを確認すればよいのです。客が情報を自分で持ち歩くので、サーバーは別に保管庫を持たなくてもよくなります。

ここで当然の心配が出てきます。ユーザーが持ち歩く札なら、内容を好きなように書き換えられるのではないか、ということです。だからトークンには、偽造を見分ける封印が入っています。内容を少しでも変えると封印が壊れ、サーバーはすぐに偽物だと気づきます。よく使われるトークンの形式を JWT と呼びますが、名前まで覚える必要はありません。情報を検証できる形でユーザーが持ち歩く、という発想だけ覚えておけば十分です。

トークン方式は、サーバーが一人一人を逐一覚えなくてもよいので、規模を大きくするのに向いています。その代わり、一度渡した札は期限が切れるまで取り戻しづらく、強制ログアウトのようなコントロールはセッションより手がかかります。セッションとトークンのどちらを使うかは、こうした長所と短所を見比べて決めます。

だから、こんなことが説明できます #

この仕組みがわかると、ふだん経験していた色々なことが一度に解けます。

• 自動ログインのチェックボックス。 チェックすると、Cookie やトークンの有効期限を長く取るので、ブラウザを閉じて開き直しても、しばらくログインが維持されます。チェックしないと、たいていもっと短く維持されてから切れます。
• 急にログアウトされること。 有効期限が過ぎてメモや札が切れたか、セキュリティのためにサーバーがその情報を無効にした場合です。
• 共用パソコンの警告。 Cookie がそのまま残っていると、次の人がそのメモをそのまま使えてしまいます。だから共用パソコンではログアウトが大事です。
• セキュリティと HTTPS。 Cookie やトークンは、事実上の入場証です。やり取りの途中で誰かに横取りされると、その人が自分になりすませます。通信を暗号化する HTTPS が大事な理由がここにあります。

なぜ非開発者が知っておくと仕事が楽になるのか #

• ログインの問い合わせに正確に答えられます。 ログアウトが何度も切れるという問い合わせを受けたとき、有効期限や Cookie の設定など、確認すべき箇所を一緒に思い浮かべられます。
• バグをうまく報告できます。 どのブラウザで、自動ログインをつけていたか、いつから切れるのかを一緒に伝えれば、原因を探すのがずっと速くなります。
• 個人情報の感覚が身につきます。 Cookie やトークンが入場証だとわかれば、なぜむやみに共有してはいけないのか、なぜ HTTPS とログアウトが強調されるのかが、自然に理解できます。

まとめ #

一度ログインすれば状態が維持されるという当たり前の経験の裏には、ユーザーを覚えられないウェブを覚えさせる仕掛けが隠れています。ブラウザが自動的に持ち歩く Cookie、情報をサーバーが保管して番号札だけを手渡すセッション、情報を検証できる形でユーザーが持ち歩くトークンまで見てきました。

これらの仕掛けが結局は入場証だと覚えておけば、ログインとセキュリティをめぐる話がずっとはっきりします。ブラウザとサーバーがリクエストとレスポンスをやり取りする全体像が気になればAPI とは何かを、この情報を狙う攻撃がどう発展してきたかが気になればコンピューターウイルスとランサムウェアの歴史を一緒に読んでみることをおすすめします。