Windows、Forms、Passport、Claims などの認証は、BROWSER認証方式です。これらは、ブラウザーがサーバーと通信して資格情報を提示するメカニズムです。それらは、データベースやその他のストレージ メカニズムとは何の関係もありません (ほとんどの場合..)。これらは単なる実装の詳細です。
FormsAuthentication は、Cookie を使用して、ユーザーが認証されたことをサーバーに伝える暗号化された値を格納します。データベースとの比較、サービスの使用など、ユーザーがどのように認証されるかは、最終結果が FormsAuthentication Cookie の発行である場合、すべて無関係です。
WindowsAuthentication は、ブラウザーと Web サーバーが通信して Kerberos チケットを共有して身元を確認するか、サーバーがブラウザーにポップアップを要求するボックスにユーザーがユーザー名パスワードを入力するという点で少し異なります。このモードでは、サーバー自体が認証の方法を管理し、アプリは関与しません。
BasicAuthentication は、HTTP ヘッダーを使用してパスワードを平文で送信します。技術的には暗号化されたパスワードですが、よく知られているため、誰でも暗号化を解除できます。繰り返しますが、データを格納する実際の方法はサーバー次第であり、サーバーはアプリケーションの知識がなくてもこれを行います。重要な部分は、HTTP ヘッダーを介して実行されることです。
他のタイプの認証にも同じことが当てはまります。これらはすべて、Cookie および/またはヘッダー メカニズムの単なるバリエーションです。
ここでのポイントは、認証とは、特定の HTTP 要求がどのようにユーザーがサーバーに対して、そして最終的にはアプリケーションに対して誰であるかを識別する方法に関するものであるということです。データの保存方法や検証方法ではありません。したがって、サーバーとブラウザーがどのように通信するかを教えてくれなかったので、認証がどのように定義されているかはわかりませんが、それはほぼ間違いなく FormsAuthentication のバリエーションです。
編集:
ちょっとだけ歴史のお勉強。FormsAuthentication と呼ばれる理由は、認証システムがブラウザーからのポップアップ ダイアログ ボックスを使用して資格情報を入力しないためですが、通常、Web ページはユーザーが資格情報を入力するための HTML フォームを提供します。ブラウザーは、要求に応じて Cookie を渡す場合を除いて、認証プロセスにはまったく関与しません。
より正確には「CookieBasedAuthentication」と呼ばれるべきですが、名前は固定されており、おそらくそのままになります。ASP.NET は FormsAuthentication と呼ばれる特定の実装を提供しますが、任意の Cookie ベースの認証スキームで同じことを行うことができます (自分で作成することはお勧めしませんが、ほぼ確実にセキュリティ ミスを犯すことになります)。
Session にフラグを格納するだけで十分だと考える人もいます。いかなる状況でも、Session を使用して認証情報を保存しないでください。セッション Cookie は暗号化されていないため、簡単に盗まれたり、なりすましが行われたりします。よく知られている方法を使用します。