Webアプリケーションと認証

Webアプリケーションの中には、ユーザ名とパスワードを使ってログインを行ってから機能が利用できるようになるものがあります。認証を行うことによって、誰がWebアプリケーションを使っているかが明確になり、権利を持った利用者にのみ、特定の機能を利用させる、といったことが可能になります。ここでは、Webアプリケーションで認証の処理を行うための方法について考えてみたいと思います。

認証の基本

私たちは日常生活でさまざまな認証を行います。たとえば、キャッシュカードを使いキャッシュディスペンサーで現金を下ろすときには、暗証番号を使った認証を行います。家のドアを開け閉めするとき、鍵を使うのも一種の認証と言えるかもしれません。このように、自分以外の人間やモノに対して、何らかの手段を使って自分自身であることを認めてもらう行為のことを認証と呼びます。

認証を行うときには、他人や物体、プログラムなどに自分自身であることを認めてもらう必要があります。そのためには、第三者にも客観的に認めてもらえる「モノ」を使う必要があります。暗証番号、パスワード、鍵などはそのような「モノ」の例です。

Webアプリケーションでは、たいていユーザ名とパスワードを使って認証を行います。たとえば、ブログのようなWebアプリケーションには、2種類のユーザがいます。ブログを見る人と書く人です。すべてのユーザがブログの記事を書き換えられるのでは問題があります。どのユーザがブログを読む人で、どのユーザが書く人であるかをブログのWebアプリケーションが見分ける必要があります。そのために、ブログを書く人はユーザ名とパスワードを使ってブログにログインしてから、記事を書くわけです。

この場合は、ユーザ名とパスワードが第三者(Webアプリケーション)にも客観的に認めてもらえる「モノ」として機能していることになります。本人しか知り得ない情報を使って、本人であることを確認するのが認証の基本的な考え方です。

Webアプリケーションでの認証

Webアプリケーションはクライアントサーバモデルと呼ばれる仕組みで動きます。クライアントとなるWebブラウザなどと、実際に処理を行うプログラムは離れた位置にあって、ネットワークを通じて通信を行います。

認証に必要なユーザ名やパスワードなどのデータを送るのはクライアントです。それに対して、認証に必要なデータを評価し、正しいデータであることを評価するのはサーバ側にあるプログラムです。Webアプリケーションでは、リクエストとレスポンスが対応を作りながら処理を続けていきます。つまり、認証を行うときにも、リクエストとレスポンスを組み合わせながらデータや結果のやりとりを行う必要があるわけです。実際、Webアプリケーションの認証処理は、フォームを使った入力の遷移ととても似た形で進んでいきます。

認証状態の継続

もう1つ、Webアプリケーションの認証で考えなければならないことがあります。それは認証状態の継続についてです。

Webアプリケーションでは、リクエストとレスポンスのペアをやりとりしながら処理を進めていきます。認証を行うため、ユーザ名とパスワードをPOSTメソッドを使ってリクエストとして送ったとしましょう。そのリクエストに対応するレスポンスを作る際には、Webアプリケーションのプログラムは認証に必要なデータを得ることができます。しかし、ログインをしたあと、データを編集するために送ったPOSTのリクエストに認証に必要な情報が含まれていなかったら、プログラム側でどのようにしてログイン済みであることを判断すればよいでしょうか。何らかの方法を使って、リクエストを使ってユーザが認証状態であることを示せないと、毎回ユーザ名とパスワードをクエリを使って送信しなければならない、ということになってしまいます。

実際は、多くのWebアプリケーションでは、リクエストのヘッダの中に何らかの情報を埋め込んで認証状態を継続しています。Webアプリケーションでは、認証情報の送り方と、認証状態の継続の仕方によって、認証を行うための方法が何種類かに分かれます。