web-dev-qa-db-ja.com

Cookieベースvsセッションvsトークンベースvsクレームベースの認証

認証について読み、型の分類について混乱しました。

Cookieベースの認証から始めましょう。私が正しく理解していれば、重要な点は、ユーザー認証に必要なすべてのデータがCookieに格納されるということです。そしてこれが私の最初の混乱です。

  • セッションIDなので、セッションベースの認証になりますか？
  • クレーム、そしてそれはクレームベースの認証と呼ばれるべきですか？
  • JWTトークンをCookieに保存している人もいることがわかりましたが、これは独自の認証フローのカスタム実装のようです...

次に、クレームベース認証に切り替えます。主な要素はクレームであり、クレームのコレクションはコンテナーとして使用できます

  • cookie（上記で説明）
  • トークン（例としてJWT）。

反対側から、トークンについて話しているとき、トークンにはあらゆる種類の情報が含まれている可能性があります...たとえば、セッションID ...

それで私は何を逃したのですか？認証タイプについて話すとき、人々はなぜCookie-Session-basedまたはToken-Claims-based認証のようなものを定義しないのですか？

authentication
26
Set

さまざまな概念の命名がわかりにくいことに同意します。 Webコンテキストでの認証について話すとき、考慮すべきいくつかの側面があります。

認証時にクライアントはどのような情報を送信しますか？

  • セッションID。つまり、サーバーにはアクティブなセッションを含むセッションストレージがあります。セッションはサーバー側でstatefulです。
  • クレームのセット。クレームには、クライアントが実行できる操作に関する情報が含まれています。サーバーは、認証された各クライアントを追跡しませんが、クレームを信頼します。クレームは通常、サーバー側ではstatelessです。

クライアントはどのように認証情報を送信しますか？

  • Cookies。ブラウザは、Cookieが設定された後、リクエストごとに自動的にCookieを送信します。 CookieはXSRFに対して脆弱です。
  • その他のヘッダー。通常、Authorizationヘッダーがこれに使用されます。これらのヘッダーはブラウザによって自動的に送信されませんが、クライアントによって設定される必要があります。これはXSSに対して脆弱です。
  • リクエストURL。認証情報はURLに含まれています。これは一般的には使用されません。

認証情報の形式を教えてください。

  • プレーン、署名されていないテキスト。これはセッションIDに使用できます。通常、セッションIDはクライアントが推測できないため、サーバーはクライアントが偽造していないと信頼できます。
  • Json Web Token。 JWTは暗号で署名され、有効期限情報が含まれています。クライアントは通常、トークンをデコードできますが、サーバーに通知せずにトークンを変更することはできません。
  • その他の署名された形式。 JWTと同じ。重要なことは、クライアントがデータを変更するのを防ぐ暗号署名です。

おまけ：クライアントはどのように情報をローカルに保存しますか

  • Cookies。もちろん、これはCookieを使用して情報を送信する場合です。ただし、Cookieはクライアント側のストレージメカニズムとしても使用できます。これには、Cookieがスクリプトから読み取り可能であることが必要です。たとえば、クライアントはJavaScriptでCookieを読み取り、Authorization-Headerで情報を送信できます。
  • ローカルストレージ。 Cookieが利用できない場合、これが唯一の可能な方法です。 JavaScriptによる管理が必要です。

彼らが言うとき人々は何を意味します...

  • "Cookieベースの認証"。通常、これは「セッションID、Cookieで送信、プレーンテキストとして可能」を意味します。
  • "トークンベースの認証"。通常、これは「請求、Json Webトークンとしてエンコードされた認証ヘッダーを使用して送信する」ことを意味します。
  • "クレームベースの認証"。セッションID以外でもかまいません。
38
TheFogger

簡単に言えば、

  1. Cookieベースの認証

    • Webクライアント（例：webブラウザー）は、認証が成功した後にWebサーバーから送信されたCookieを保存します。
    • Cookieには、ユーザー、クライアント、authNタイムスタンプ、およびCookieを特定するための一意のIDを持つその他の有用なデータに関する情報が含まれています。
    • 通常、Cookieはドメイン属性が設定されたWebサーバーによって暗号化されます（例：google.com）をウェブクライアントに送信します。
    • ウェブクライアントがドメインリソースにアクセスする場合（例：mail.google.com）、ドメインに基づいてすべてのCookieを送信します（例：google.com）をWebサーバーに送信します。Webサーバーは、Cookieの状態とタイムスタンプに基づいてアクセスを検証/確認し、許可/拒否します。

  2. セッションベースの認証

    • WebクライアントCookieとともに、WebサーバーがユーザーのauthNデータをバックエンドに保存する場合、セッションベースの認証と呼ばれます。
    • これは、Webクライアントがアクセスすべきではないシステムにアクセスして違反が発生した場合に非常に役立ちます。バックエンドからWebクライアントのセッションを管理者が取り消すことができます。

  3. トークンベースの認証

    • 通常、これは非Cookieクライアントのシナリオで使用され、クライアントサイドにCookieを保存する方法はありません。
    • したがって、認証が成功した後、Webサーバーは署名されたトークン（ユーザー、クライアント、authNタイムスタンプ、および一意のIDを持つその他の有用なデータを含む）をクライアントに送信します。
    • クライアントがリソースにアクセスする場合は常に、このトークンを送信する必要があり、リソースへのアクセスを許可する前に、Webサーバーがトークンを検証/検証します。

  4. クレームベースの認証

    • これはトークンベースの認証と同じですが、クライアントやクライアントに関連付けられているユーザーに関するデータをトークンに追加するだけです。
    • これらのデータは、クライアントがリソース内で何をすべきかについて話す承認に関係しています（例：mail.read、mail.delete、calendar.read）。
3
Zeigeist