認證與授權
認證與授權，Authentication and Authorize，這個是兩個不同的事。認證是對訪問身份進行確認，如驗證用戶名和密碼，而授權是在認證之后，判斷是否具有權限進行某操作，如 Authorize 屬性。簡單說，他們之間先后順序是先認證，再授權。
Web Api 的客戶端可以是瀏覽器，GUI 應用程序，各移動設備應用等等，設計的 Api 可以供自己使用，也可以供別人使用。因為很多人習慣了 IIS ，當 Web Api 寄宿在 IIS 上時，他們習慣了 Cookie 的方式，但 Owin Self Host 的出現，以及不同端的出現，Cookie 一下就成了麻煩的事了，不能解決問題了。
那該怎么辦呢？觀看現在各平台提供 Api，第三方應用使用數據前，都是先進行認證，然后返回 token 信息，然后每次的請求都將 token 信息一起發送過去，就是 Api 的請求都是每次需要進行驗證的，在沒有 Cookie 的情況下，token 信息怎么發送呢？
- 與 Query String 一起
- 放到 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 認證時，發送用戶信息的實現，參考