百度一下”asp.net身份認證“，你會得到很多相關的資料，這些資料通常上來就會介紹諸如”Form認證“”Windows認證“等內容，而沒有給出一個完整的流程。初學者對此往往一頭霧水，我也曾經被坑過很多回，於是寫下此文，算是復習。
現代的Windows Server系統都是基於嚴格的用戶機制的，當你想操作服務器時肯定需要賬號密碼驗證的。當我們把開發好的Web應用程序部署在服務器后，用戶通過瀏覽器訪問該站點，實際上就是該用戶通過HTTP操作這台服務器的過程，本質上也是用戶操作服務器（至少是讀）的過程。這就產生了一個被大多數人忽略的問題：網絡用戶根本不知道服務器的賬號密碼，怎么會有讀寫服務器的權限？答案可以用下面一個簡單的圖給出：
用戶發起一個請求后，授權主要經歷IIS階段和ASP.NET階段。經過IIS時會得到系統賬號相關權限標識（或票據），使用該標識進入站點，這時asp.net運行時會把該標識轉化成.NET的一個用戶實體對象，我們就可以在自己的代碼中對該實體進行處理。通過一個具體的實例來認識一下，首先我們新建一個【不進行身份認證】的MVC項目（WebForm項目亦可），為了方便描述，就叫WebAuth吧！
項目默認有HomeController和三個Action：Index/About/Contact。編譯生成，並把它部署到iis上，為了方便我直接部署成http://localhost。就從這里開始身份認證之旅吧！
IIS階段
一、匿名身份認證
一般公司或個人開發ASP.NET的網站用的都是這種方式。比如剛剛部署的Web，我們在IIS的功能視圖中打開身份驗證：
可以看到默認的就是匿名身份認證。這種情況下不需要任何的認證，我們就可以訪問服務器上的內容。之所以能這么方便的訪問服務器的內容，是因為IIS在后台幫我們做了很多事情。當我們安裝IIS時，安裝程序會自動創建 IUSR_ComputerName 帳戶（其中 ComputerName 是正在運行 IIS的電腦名稱），普通用戶使用瀏覽器訪問該站點時，就是直接使用這個賬號來操作服務器。我們在開發過程中常常碰到讀寫服務器某文件沒有權限，這時百度一下，都會告訴你要修改IUSR_Computername用戶權限，就是這個原因。
二、基本身份認證
不修改任何代碼。我們在IIS中禁用”匿名身份認證“，啟用”基本身份認證“，這時我們再訪問項目的項目中的時，瀏覽器會彈出一個對話框要求用戶輸入自己的用戶名和密碼,如下圖：
這個賬號必須是服務器系統的賬號，且擁有對站點根目錄讀（寫）的權限。可以在目錄的文件夾屬性->安全性上設置。我專門添加了個賬號test，如下：
返回瀏覽器，輸入用戶名test和設置的密碼即可訪問項目的所有頁面。在不需要復雜用戶邏輯的項目中使用該方法，可以不用修改任何代碼實現認證。
不過基本身份認證有個非常嚴重的安全問題，通過這種方式的用戶名和密碼都以明文形式在網絡間進行發送，很容易被攔截獲取。而且要知道這個賬號可是服務器的賬號！可以用SSL加密來解決這個問題。
三、摘要式身份認證
摘要式身份驗證提供與基本身份驗證相同的功能，即當用戶訪問http://localhost 時同樣彈出輸入賬號和密碼的對話框。但是這種認證方式在通過網絡發送用戶憑據方面提高了安全性。具體流程如下：
- 客戶從運行 IIS 的服務器請求文件。
- IIS 拒絕請求，告訴給客戶端正在使用摘要式身份驗證，並發送領域名稱。
- Internet Explorer 提示用戶輸入憑據（用戶名和密碼）。然后，Internet Explorer 合並這些憑據和領域名稱以創建一個 MD5 哈希，並從運行 IIS 的服務器重新提交文件請求，此時發送的是 MD5 哈希。
- 運行 IIS 的服務器接收哈希，並將客戶端的哈希發送到域控制器以進行驗證。
- 域控制器向運行 IIS 的服務器通知驗證結果。
- 如果客戶端已經過身份驗證，則 IIS 將請求的文檔或數據發送到客戶端。
這里特別注意一下：什么是Active Directory？它就是一個普通的Windows服務，通過數據庫把系統的網絡對象信息存儲起來，比如系統的賬號，用戶組，共享資源等。可以方便使用者方便的查找和使用這些信息。
四 Windows身份認證
同上，這種認證方式對於客戶端用戶來說和基本認證並沒有什么區別，但實際上它比基本認證要復雜的多。這種方式在通過網絡發送用戶名和密碼之前，先將它們進行哈希計算。當啟用集成 Windows 身份驗證時，用戶的瀏覽器通過與 Web 服務器進行密碼交換（包括哈希）來證明其知曉密碼。集成 Windows 身份驗證是 Windows Server 2003 家族成員中使用的默認驗證方法。
Windows 身份認證主要有兩種方式：NTLM 方式和Kerberos V5。如果在 Windows 2000 或更高版本域控制器上安裝了 Active Directory 服務，並且用戶的瀏覽器支持 Kerberos v5 驗證協議，則使用 Kerberos v5 驗證，否則使用 NTLM 驗證。這兩種方式的詳細講解可參考A大的這篇文章：http://www.cnblogs.com/artech/archive/2011/01/24/kerberos.html
asp.net階段
上面四種是IIS服務器提供的驗證方式，當用戶通過IIS的用戶驗證后，就可以得到一個Windows的身份，這個身份將會被傳到我們自己的項目WebAuth中。打開工程的Web.config文件，有一項authentication配置：
<authenticationmode="Windows"/>
這里的Windows和IIS里的Windows身份認證不同。這里指將IIS獲取的Windows用戶直接傳到網站中使用，可以在index.cshtml中添加以下代碼訪問：
當前登錄狀態:@Request.IsAuthenticated<br/> 當前登錄用戶:@User.Identity.Name
IIS使用匿名認證以外的任何帶輸入框的認證，效果如下：
通常情況這種方式並沒什么卵用，絕大多數情況我們的IIS都只用“匿名身份認證”方式。然后在自己的站點里開發自己的用戶邏輯，將authentication的mode設置為forms，即我們耳熟能詳的Form認證。
Form認證的核心原理很簡單，用戶在請求信息中攜帶自己的身份證明（用戶名&密碼），站點驗證通過后，向用戶頒發一張證明身份的票據，客戶端通過Cookie的方式來存儲這個票據，在以后的請求中，通過在請求中附帶票據來證明身份。園子里有位大神通過以系列的實例講的非常清楚：http://www.cnblogs.com/fish-li/archive/2012/04/15/2450571.html，微軟官方為Form認證提供了全方位的支持與擴展----Membership及Identity！關於這兩種方式，騰飛兄在他的博客里面講解的也非常詳細：http://www.cnblogs.com/jesse2013/p/membership.html 及 http://www.cnblogs.com/jesse2013/p/aspnet-identity-claims-based-authentication-and-owin.html