认证与授权
认证与授权，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 Slef 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 认证时，发送用户信息的实现，参考