 |
||||||||||||||
|
||||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||||
|
||||||||||||||
| Webアプリケーションでの認証 | ||||||||||||||
|
Webアプリケーションでの認証の一般的な流れとして、以下のような動作が想定されます。 |
||||||||||||||
|
||||||||||||||
|
表2：認証の流れ |
||||||||||||||
| 前回説明したように、HTTPはステートレスなプロトコルです。そのため表2の（4）、（5）の動作のようにログイン状態を保持するためには、HTTPリクエストの度にサーバにログイン状態であるということを伝える必要があります。 そのための方法としては、大きく分けて以下の2種類が考えられます。
|
||||||||||||||
|
表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 次のページ |
||||||||||||||
|
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
-
-
連載
