189

トークン認証と Cookie を使用した認証の違いは何ですか?

Ember Auth Rails Demoを実装しようとしていますが、 Ember Auth FAQの「なぜトークン認証なのか?」という質問に記載されているように、トークン認証を使用する理由がわかりません。

4

9 に答える 9

447

HTTP はステートレスです。承認するには、サーバーに送信するすべてのリクエストに「署名」する必要があります。

トークン認証

  • サーバーへのリクエストは「トークン」によって署名されます。通常、これは特定の http ヘッダーを設定することを意味しますが、http リクエストの任意の部分 (POST 本文など) で送信できます。

  • 長所：

    • 承認したいリクエストのみを承認できます。(Cookie - 認証 Cookie もすべてのリクエストに対して送信されます。)
    • XSRF への耐性 (XSRF の簡単な例 - のようなリンクをメールで送信します<img src="http://bank.com?withdraw=1000&to=myself" />。cookie 認証を使用して bank.com にログインしている場合、bank.com には XSRF の手段がありません。ブラウザがその URL に対して承認された GET リクエストをトリガーするという事実だけで、あなたのアカウントからお金を引き出します.) Cookie ベースの認証で実行できる偽造防止対策があることに注意してください-ただし、それらを実装する必要があります.
    • Cookie は単一のドメインにバインドされます。ドメイン foo.com で作成された Cookie は、ドメイン bar.com では読み取れませんが、好きなドメインにトークンを送信できます。これは、承認が必要な複数のサービスを使用する単一ページ アプリケーションに特に役立ちます。そのため、myservice1.com および myservice2.com に対して承認済みのクライアント側要求を作成できる Web アプリをドメイン myapp.com に作成できます。
  • 短所：
    • トークンをどこかに保存する必要があります。クッキーは「箱から出して」保存されます。思いつく場所は、localStorage (短所: ブラウザー ウィンドウを閉じた後もトークンが保持される)、sessionStorage (長所: ブラウザー ウィンドウを閉じた後もトークンが破棄される、短所: 新しいタブでリンクを開くとそのタブがレンダリングされる) です。匿名) と Cookie (長所: ブラウザー ウィンドウを閉じると、トークンは破棄されます。セッション Cookie を使用すると、新しいタブでリンクを開くときに認証されます。認証用の Cookie を使用する場合、トークン ストレージとして使用しているだけです。短所: Cookie はリクエストごとに送信されます。この Cookie が https のみとしてマークされていない場合、中間者攻撃に対して無防備です。)
    • トークン ベースの認証に対して XSS 攻撃を行う方が少し簡単です (つまり、サイトに挿入されたスクリプトを実行できれば、トークンを盗むことができます。ただし、Cookie ベースの認証も特効薬ではありません。クライアントは http-only を読み取ることができませんが、クライアントは引き続き、承認 Cookie を自動的に含めるリクエストを作成できます。)
    • 許可されたユーザーのみが機能するはずのファイルをダウンロードするリクエストには、File API を使用する必要があります。Cookie ベースの認証では、同じ要求がすぐに使用できます。

クッキー認証

  • サーバーへのリクエストは、常に認証 Cookie によってサインインされます。
  • 長所：
    • Cookie を「http のみ」としてマークすると、クライアント側で読み取ることができなくなります。これは、XSS 攻撃からの保護に適しています。
    • そのまま使用できます - クライアント側にコードを実装する必要はありません。
  • 短所：
    • 単一のドメインにバインドされています。(したがって、複数のサービスにリクエストを行う単一ページのアプリケーションがある場合、リバース プロキシのようなクレイジーなことを行うことになります。)
    • XSRF に対して脆弱です。クロス サイト リクエスト フォージェリからサイトを保護するには、追加の手段を実装する必要があります。
    • 単一のリクエストごとに送信されます (認証を必要としないリクエストであっても)。

全体として、トークンを使用すると柔軟性が向上すると思います (単一のドメインに縛られないため)。欠点は、かなりのコーディングを自分で行う必要があることです。

于 2016-01-28T11:10:54.213 に答える
38

