2013-07-21 11 views
108

クッキーベースの認証の仕組みをステップごとに説明できますか?私は決して認証かクッキーのどちらかを含む何もしなかった。ブラウザは何をする必要がありますか?サーバーは何をする必要がありますか?どのような順序で?どのように物事を安全に保つのですか?Cookieベースの認証はどのように機能しますか?

私は様々な種類の認証とクッキーについて読んできましたが、2つを一緒に使用する方法の基本的な説明をしたいと思います。私はよく一緒に使用されますが、どうやって。

+3

http://www.howstuffworks.com/cookie.htm – Cyclonecode

+0

この記事は役立つかもしれない:http://www.yegor256.com/2015/05/18/cookie-based-authentication.html – yegor256

答えて

93

Cookieは、基本的に辞書の項目です。各項目にはキーと値があります。認証の場合、キーは「username」のようなもので、値はユーザー名です。ウェブサイトにリクエストするたびに、ブラウザはリクエストにクッキーを含め、ホストサーバーはクッキーをチェックします。そのように、認証は自動的に行うことができます。

クッキーを設定するには、要求後にサーバーが返信する応答に追加するだけです。ブラウザは、応答を受信するとクッキーを追加します。

有効期限や暗号化など、Cookieサーバー側で構成できるさまざまなオプションがあります。暗号化されたクッキーは、しばしば署名付きクッキーと呼ばれます。基本的に、サーバーは辞書項目のキーと値を暗号化するため、サーバーのみが情報を利用できます。それでクッキーは安全です。

ブラウザは、サーバーによって設定されたCookieを保存します。ブラウザがそのサーバに行うすべてのリクエストのHTTPヘッダに、Cookieが追加されます。それはそれらを設定するドメインのためのクッキーを追加するだけです。 Example.comでは、Cookieを設定したり、ブラウザーがcookieをsub.example.comなどのサブドメインに送り返すためのHTTPヘッダーにオプションを追加することもできます。ブラウザが別のドメインにCookieを送信することは容認できません。

+0

何私は、ブラウザがクッキーを同じドメインに送り返すことができることを理解しています。それに関連して、ブラウザーは2つのドメインを区別するときにサブドメインを考慮に入れますか? – Aakash

+1

ブラウザがサブドメインをどのように処理するかについて、HTTPヘッダーにオプションを設定できます。 –

151

私はこれが何年も遅れていることを認識していますが、私はConorの答えを広げて議論に少し追加することができると思っていました。

クッキーベース認証がどのように機能するかを説明する段階的な説明はありますか?私は決して認証かクッキーのどちらかを含む何もしなかった。ブラウザは何をする必要がありますか?サーバーは何をする必要がありますか?どのような順序で?どのように物事を安全に保つのですか?

ステップ1:クライアント>何か前まで

署名は、ユーザーがサインアップする必要があります。クライアントは、ユーザー名とパスワードを含むHTTP要求をサーバーに送信します。

ステップ2:サーバー>取り扱い

サーバがこの要求を受信し、データベース内のユーザ名とパスワードを保存する前にパスワードをハッシュをサインアップしてください。このようにして、誰かがあなたのデータベースにアクセスすると、あなたの実際のパスワードは表示されません。

ステップ3:クライアント>ユーザーログイン

今すぐあなたのユーザーがログインする彼/彼女は、自分のユーザー名/パスワードを提供して、再度、これは、サーバーへのHTTPリクエストとして計上されます。

ステップ4:サーバー>検証ログインが

サーバーは、データベース内のユーザー名を検索します付属ログインパスワードをハッシュし、データベースで以前にハッシュされたパスワードと比較します。チェックアウトしていない場合は、sending a 401 status code and ending the requestでアクセスを拒否することがあります。

ステップ5:サーバー>すべてがチェックアウトした場合、我々は一意のユーザーのセッションを識別するアクセストークンを作成しようとしている

アクセストークンを生成します。それでもサーバーで、我々は、アクセストークンを持つ2つのことを行う:

  1. ストアを
  2. がクライアントに返されるレスポンスのクッキーにそれを取り付けて、そのユーザーに関連付けられているデータベースに。ユーザーのセッションを制限する有効期限を設定してください。

以降、クッキーはクライアントとサーバーの間で行われるすべての要求(および応答)に添付されます。

ステップ6:クライアントは>ページが戻るクライアント側の

を要求した作り、私たちは今ログインしているクライアントが認証を必要とするページを要求するたびに(すなわち、それらはログインする必要があります。サーバーはクッキーからアクセストークンを取得し、そのユーザーに関連付けられているデータベース内のアクセストークンと照合します。チェックアウトすると、アクセスが許可されます。

これはあなたの作業を開始するはずです。ログアウト時に必ずクッキーをクリアしてください!

+4

ありがとうございます。私はアクセストークンがセキュリティをどのように提供するのだろうか?攻撃者は、クッキーを盗み、認証されたログインユーザとしてポーズを取ることができますか?それともSSLによって保護されていますか? – Richeek

+1

@Richeek SSLは要求/応答中に傍受を保証しますが、攻撃者はエンドポイント(ブラウザなど)でCookieにアクセスする可能性があります。理論的には、Cookieの有効期限が切れるまで、ログインしたユーザーとしてポーズを取ることができます。上記の実装がそれを処理しないので、私は "理論的に"言う。上記の実装では、データベース内のアクセストークンが更新される(つまり次のログイン)まで、攻撃者はアクセス権を持ちます。 – pllx

+7

有効期限が切れたときにアクセストークンを無効にする可能性があります。おそらくデータベースに「有効期限」があります。または、アクセストークンと同様の[JSON Webトークン(JWT)](http://techarena51.com/index.php/json-web-token-authentication-with-flask-and-angularjs/)の使用を検討することもできますトークンの有効期限を処理することができます。 [JWTの詳細はこちら](http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html#rfc.section.4.1.4) 攻撃者は引き続きアクセスできます彼らがアクセストークン/ JWTを持っている場合は短期間あなたのアカウントにアクセスできるので、エンドポイントも保護する必要があります。 – pllx

0

クッキーベースの認証

クッキーベースの認証は、ユーザーがログインフォームにユーザー名とパスワードを提供し、ログインをクリックしたこれら4 steps-

  1. で正常に動作します。
  2. 要求が行われた後、サーバーはデータベースを照会してバックエンドのユーザーを検証します。リクエストが有効な場合、データベースからフェッチされたユーザー情報を使用してセッションを作成し、保存します。セッションごとにセッションIDという一意のIDが作成されます。デフォルトでは、セッションIDはブラウザを通じてクライアントに渡されます。
  3. ブラウザはこの後続の各要求でIDを発行し、このセッションIDウェブサイトに基づいてデータベースに対してセッションIDが検証され、どのクライアントに属するセッションが識別され、その要求にアクセス権が与えられます。

  4. ユーザーがアプリからログアウトすると、セッションはクライアント側とサーバー側の両方で破棄されます。

関連する問題