「認証の維持」といわゆる「セッション管理」とはちょっと違う。

一般的なユーザー認証では、サーバー側にIDとパスワード（のハッシュ）という情報を持ち、ユーザーがフォームから入力したIDとパスワードの組み合わせを、サーバーの持つ情報と照合することによって認証処理を行う。

ただし、毎回フォームでIDとパスワードを入力するのは面倒なんで、一度入力したIDとパスワードは、2回目以降いちいち入力せずに認証処理を行いたい。要するに一度入力されたIDとパスワードを覚えておいて使い回したい。

BASIC認証とかのブラウザが対応している認証方式の場合は、ブラウザの機能として覚えてくれる。そして、アクセスのたびにIDとパスワード（のBASE64エンコード）が送られ、毎回認証処理が行われる。ちなみにBASIC認証で送られるパスワードのBASE64エンコードは可逆なので、パスワードを平文で送っているのと大して変わらない。

ブラウザの標準機能を使わず認証を行う場合は、Webの標準的な機能を使ってIDとパスワードを覚えておかないといけない。そこでCookieが使われることになる。IDとパスワード（平文あるいはBASE64のような可逆エンコード）を覚えておくというのが一番単純なやり方（初回にフォームからIDとパスワードが送られたときと同じ照合コードが使える）だけど、ちょっと安全性を高めたければ、IDとパスワードのハッシュ（非可逆）を覚えておく。

サーバーサイドには、IDとパスワード（のハッシュ）の組み合わせしか認証チェック用の情報を持たないことが前提なんで、ブラウザから送られる情報は、サーバーに保存されているIDとパスワード（のハッシュ）を使って照合可能なデータである必要がある。

一方（いわゆる）セッション管理というのは、基本的には認証とは関係なく、単にあるブラウザからの連続したアクセスを同定し、複数回のアクセスにおいて状態（データ）をサーバー上で保持（認識）したい、という話だ。

そのためには、あるブラウザからのアクセスを特定するために、ブラウザごとにユニークな識別IDを割り振り、それを使用する。それがセッションID。そのセッションIDも基本的にはCookieに保存することになる。

セッションIDはユニークであれば連番とかで生成してもいいけど、連番で生成したセッションIDの場合、他の人のセッションIDが類推できてしまう。たとえば自分のセッションIDが100だったら、「きっと99とか101とかの人もいるに違いない」とか。だから、セッションIDはできるだけ類推の効かない（ランダム性の高い）ものを使うことで、安全性を高める必要がある。

セッション管理を使えばあらゆる状態を維持することができるんで、もちろん認証の維持にも使うことができる。セッション管理の仕組みを認証の維持に使うことによって、IDやパスワードと直接結びつくデータを毎回送信する必要がなくなり、安全性が高まる。

またいわゆるセッション管理機能を使わない場合でも、直接IDやパスワードと結びつかないランダムでユニークな認証キーをサーバー側で生成し、サーバー上でIDと結びつけておくと同時に、ブラウザにその認証キーを覚えてもらう。そして、その認証キーを利用して認証処理を行うことによって、直接IDやパスワードに結びつく情報のやりとりを最小限に抑えることにより、安全性を高めることができる（他にも方法はいろいろある）。

ただし、セッションIDやランダムな認証キーを利用する場合でも、直接IDやパスワードと結びつくデータが流れないというだけで、セッションIDやランダムな認証キー自体が直接認証機能と結びつき、それを悪用されることで認証処理を乗っ取られることに代わりはない。

また、せっかくセッションIDやランダムな認証キーを利用していても、その有効期間が必要以上に長い場合は、結局その文字列自体をパスワードのように利用することができ、セッションIDやランダムな認証キーを使っているからより安全だ、とは言い切れない。もちろんCookieが漏れるような設計だったら、セッションIDやランダムな認証キーを利用していても意味がない。

って俺は毎日なんでこんな文章を書いているんだろうなー。

ところで、JavaScript必須でチャレンジ＆レスポンスとかやっている例ってあるのかな？とふと思った。