典型的な Web アプリは、その要求/応答の性質から、ほとんどがステートレスです。HTTP プロトコルは、ステートレスプロトコルの最良の例です。ただし、ほとんどの Web アプリはstateを必要とするため、サーバーとクライアントの間で状態を保持するために、サーバーがすべての応答で Cookie をクライアントに返すことができるように、Cookie が使用されます。これは、クライアントからの次のリクエストにこの Cookie が含まれるため、サーバーによって認識されることを意味します。このようにして、サーバーはステートレスクライアントとのセッションを維持でき、アプリの状態に関するほとんどすべてを認識しますが、サーバーに保存されます。このシナリオでは、クライアントが保持する瞬間はありませんこれはEmber.jsの動作とは異なります。

Ember.js では事情が異なります。Ember.js は、サーバーに状態データを要求する要求を行うことなく、その状態を常に把握しているため、クライアントで実際に状態を保持するため、プログラマーの仕事が容易になります。

ただし、クライアントで状態を保持すると、ステートレスな状況では存在しない同時実行の問題が発生する場合もあります。ただし、Ember.js はこれらの問題にも対処します。具体的には、ember-data はこれを念頭に置いて構築されています。結論として、Ember.js はステートフルクライアント用に設計されたフレームワークです。

Ember.js は、セッション、状態、および対応する Cookie がサーバーによってほぼ完全に処理される典型的なステートレスWeb アプリのようには機能しません。Ember.js はその状態を完全に Javascript に保持し (他のフレームワークのように DOM ではなく、クライアントのメモリに)、サーバーがセッションを管理する必要はありません。これにより、アプリがオフライン モードの場合など、多くの状況で Ember.js の汎用性が高まります。

明らかに、セキュリティ上の理由から、認証のためにリクエストが行われるたびに、ある種のトークンまたは一意のキーをサーバーに送信する必要があります。このようにして、サーバーは送信トークン (サーバーによって最初に発行されたもの) を検索し、クライアントに応答を返す前に有効かどうかを確認できます。

私の意見では、 Ember Auth FAQに記載されているように Cookie の代わりに認証トークンを使用する主な理由は、主に Ember.js フレームワークの性質によるものであり、ステートフルなWeb アプリ パラダイムにより適合するためでもあります。したがって、Cookie メカニズムは、Ember.js アプリを構築する際の最善の方法ではありません。

私の答えがあなたの質問にもっと意味を与えることを願っています。

于 2013-06-08T15:50:51.797 に答える
10

ここには混乱があると思います。Cookie ベースの認証と、現在HTML5 Web Storageで可能になっていることとの大きな違いは、ブラウザーは、Cookie データを設定したドメインからリソースを要求するたびに、Cookie データを送信するように構築されていることです。Cookie をオフにしない限り、これを防ぐことはできません。ページ内のコードがデータを送信しない限り、ブラウザーは Web Storage からデータを送信しません。また、ページは自分が保存したデータにのみアクセスでき、他のページに保存されたデータにはアクセスできません。

そのため、Cookie データが Google や Facebook によって使用される可能性があることを心配しているユーザーは、Cookie をオフにする可能性があります。ただし、Web Storage を無効にする理由はほとんどありません (広告主が Web Storage の使用方法を理解するまでは)。

これが Cookie ベースとトークン ベースの違いであり、後者は Web Storage を使用します。

于 2013-12-27T08:14:31.567 に答える
5

トークンベースの認証はステートレスであり、サーバーはユーザー情報をセッションに保存する必要はありません。これにより、ユーザーがログインした場所を気にせずにアプリケーションをスケーリングできます。Cookie ベースには Web サーバー フレームワークのアフィニティがありますが、トークン ベースでは問題になりません。したがって、別の uid/pwd 認証を回避するために、ログインしているドメイン以外のドメインからセキュアなリソースをフェッチするために同じトークンを使用できます。

ここの非常に良い記事：

http://www.toptal.com/web/cookie-free-authentication-with-json-web-tokens-an-example-in-laravel-and-angularjs

于 2015-03-27T10:52:10.153 に答える
0

要するに：

JWT vs Cookie Auth

|                    | Cookie        | JWT                             |
| Stateless          | No            | Yes                             |
| Cross domain usage | No            | Yes                             |
| Mobile ready       | No            | Yes                             |
| Performance        | Low           | High (no need in request to DB) |
| Add to request     | Automatically | Manually (if not in cookie)     |
于 2020-12-24T09:24:09.423 に答える