この質問は、少し異なる形で詳細にここで扱われました：
RESTful認証
しかし、これはサーバー側から対処します。これをクライアント側から見てみましょう。ただし、その前に、重要な前奏曲があります。
Javascript暗号は絶望的
これに関するマタサノの記事は有名ですが、そこに含まれる教訓は非常に重要です。
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/
要約する：
- 中間者攻撃では、暗号コードを簡単に置き換えることができます
<script>
function hash_algorithm(password){ lol_nope_send_it_to_me_instead(password); }</script>
- 中間者攻撃は、非SSL接続を介してリソースを提供するページに対して簡単です。
- SSLを取得したら、とにかく実際の暗号を使用します。
そして、私の独自の結果を追加するには：
- XSS攻撃が成功すると、SSLを使用している場合でも、攻撃者がクライアントのブラウザでコードを実行する可能性があります。そのため、すべてのハッチが攻撃されても、攻撃者が実行方法を見つけた場合、ブラウザの暗号は失敗する可能性があります。他の誰かのブラウザ上のjavascriptコード。
これにより、JavaScriptクライアントを使用する場合、RESTful認証スキームの多くが不可能または愚かになります。見てみよう！
HTTP基本認証
何よりもまず、HTTP Basic Auth。最も簡単なスキーム：すべてのリクエストで名前とパスワードを渡すだけです。
もちろん、これには絶対にSSLが必要です。すべてのリクエストでBase64（可逆）エンコードされた名前とパスワードを渡すためです。回線を聞いている人はだれでも簡単にユーザー名とパスワードを抽出できます。「Basic Auth is insecure」の引数のほとんどは、ひどい考えである「Basic Auth over HTTP」の場所から来ています。
ブラウザーは組み込みのHTTP Basic Authサポートを提供しますが、それは罪として醜いので、アプリではおそらく使用しないでください。ただし、JavaScriptでユーザー名とパスワードを隠しておく方法もあります。
これは最もRESTfulなソリューションです。サーバーは、状態に関する知識を一切必要とせず、ユーザーとの個々の対話をすべて認証します。一部のREST愛好家（ほとんどが麦わら）は、あらゆる種類の状態を維持することは異端であり、他の認証方法を考えれば口の中で泡立つと主張します。この種の標準準拠には理論上の利点があります。Apacheがそのままサポートします。必要に応じて、オブジェクトを.htaccessファイルで保護されたフォルダにファイルとして保存できます。
問題は？クライアント側でユーザー名とパスワードをキャッシュしています。これにより、evil.ruに優れた亀裂が生じます。最も基本的なXSS脆弱性でさえ、クライアントがユーザー名とパスワードを悪意のあるサーバーに送信する可能性があります。パスワードをハッシュ化してソルト処理することで、このリスクを軽減することもできますが、JavaScript Cryptoは絶望的です。このリスクは、ブラウザの基本認証サポートに任せることで軽減できますが、前述のように醜い罪です。
HTTPダイジェスト認証
jQueryでダイジェスト認証は可能ですか？
より「安全な」認証、これは要求/応答ハッシュチャレンジです。除きJavaScriptの暗号絶望的であることが唯一のSSL上で動作し、あなたはまだ、クライアント側のユーザー名とパスワードをキャッシュし、それはより多くのHTTP基本認証よりも複雑な作りが、する必要がないので、これ以上確保します。
追加の署名パラメーターを使用したクエリ認証。
もう1つの「安全な」認証では、ナンスとタイミングデータでパラメーターを暗号化し（繰り返し攻撃とタイミング攻撃から保護するため）、送信します。これの最も良い例の1つは、OAuth 1.0プロトコルです。これは、私の知る限り、RESTサーバーに認証を実装するためのかなり重要な方法です。
http://tools.ietf.org/html/rfc5849
ああ、でもJavaScript用のOAuth 1.0クライアントはありません。どうして？
JavaScript Cryptoは絶望的です。JavaScriptはSSLなしではOAuth 1.0に参加できず、クライアントのユーザー名とパスワードをローカルに保存する必要があります。これにより、ダイジェスト認証と同じカテゴリに分類されます。HTTP基本認証よりも複雑ですが、安全性は高くありません。
トークン
ユーザーはユーザー名とパスワードを送信し、その代わりにリクエストの認証に使用できるトークンを取得します。
ユーザー名とパスワードのトランザクションが完了するとすぐに機密データを破棄できるため、これはHTTP基本認証よりもわずかに安全です。トークンは「状態」を構成し、サーバーの実装をより複雑にするため、RESTfulでもありません。
まだSSL
ただし、トークンを取得するには、最初のユーザー名とパスワードを送信する必要があります。機密情報は依然として、危険なJavaScriptに触れています。
ユーザーの資格情報を保護するには、攻撃者をJavaScriptに近づけないようにする必要があり、ユーザー名とパスワードをネットワーク経由で送信する必要があります。SSLが必要です。
トークンの有効期限
「このトークンが長すぎる場合は破棄して、ユーザーを再度認証させる」などのトークンポリシーを適用するのが一般的です。または「このトークンの使用が許可されている唯一のIPアドレスは確かですXXX.XXX.XXX.XXX」これらのポリシーの多くはかなり良いアイデアです。
消防
ただし、SSLなしでトークンを使用すると、「サイドジャッキング」と呼ばれる攻撃に対して依然として脆弱です：http ://codebutler.github.io/firesheep/
攻撃者はユーザーの資格情報を取得しませんが、それでもユーザーのふりをすることができ、これはかなり悪い場合があります。
tl; dr：暗号化されていないトークンをネットワーク経由で送信することは、攻撃者がそれらのトークンを簡単に取得し、ユーザーのふりをすることができることを意味します。FireSheepは、これを非常に簡単にするプログラムです。
独立した、より安全なゾーン
実行しているアプリケーションが大きくなるほど、機密データの処理方法を変更するコードを挿入できないようにすることが難しくなります。CDNを完全に信頼していますか？あなたの広告主？あなた自身のコードベース？
クレジットカードの詳細では一般的で、ユーザー名とパスワードではあまり一般的ではありません-一部の実装者は、アプリケーションの残りの部分とは別のページに、「機密データの入力」を保持します。ユーザーをフィッシングするのは困難です。
Cookie（単にトークンを意味する）
認証トークンをCookieに入れることは可能です（そして一般的です）。これにより、トークンを使用したauthのプロパティが変更されることはなく、より便利になります。以前のすべての引数が引き続き適用されます。
セッション（まだトークンを意味します）
セッション認証は単なるトークン認証ですが、わずかに異なるもののように見えるいくつかの違いがあります。
- ユーザーは、認証されていないトークンから開始します。
- バックエンドは、ユーザーのトークンに関連付けられた「状態」オブジェクトを維持します。
- トークンはCookieで提供されます。
- アプリケーション環境は、詳細を抽象化します。
それを除けば、実際にはトークン認証と何の違いもありません。
これは、RESTful実装からさらにさまよっています。ステートオブジェクトを使用すると、ステートフルサーバー上のプレーンオールRPCのパスにさらに進んでいきます。
OAuth 2.0
OAuth 2.0は、「ソフトウェアAがソフトウェアBにユーザーXのログイン認証情報へのアクセス権を与えずに、ソフトウェアBにユーザーXのデータへのアクセス権をどのように付与するか」の問題を調べます。
実装は、ユーザーがトークンを取得し、サードパーティサービスが「はい、このユーザーとこのトークンは一致し、ユーザーからデータの一部を今すぐ取得できる」ための標準的な方法にすぎません。
ただし、基本的に、OAuth 2.0は単なるトークンプロトコルです。他のトークンプロトコルと同じプロパティを示します。これらのトークンを保護するにはSSLが必要です。これらのトークンの生成方法が変更されるだけです。
OAuth 2.0が役立つ2つの方法があります。
- 他人への認証/情報の提供
- 他人からの認証/情報の取得
しかし、それには、トークンを使用しているだけです。
あなたの質問に戻る
それで、あなたが尋ねている質問は「私のトークンをクッキーに保存し、私の環境の自動セッション管理に詳細を処理させるべきですか、それとも自分のトークンをJavaScriptに保存して自分でそれらの詳細を処理するべきですか？」ということです。
そして答えは、あなたを幸せにするものなら何でもしなさい。
ただし、自動セッション管理の問題は、舞台裏で多くの魔法が起こっていることです。多くの場合、これらの詳細を自分で制御する方が良いです。
私は21歳なので、SSLはイエスです
もう1つの答えは、すべてにhttpsを使用することです。そうしないと、ブリガンドがユーザーのパスワードとトークンを盗みます。