web-dev-qa-db-ja.com

認証トークンをCookieまたはヘッダーに保存しますか？

ヘッダーはREST呼び出しで信頼済みシステムから別のシステムに認証トークンを転送するための「よりクリーンな」ソリューションであることを理解しています。しかし、クライアント側のJavaScriptコードでは、世界は私には異なって見えます。

Cookieは「httpのみ」としてマークできるため、JavaScriptで簡単に盗むことはできません。ヘッダーはJavaScriptによっても設定する必要があるため、認証トークンはJavaScript内からアクセスできる必要があります。しかし、人々はauth-headersを使用して、信頼されていないクライアントJavaScriptからサーバーに認証トークンを送信します。

古き良き「httpのみで安全なフラグでcookieを使用する」から「JavaScriptに認証トークンを処理させる」に何が変更されましたか？それとも、「クライアント側でCookieを使用し、信頼された世界に入ったらすぐにauth-headerに切り替える」という正しい方法でしょうか？

PS：私は同様の質問に対して多くの回答があることを知っていますが、私の質問は「何が変わった、違う」という異なる視点からのものだと思います。

authenticationcookiesrestapi
21
rdmueller

Cookieベースの認証

長所

  1. HttpOnly Flag：HttpOnlyフラグで保護されたセッションCookieを作成できます悪意のあるJavaScript（XSS-Cross-Site Scripting）からのCookie。

  2. Secureフラグ：Secureフラグを使用してセッションCookieを作成し、暗号化されていないチャネルを介したCookie送信。

短所

  1. [〜＃〜] csrf [〜＃〜]：サードパーティのCookieはデフォルトでサードパーティに送信されるため、CookieはCSRF攻撃に対して脆弱/脆弱ですCSRFの脆弱性の悪用を引き起こすパーティドメイン。

  2. パフォーマンスとスケーラビリティ：Cookieベースの認証はステートフル認証であり、サーバーはすべての状態を維持するためにCookieをファイル/ DBに保存する必要がありますユーザー。ユーザーベースが増加すると、バックエンドサーバーはセッションCookieを保存するために別のシステムを維持する必要があります。

トークンベースの認証：

長所

  1. パフォーマンスとスケーラビリティ：トークンには、メタデータとその署名された値（改ざん防止用）が含まれています。それらは自己完結型であるため、サーバーで状態を維持する必要はありません。これにより、パフォーマンスが向上し、拡張が必要な​​場合のスケーラビリティが向上します。

  2. [〜＃〜] csrf [〜＃〜]：Cookieベースの認証とは異なり、トークンベースの認証はクロスサイトリクエストフォージェリの影響を受けません。トークンはデフォルトではサードパーティのWebアプリケーションに送信されません。

短所

  1. [〜＃〜] xss [〜＃〜]：セッショントークンはブラウザのローカルデータストレージに保存され、同じドメインのJS。したがって、Cookieベースの認証で使用可能なHTTPOnlyセキュリティフラグとは異なり、XSS攻撃からセッション識別子を保護するオプションはありません。

結論

前述のように、両方のメカニズムには独自の長所と短所があります。アプリケーション開発フレームワークの現在の時代には、次のような短所がありますXSSとCSRFは、基盤となるフレームワーク自体によって処理されるため、開発者と利害関係者がどちらを決定するかは、明らかにトレードオフであると思います。

17
Shiv Sahni

受け入れられた回答は、セッションベースの認証を照合することです。この場合、セッションはバックエンドデータベースで維持され、転送メカニズムであるCookieでステートフルになるため、長所と短所に欠陥があります。

認証トークンをCookieまたはヘッダーのどちらに保存するかは、クライアントによって異なります。クライアントが別のREST= apiである場合、ヘッダーを介してそれを渡すことは理にかなっています。

クライアントがブラウザの場合、あなたはできますトークンをローカル/セッションストレージに保存してから、ヘッダーを介してトークンを送信します（受け入れられた回答が言うように）、しかし、あなたが述べたように-これには脆弱性があり、推奨されません（これについてはこちらをご覧ください https://auth0.com/docs/security/store-tokens ）。

クライアントがSPAの場合は、トークンをメモリに格納するだけで済みます。これがおそらく最も安全なオプションですが、ページ間で新しいトークンを取得する必要があります。

ページ間の永続性が必要な場合でも、「昔ながらの方法」が最善の選択肢である可能性があります-Cookieをhttpのみで安全に提供し、csrf保護を実装しました（同じサイトのため、すぐにこれは必要なくなる可能性があります）プロパティ）。 csrf保護を実装すると、「Cookieを使用しないトークンベースの認証」のすべての利点とXSSに対する追加の保護が得られます。

9
Melbourne2991