前言
webapi接口是开放给外部使用的，包括接口的地址，传参的规范，还有返回结果的说明。正因为接口的开放性，使得接口的安全很重要。试想一下，用抓包工具（如fiddler)，甚至浏览器获取到接口的规范后（甚至可以猜到接口的其它规范），如果接口没有做”安全“这一道防火墙，任何人都可以调用接口来获取及提交数据，这真是太可怕了。17年我负责一个气象类项目的开发，其中有些功能是我们无法完成但甲方要求必须有的功能，并给我们展示了实现该功能的一个产品。后面通过对此产品的fiddler抓包分析，了解了该产品是通过接口向apps端提供数据，而所有的接口竟然都没有加密，于是这个项目基于此功能的实现基本上都是通过调用该产品的接口实现，对我来说是省去了很大的开发成本，但对于那个产品的公司来说是损失了有价值的数据。
对于webapi方面的安全，可写的东西太多了，且asp.net webapi及asp.net core webapi在安全方面也有些差异。我只对”webapi框架搭建“项目里用到的技术做一些说明。后续的博客会对每一个技术的实现做详细的描述。
JWT技术
考虑http的无状态性，且又必须让服务器能区分每次的http请求是”谁“发出的，但又不想在http请求里携带很多信息（尽量每次的请求包比较小），我采用token技术。即将用户的基本信息，如用户id，用户的角色等进行加密，并附在http请求头里。服务器端只要对token进行解密后就能知道是谁发起的请求。之前我是自己生成token，规范token的加密/解密规则和token里存储的信息（如一个user实体的信息），后面发现这一技术已经有一个规则，那就是jwt。jwt参考如下网站：https://jwt.io/。
webapi安全
微软对webapi的安全拆分为authentication和authorization，authentication的职责是解决”用户是谁“的问题，而authorization的职责是解决”是否有权限“的问题。通过jwt技术，可以解决”用户是谁“的问题，通过”基于角色的权限控制“可以解决”是否有权限“的问题。后续的博客会详细说明。
安全的”切入点“
我们肯定不想在每个接口里都去写一段”安全代码“，而是用aop的思想，在整个http请求的生命周期中做为一个切面插入到生命周期的某个点上。所以先让我们了解下webapi的生命周期。如下图。
对于在哪一个环节做为安全机制的切入点，微软的一篇文章里说的很好：https://msdn.microsoft.com/en-us/magazine/dn781361.aspx。我总结如下
Http Module：如果webapi的host为iis，所有的请求会通过httpmodule，可以创建自己的httpmodule并在该类里写安全机制的代码。缺点是和iis耦合了。而我们现在的教程里用的是owin技术。所以先排除。
owin middleware：如果webapi的host为owin，可创建自己的安全middleware组件，并注册到owin管道里。只要webapi组件注册在该组件之后就行。且这种方式有一个优点（也能说是它的缺点），不仅可以用于webapi框架，也可以用于其它框架的安全，只要该框架可以注册在owin管道里就行。
http Message handler：从上图可以看出，请求从httpserver出来后的第一个通道就是http message handler。微软的这篇文章里也提到怎么用这种方式去实现：https://docs.microsoft.com/en-us/aspnet/web-api/overview/security/authentication-and-authorization-in-aspnet-web-api。
action filter：可以但不建议的方式，良好的安全通道是http请求先经过authentication再经过authorization（即要先知道这个人“是谁”才能知道他有什么“权限”）。但从图可以看出action filter是在authorization filter之后，虽然可以不用authorization filter，只用action filter，但毕竟有点怪异。
authentication filter和authorization filter：推荐的方式。
原文链接：https://www.cnblogs.com/shengyu-kmust/p/8283383.html
原创文章，作者：优速盾-小U，如若转载，请注明出处：https://www.cdnb.net/bbs/archives/17133
