 |
|
| SledgeによるWebアプリケーションフレームワーク入門 |
第３回：認証
著者：ライブドア 池邉 智洋 2005/6/27
|
|
|
| 前のページ 1 2 3 4 次のページ
|
|
| Webアプリケーションでの認証
|
Webアプリケーションでの認証の一般的な流れとして、以下のような動作が想定されます。
|
- 認証が必要なエリアへのリクエストを試みる
- ログインフォームまたはベーシック認証のダイアログが表示される
- IDとパスワードを入力する
- ID、パスワードが一致した場合のみ（1）でリクエストしたページが表示される
- その後は「ログイン状態」となり、認証が必要なエリアが閲覧できる
|
表2：認証の流れ
|
前回説明したように、HTTPはステートレスなプロトコルです。そのため表2の（4）、（5）の動作のようにログイン状態を保持するためには、HTTPリクエストの度にサーバにログイン状態であるということを伝える必要があります。
そのための方法としては、大きく分けて以下の2種類が考えられます。
- リクエストの度にID、パスワードをサーバに送信する
- セッション管理を行ない、認証状態はサーバ側で管理する
|
表3：ログイン状態を保持するための方法
|
（A）の方式の代表的な例としてベーシック認証があります。ベーシック認証ではHTTPリクエスト時に以下のようなAuthorizationヘッダを送信します。
|
Authorization Basic dXNlcjpwYXNz
|
「dXNlcjpwYXNz」は「user:pass」という文字列をBASE64エンコードしたものです。容易に復元可能であり、平文で送っているのとほとんど一緒です。
ベーシック認証はIDとパスワードを一回入力するだけでログイン状態を維持しているように見えますが、実際はブラウザがIDとパスワードを記憶していて、Authorizationヘッダを自動的に送信することによってログイン状態を作りだしています。また、ベーシック認証を使わない場合には、CookieにIDとパスワードを対の状態で保存しておき、サーバに送信する方法も考えられます。
（B）の方式ではサーバにID、パスワードを送信するのはログイン時の一回のみとなります。ログインが成功した際にサーバ側のセッション情報にログインしたという情報を記録し、それ以降はCookieなどにて維持されるセッションIDのみをやり取りします。
（A）の方法では、IDとパスワードの一致を確認する処理を繰り返すだけなので実装が単純になりますが、ID、パスワードがHTTPリクエストの度にネットワークに流れてしまい、Cookieが流出した場合にはなりすましなどの被害が拡大します。（B）の方法の場合でも、セッションIDが盗まれてしまうとなりすましができてしまいますが、セッションの有効期限を設けておくなどの方法により被害を限定化することが可能です。
|
前のページ 1 2 3 4 次のページ
|
|
|
|
|
著者プロフィール
株式会社ライブドア 池邉 智洋
ネットサービス事業本部 システムグループ マネージャー。2001年10月よりライブドア（当時オン・ザ・エッヂ）にて受託開発業務のWebアプリケーション開発に従事。2003年11月よりlivedoorのポータル化にたずさわり、各種サービスの開発を行う。個人的にCPANモジュールやApacheモジュールの公開も行っている。
|
|
|
|
|
|
