web-dev-qa-db-ja.com

セッション認証とトークン認証

私はいくつかの用語とメカニズムを理解し、それらが互いにどのように関連しているか、またはどのように重複しているかを調べようとしています。理論上のWebアプリケーションとモバイルアプリケーションの認証が焦点です。 焦点は、トークンベースの認証とCookieベースの認証の正確な違いと、それらが交差するかどうか/どのように交差するかにあります。

http基本/ダイジェストおよびoauth/aws authのような複雑なシステムは私に興味を示しません

いくつかのアサーションがあります。アサーションを出して、それらが正しいかどうかを確認したいと思います。

  1. モバイルアプリケーションでは、セッションなしの認証トークンのみを使用できます。ブラウザコンテキストでは、トークンをクライアントサイドで永続化するためにCookieが必要です。
  2. 資格情報（通常はユーザー名/ pw）をトークンと交換すると、範囲と時間を制限できます。ただし、これは、トークンとそれに関連するすべてのものもサーバーで永続化して処理する必要があることも意味します。
  3. トークンはサーバーサイドで取り消すことができます。 Cookieにはそのオプションがなく、期限切れになります。
  4. Cookieのみを使用するということは、sessionidがユーザーアカウントに関連し、いかなる方法でも制限されないことを意味します。

私はマークから遠すぎず、どんな助けにも感謝しています！

authenticationcookiessession-managementtoken
100
Hoax

  1. Session-based Authenticationでは、サーバーは負荷の高いサーバー側をすべて実行します。大まかに言えば、クライアントはその資格情報で認証し、session_id（Cookieに保存できます）を使用して、これを後続のすべての発信要求に添付します。したがって、これは資格情報のセットに相当するため、「トークン」と見なすことができます。ただし、これについて特別なことは何もありませんsession_id ストリング。これは単なる識別子であり、サーバーは他のすべてを行います。ステートフルです。識別子をユーザーアカウントに関連付けます（たとえば、メモリ内またはデータベース内）。このセッションを特定の操作または特定の期間に制限または制限し、セキュリティ上の懸念がある場合はセッションを無効にすることができます。さらに重要なことは、これらすべてをオンザフライで実行および変更できることです。さらに、それはウェブサイト上のユーザーのあらゆる動きを記録することができます。考えられる欠点は、拡張性が低いこと（特に複数のサーバーファームで）とメモリ使用量が多いことです。

  2. Token-based Authenticationでは、セッションはサーバー側に保持されません（ステートレス）。最初の手順は同じです。資格情報はトークンと交換され、トークンはその後のすべてのリクエストに添付されます（Cookieに保存することもできます）。ただし、メモリ使用量、簡単な拡張性、および全体的な柔軟性（トークンは別のクライアントと交換できます）を減らすために、必要なすべての情報を含む文字列（トークン）が発行されます。サーバ。トークンを使用/作成する方法はいくつかあります。

    1. ハッシュメカニズムの使用。 HMAC-SHA1

      token = user_id|expiry_date|HMAC(user_id|expiry_date, k)

      どこ user_idおよびexpiry_dateは、結果のハッシュが添付されたプレーンテキストで送信されます（kはサーバーだけに認識されます）。

    2. 対称的にトークンを暗号化するAESを使って

      token = AES(user_id|expiry_date, x)

      ここで、xは暗号化/復号化キーを表します。

    3. それを非対称に暗号化します。 RSA

      token = RSA(user_id|expiry_date, private key)

生産システムは、通常、これらの2つのアーキタイプよりも複雑です。たとえば、Amazonはそのウェブサイトで両方のメカニズムを使用しています。また、ハイブリッドを使用して、2で説明したようにトークンを発行し、ユーザーセッションをトークンに関連付けて、ユーザーの追跡や失効を可能にし、クラシックトークンのクライアントの柔軟性を維持することもできます。また、OAuth 2.0は、たとえばベアラトークンを取得するために、存続期間の短い特定のベアラトークンと長寿命のリフレッシュトークンを使用します。

出典：

114
Hoax

HTTPはステートレスであり、認証された状態にするためには、ユーザーに関する情報を参照するために使用されるある種のトークンが必要です。このセッションIDは通常、Cookie値として送信されるランダムトークンの形式です。 OAuth Access Token は、ユーザー、およびユーザーがアクセスできるリソースのscopeを識別するために使用されます。 OAuthシングルサインオンを使用するアプリケーションでは、通常、OAuthアクセストークンがセッションIDと交換され、さまざまなユーザー状態を追跡できます。

攻撃者の観点から見ると、セッションID、またはOAuthアクセストークンのハイジャックは、ユーザー名とパスワードと同じくらい優れており、場合によってはそれよりも優れています。 セッションIDにはセキュリティプロパティが必要です ユーザーアカウントを侵害から保護します。

開発者の観点から、ホイールを再発明しないでください。プラットフォームが提供するセッションマネージャを使用し、 OWASPセッション管理ガイドライン に準拠するように構成されていることを確認します。

7
rook

したがって、セッションベースの認証で、必要なリソースへのアクセスのセキュリティを強化するには：

  • ユーザーの資格情報の代わりとして使用する必要があります
  • 常に永続的なCookieを使用する必要があります
  • ウェブサイトに戻ってくるユーザーを特定する必要があります
  • 2要素認証を使用する必要があります
0
Mu Mor