關於 Web Api 2 認證與受權

認證與受權

認證與受權，Authentication and Authorize，這個是兩個不一樣的事。認證是對訪問身份進行確認，如驗證用戶名和密碼，而受權是在認證以後，判斷是否具備權限進行某操做，如 Authorize 屬性。簡單說，他們之間前後順序是先認證，再受權。

Web Api 的客戶端能夠是瀏覽器，GUI 應用程序，各移動設備應用等等，設計的 Api 能夠供本身使用，也能夠供別人使用。由於不少人習慣了 IIS ，當 Web Api 寄宿在 IIS 上時，他們習慣了 Cookie 的方式，但 Owin Self Host 的出現，以及不一樣端的出現，Cookie 一下就成了麻煩的事了，不能解決問題了。

那該怎麼辦呢？觀看如今各平臺提供 Api，第三方應用使用數據前，都是先進行認證，而後返回 token 信息，而後每次的請求都將 token 信息一塊兒發送過去，就是 Api 的請求都是每次須要進行驗證的，在沒有 Cookie 的狀況下，token 信息怎麼發送呢？

1. 與 Query String 一塊兒
2. 放到 Request Header Authorization 裏面

使用 postman 進行測試 Api 的時候，就能感覺到了。這裏主要講第 2 種方式，使用 IIS 的狀況就不講了，由於可使用 HttpConext(System.Web.dll)，那麼使用 Owin Self Host 方式，該怎麼去實現認證呢？

 

Web Api 認證明現

這裏不考慮數據傳輸安全的問題。認證前先要作好準備工做，提供一個 Api 認證接口，如 Login，認證成功後返回 token（用戶信息及超時時間等信息），後續的 Api 調用就要經過 token 進行認證與受權了。這裏有 3 種實現方式：

MessageHandler 參考 

這是 Web Api 有的方式，經過繼承 DelegatingHandler ，獲取 token 信息，而後進行認證，只需將實現的 MessageHandler 假如配置便可：

1 config.MessageHandlers.Add(new BasicAuthenticationHandler());

Attribute Filter 參考

經過實現自定義的 Authorize 屬性，獲取 token，而後進行認證

Owin Middleware 參考

當 Web Api 寄宿在 Owin Self Host 上時，能夠經過實現本身的 Middleware 來認證，並且相比 Message Handler 的好處是，Message Handler 只對 Web Api 有效，而 Middleware 能夠對其餘寄宿在 Owin 上的 Application 都有效，如 SignalR 等

固然正確的作法應該是繼承 Microsoft.Owin.Security.AuthenticationMiddleware 來實現，能夠參考 Katana Project 其餘的認證明現

 

總結

看了不少資料才瞭解到這些實現方式，其實都是由於本身知識儲備不夠，首先連認證和受權都搞混了，而後是以前 Asp.Net 模式的羈絆，阻礙了接受新鮮事物。面對新東西，仍是先要搞清概念與原理，而後分析處理的邏輯，就能定位到解決問題要關注的點，因此啊，仍是要多學習，深刻學習。

HttpClient 進行 Basic 認證時，發送用戶信息的實現，參考