認証について読んだことがあり、型の分類について混乱するようになりました。

Cookieベースの認証から始めましょう。正しく理解できれば、重要な点は、ユーザー認証に必要なすべてのデータがCookieに保存されるということです。そしてこれが私の最初の混乱です：クッキーに私たちは保存するかもしれません

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

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

• Cookie（上記のとおり）
• トークン（例としてJWT）。

反対側から、トークンについて話しているとき、それはあらゆる種類の情報を含んでいるかもしれません...例えばセッションID ...

だから私は何を見逃しましたか？なぜ人々は、何かのように定義していないCookie-Session-basedか、Token-Claims-based認証の種類について話したときに認証を？

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

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

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

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

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

認証情報の形式は何ですか？

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

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

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

彼らが言うとき、人々はどういう意味ですか...

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

簡単に言えば、

1. Cookieベースの認証

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

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

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

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

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

4. クレームベース認証

   • これはトークンベースの認証と同じですが、クライアントおよび/またはクライアントに関連付けられたユーザーに関するトークンにデータを追加する点が異なります。
   • これらのデータは承認に関連し、クライアントがリソース内で何をするかについて話します（例：mail.read、mail.delete、calendar.read）。