web-dev-qa-db-ja.com

OAuthアクセストークンとセッションキー

以下の仮定の下でOAuth対cookieベースのセッション（ユーザー名/パスワードで確立））に利点はありますか？

  1. サービスへの正当なクライアントは1つだけです
  2. OAuthクライアントシークレットが侵害されました（そのため、有効なリクエストはだれでも発行できます）
  3. OAuthトークンとセッションのライフタイムは同じです
  4. どちらも同じ権限で同じリソースのセットにアクセスできます
  5. いずれかのスキームでのすべてのクライアント/サーバー通信は、同じプロトコルを介して行われます（議論のために、HTTPS）
  6. クライアントとサーバーは同じパーティによって制御されています
cookiessession-managementoauth
16
Michael Mior

まあ、それは異なります...

OAuthは、セッションを作成するためのプロトコルです。 OAuthベアラートークンは、Authentication: Bearer HTTPヘッダー。これは、httpヘッダー要素を介して送信される単なる暗号ナンスであり、実際にはcookie httpヘッダー要素と（most）と同じです。

どう違うの？まあ、クッキーのルールは他のヘッダー要素とは少し異なります。 cookieはbrowserによって維持され、cookieが属するすべてのリクエストに添付されます。これが Cross-Site Request Forgery またはセッションライディング攻撃が機能する理由です。ブラウザはリクエストがどこから来たかを気にせず、リクエストの宛先に基づいてクッキーを添付します。

OAuthベアラートークンは少し異なります。これらのトークンは通常、クライアント（JavaScript、Flash、または一部のミドルウェアアプリケーション）によって管理されます。アプリケーションがJavaScriptを使用して認証ベアラートークンを管理する場合、この値はブラウザーによって自動的に適用されないため、CSRFトークンとしても機能します。 、すっきりしています。

ただし、ミドルウェアにOAuthを使用している場合、CSRFは機能しないため、ヘッダーのどこに表示されるかは関係ありません。

13
rook

CSRFは、すべての最新のブラウザーによってすでに保護されています。宛先に基づいてCookieを添付するだけでなく、検証がサーバーに送信する前にOriginのポリシーを許可する場合、調査後にoauth2とセッションベースの認証はどちらも同じセキュリティになります。リスクと唯一の違いは、使用されているヘッダーです

3
user2795270