关于 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 认证时，发送用户信息的实现，参考