ASP.NET 身份驗證全攻略：七大方式原理與實戰測試

前言：為什麼需要身份驗證？

在 B/S 系統開發中，「身份驗證」是資安的第一道防線。Web 應用程式公開於網際網路或區域網路後，若無任何驗證與權限控管，任何人皆可存取資源，極難保障安全性。內部系統通常要求使用者登入才能操作；公開網站雖大多數頁面開放，但涉及個人資訊或後台管理時，仍須強制登入。若開發人員疏忽未驗證，駭客猜測頁面路徑即可隨意存取，後果不堪設想。

ASP.NET 如何實現身份驗證？

早期開發者常使用 Servlet/JSP 的「過濾器」或 ASP.NET WebForm 的「BasePage」基類集中判斷 Session/Cookie。微軟其實提供完整的會員角色管理機制（登入控制項、Membership、個人化資料庫），但許多開發者鮮少使用。實務上，ASP.NET 身份驗證主要分為數種，部分依賴 IIS 與 Windows 作業系統，不同版本間略有差異。本文以 Windows 7 / IIS 7.5 為例說明。

IIS 7 支援的七大身份驗證方式

在 IIS 管理員中雙擊「驗證」即可看到所有支援方式（安裝時若全勾選安全性功能）：

1. Active Directory 用戶端憑證： 可能涉及授權費用，較少使用。
2. ASP.NET 模擬： 用於非預設安全內容下執行應用程式，設定較繁複。
3. 表單驗證： 最常用、彈性最高的方式，後文詳述。
4. Windows 驗證： 基於 Windows 本機或網域帳號驗證。
5. 基本驗證： 同樣基於 Windows 帳號，但傳輸編碼方式不同。
6. 匿名驗證： 允許所有人存取，內部透過特定 Windows 系統帳號（預設為 IUSR）進行驗證。
7. 摘要驗證： 使用 Windows 網域控制器驗證使用者身分。

對比經典 IIS 6 畫面：

註：.NET Passport 可視為微軟早期的單點登入 (SSO) 實作，今已較少見。現今 Open API、SOA、雲計算盛行，Web 開發者若不了解 SSO，建議補齊相關知識。

實戰測試：基本驗證

停用其他驗證，僅啟用「基本驗證」。瀏覽器訪問網站時會彈出登入對話框，樣式因瀏覽器而異：

輸入正確 Windows 帳號密碼即可存取；否則回傳 401 錯誤。注意：基本驗證僅以 Base64 編碼帳號密碼，極易解碼，等同明文傳輸，若未啟用 SSL（HTTPS），資料極易被竊聽。IIS 警告訊息雖措辭生硬（提及「纜線明文傳輸」），核心提醒是：生產環境務必搭配 SSL 憑證使用基本驗證。

實戰測試：Windows 驗證

操作類似基本驗證，差異在於錯誤代碼為 401.1（基本驗證為 401.2）。Windows 驗證採用 NTLM/Kerberos 協定，瀏覽器與作業系統直接交換憑證，不經由 HTTP 實體傳輸。雖傳言僅 IE 支援，實測 Firefox 亦可正常運作。

匿名驗證機制

本質上等同「不驗證」，允許匿名存取。實際運作時，IIS 會使用 Windows 使用者群組中的特定帳號（如 IUSR）作為匿名身分：

一般公開網站會同時啟用匿名與 Windows 驗證，兼顧公開瀏覽與後台管理需求。

重頭戲：表單驗證

前述方式皆屬 IIS/作業系統層級，與 ASP.NET 無直接關聯。表單驗證則需 ASP.NET 運行時支援，適用於複雜的會員管理、角色權限、部分頁面需登入等情境。實作方式多樣，常搭配資料庫儲存使用者憑證、Cookie 追蹤登入狀態、授權規則控制存取權限。後續文章將深入探討表單驗證的進階實作技巧。