1. ホーム
  2. authentication

[解決済み] トークン認証とCookieの比較

2022-04-14 04:50:54

質問

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

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

どのように解決するのですか?

一般的なWebアプリは、ほとんどが ステートレス そのため リクエスト/レスポンス の性質を持っています。HTTPプロトコルは ステートレス プロトコルです。しかし、ほとんどのWebアプリケーションでは 状態 を保持するために 状態 サーバーとクライアントの間で、サーバーがクライアントに返すすべてのレスポンスにクッキーを送信できるように、クッキーが使用されます。つまり、クライアントからの次のリクエストはこのクッキーを含むので、サーバーに認識されることになります。このようにして、サーバは セッション と共に ステートレス クライアントが、アプリの 状態 しかし、サーバーに保存されています。このシナリオでは、クライアントはどの瞬間にも 状態 というわけではありません。 エンバー.js は動作します。

Ember.jsでは事情が違います。Ember.jsは確かに 状態 を常に把握することができます。 状態 をサーバーにリクエストしなくても 状態 のデータを使用します。

ただし、保有 状態 にはない並行処理の問題が発生することがあります。 ステートレス の状況です。しかしEmber.jsは、このような問題にも対処しています。特にember-dataは、このことを念頭に置いて作られています。結論から言うと、Ember.jsは以下のような用途のために設計されたフレームワークです。 ステートフル クライアントになります。

Ember.jsは、一般的な ステートレス ウェブアプリでは セッション は、その 状態 とそれに対応するクッキーは、ほぼ完全にサーバーによって処理されます。Ember.jsはその 状態 は完全に Javascript 内にあり(他のフレームワークのように DOM 内ではなく、クライアントのメモリ内)、セッションを管理するためのサーバーは必要ありません。その結果、Ember.js は、アプリがオフラインのときなど、多くの状況でより多用途に使用できます。

もちろん、セキュリティ上の理由から、何らかの形で トークン または ユニークキー にするために、リクエストが行われるたびにサーバーに送信されます。 認証 . こうすることで、サーバーは送信トークン(サーバーが最初に発行したもの)を調べ、それが有効かどうかを検証してからクライアントに応答を返すことができます。

私見ですが、Cookieの代わりに認証トークンを使用する主な理由は、次のとおりです。 Ember Auth FAQ は、Ember.jsフレームワークの性質上、また、より ステートフル ウェブアプリのパラダイムです。したがって、Ember.js アプリを構築するとき、Cookie メカニズムは最良のアプローチではありません。

私の回答があなたの質問にもっと意味を与えることを望みます。