トークン認証とCookie
トークン認証とCookieを使用した認証の違いは何ですか？
Ember Auth Rails Demo を実装しようとしていますが、 Ember Auth FAQ で説明されているトークン認証を使用する理由がわかりません質問「なぜトークン認証？」
典型的なWebアプリは、リクエスト/レスポンスの性質のため、ほとんどstatelessです。 HTTPプロトコルは、statelessプロトコルの最良の例です。ただし、ほとんどのWebアプリにはstateが必要なので、stateを保持するために、サーバーとクライアントの間で、サーバーはすべての応答をクライアントに送り返すことができます。これは、クライアントからの次の要求にこのCookieが含まれ、サーバーによって認識されることを意味します。このようにして、サーバーはstatelessクライアントとsessionを維持でき、アプリのに関するほとんどすべてを把握できますstate、ただしサーバーに保存されます。このシナリオでは、クライアントはstateを保持しません。これは Ember.js の動作方法ではありません。
Ember.jsでは状況が異なります。 Ember.jsは、stateを実際に保持しているため、クライアントで、statestateデータを要求するサーバーに要求する必要なし。
ただし、stateをクライアントに保持すると、stateless状況には存在しない同時実行の問題が発生することもあります。ただし、Ember.jsはこの問題も処理します。具体的には、これを念頭に置いてember-dataが構築されます。結論として、Ember.jsはstatefulクライアント用に設計されたフレームワークです。
Ember.jsは、statelessWebアプリ（session、state対応するCookieは、サーバーによってほぼ完全に処理されます。 Ember.jsはstateを完全にjavascriptに保持し（クライアントのメモリにあり、他のフレームワークのようにDOMにはありません）、セッションを管理するためにサーバーを必要としません。これにより、Ember.jsは多くの状況でより用途が広がります。アプリがオフラインモードのとき。
セキュリティ上の理由から、要求が行われるたびにサーバーに送信される何らかの種類のtokenまたはunique keyが必要ですauthenticatedであるため、サーバーは送信トークン（サーバーによって最初に発行された）を検索し、クライアントに応答を送信する前に有効かどうかを確認できます。
私の意見では、 Ember Auth FAQ に記載されているCookieの代わりに認証トークンを使用する主な理由は、主にEmber.jsフレームワークの性質とstatefulWebアプリのパラダイム。したがって、Ember.jsアプリを作成する場合、Cookieメカニズムは最適なアプローチではありません。
私の答えがあなたの質問により多くの意味を与えることを願っています。
HTTPはステートレスです。認証するには、サーバーに送信するすべてのリクエストに「署名」する必要があります。
トークン認証
サーバーへのリクエストは「トークン」によって署名されます-通常、特定のhttpヘッダーを設定することを意味しますが、httpリクエストの任意の部分（POST本体など）で送信できます。
長所：
- 承認したいリクエストのみを承認できます。 （Cookie-認証Cookieでさえ、すべてのリクエストに対して送信されます。）
- XSRFに耐性（XSRFの簡単な例-
<img src="http://bank.com?withdraw=1000&to=myself" />のようなリンクをメールで送信します。また、cookie.com経由でbank.comにログインし、bank.comにはログインしませんXSRF保護の手段を持っている場合、ブラウザがそのURLへの許可されたGETリクエストをトリガーするという事実によって、私はあなたのアカウントからお金を引き出します。）Cookieベースの認証でできる偽造防止対策があることに注意してください-しかしそれらを実装する必要があります。 - Cookieは単一のドメインにバインドされます。ドメインfoo.comで作成されたcookieは、ドメインbar.comで読み取ることはできませんが、好きなドメインにトークンを送信できます。これは、承認が必要な複数のサービスを使用する単一ページアプリケーションに特に役立ちます。したがって、myservice1.comおよびmyservice2.comに対して承認済みのクライアント側の要求を行うことができるドメインmyapp.comにWebアプリを作成できます。
- 短所：
- トークンをどこかに保存する必要があります。 Cookieは「そのまま」保存されます。思い浮かぶのは、localStorage（con：ブラウザーウィンドウを閉じた後でもトークンが保持される）、sessionStorage（pro：ブラウザーウィンドウを閉じた後にトークンが破棄される、con：新しいタブでリンクを開くとそのタブがレンダリングされる）匿名）とCookie（Pro：ブラウザーウィンドウを閉じた後、トークンは破棄されます。セッションCookieを使用すると、新しいタブでリンクを開くときに認証され、XSRFを無視しているため、認証用のCookie、トークンストレージとして使用しているだけです。Con：Cookieはすべてのリクエストに対して送信されます。このCookieがhttpsのみとしてマークされていない場合は、中間者攻撃が可能です。
- トークンベースの認証に対してXSS攻撃を行う方が少し簡単です（つまり、サイトで注入されたスクリプトを実行できる場合、トークンを盗むことができますが、Cookieベースの認証も特効薬ではありません。クライアントはhttp-onlyを読み取ることができません。クライアントは、ユーザーに代わって認証Cookieを自動的に含めるリクエストを行うことができます。）
- 許可されたユーザーのみに機能するはずのファイルをダウンロードするには、File APIを使用する必要があります。 Cookieベースの認証では、同じリクエストがそのまま使用できます。
Cookie認証
- サーバーへの要求は、常に許可Cookieによってサインインされます。
- 長所：
- Cookieを「httpのみ」としてマークすると、クライアント側で読み取ることができなくなります。これは、XSS攻撃からの保護に適しています。
- すぐに使える-クライアント側でコードを実装する必要はありません。
- 短所：
- 単一のドメインにバインドされています。 （したがって、複数のサービスへのリクエストを行う単一のページアプリケーションがある場合、リバースプロキシのようなクレイジーなことをすることになります。）
- XSRFに対して脆弱です。サイトをクロスサイトリクエストフォージェリから保護するには、特別な対策を講じる必要があります。
- 単一の要求ごとに送信されます（認証を必要としない要求でも）。
全体的に、トークンを使用すると柔軟性が向上すると思います（単一ドメインにバインドされていないため）。欠点は、かなりのコーディングを自分で行わなければならないことです。
トークンはどこかに保存する必要があります（ローカル/セッションストレージまたはCookie）
トークンはCookieのように期限切れになる場合がありますが、より細かく制御できます
ローカル/セッションストレージはドメイン間で機能しません。マーカーCookieを使用します
プリフライトリクエストは各CORSリクエストで送信されます
何かをストリーミングする必要がある場合は、トークンを使用して署名付きリクエストを取得します
XSRFよりもXSSを扱う方が簡単です
トークンはリクエストごとに送信されます。サイズに注意してください
機密情報を保存する場合は、トークンを暗号化します
JSON Web TokensはOAuthで使用できます
トークンは特効薬ではありません。認可のユースケースを慎重に検討してください
http://blog.auth0.com/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies/
http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/
ここには混乱があると思います。 Cookieベースの認証と HTML5 Web Storage で可能になったものとの大きな違いは、ブラウザーは、Cookieデータを設定するドメインからリソースを要求するたびにCookieデータを送信するように構築されていることです。 Cookieをオフにしない限り、それを防ぐことはできません。ブラウザーは、ページ内のコードが送信しない限り、Web Storageからデータを送信しません。また、ページは自分が保存したデータにのみアクセスでき、他のページに保存されたデータにはアクセスできません。
したがって、ユーザーは、CookieデータがGoogleまたはFacebookで使用される方法を心配して、Cookieをオフにする可能性があります。ただし、Web Storageをオフにする理由はあまりありません（広告主がそれを使用する方法を考え出すまで）。
したがって、これはCookieベースとトークンベースの違いです。後者はWeb Storageを使用します。
トークンベースの認証はステートレスであり、サーバーはセッションにユーザー情報を保存する必要はありません。これにより、ユーザーがログインした場所を気にせずにアプリケーションを拡張できます。CookieベースのWeb Server Frameworkアフィニティはありますが、トークンベースの問題ではありません。そのため、同じトークンを使用して、別のuid/pwd認証を回避する、ログインしているドメイン以外のドメインから安全なリソースを取得できます。
ここで非常に良い記事：
次の場合にトークンを使用...
連携が望まれます。たとえば、1つのプロバイダー（Token Dispensor）をトークン発行者として使用し、次にAPIサーバーをトークンバリデーターとして使用します。アプリは、Token Dispensorに対して認証を行い、トークンを受信して、そのトークンをAPIサーバーに提示して検証することができます。 （Googleサインイン、Paypal、Salesforce.comなどで機能します）
非同期が必要です。たとえば、クライアントにリクエストを送信し、そのリクエストをどこかに保存して、「後で」別のシステムで処理するようにします。その別のシステムは、クライアントへの同期接続を持たず、中央トークンディスペンサリーへの直接接続を持たない場合があります。非同期処理システムがJWTを読み取って、ワークアイテムを後で実行できるかどうかを判断できます。これは、ある意味で、上記の連盟のアイデアに関連しています。ただし、ここで注意してください：JWTは期限切れです。作業項目を保持しているキューがJWTの有効期間内に処理されない場合、クレームは信頼されなくなります。
Cient Signedリクエストが必要です。ここでは、クライアントの秘密キーを使用してリクエストがクライアントによって署名され、サーバーはクライアントの登録済み公開キーを使用して検証します。
主な違いの1つは、Cookieには同じ生成元ポリシーが適用されるのに対し、トークンには適用されないことです。これにより、あらゆる種類のダウンストリームエフェクトが作成されます。
Cookieは特定のホストとのみ送受信されるため、ホストはユーザーを認証する負担を負う必要があり、ユーザーは検証可能にするためにそのホストでセキュリティデータを含むアカウントを作成する必要があります。
一方、トークンは発行され、同じオリジンポリシーの対象ではありません。発行者は文字通り誰でもかまいませんし、どの発行者を信頼するかを決めるのはホスト次第です。通常、GoogleやFacebookなどの発行者は信頼性が高いため、ホストはユーザー認証（すべてのユーザーセキュリティデータの保存を含む）の負担を別の関係者に移すことができ、ユーザーは個人データを特定の発行者の下に統合し、対話するホストごとに異なるパスワードの束。
これにより、ユーザーエクスペリエンスの全体的な摩擦を軽減するシングルサインオンシナリオが可能になります。理論的には、すべてのmaとpaのWebサイトが独自の、おそらくは中途半端な認証システムを起動する代わりに、認証サービスを提供するために専門のIDプロバイダーが出現するにつれて、Webの安全性も高まります。そして、これらのプロバイダーが登場すると、非常に基本的なリソーストレンドでさえゼロに向かう安全なWebリソースを提供するコストが発生します。
したがって、一般にトークンは認証の提供に関連する摩擦とコストを削減し、セキュリティシステムの実装と維持の両方をより上手に行える集中型の当事者に、安全なWebのさまざまな側面の負担を移します。