聊聊常见的服务(接口)认证受权

写在前面

头发掉得多了，总有机会接触/调到各类各样的接口，各类面向Api编程实际上已经嵌入到咱们的习惯中，没办法如今服务端通讯还得是http(s)，其余协议还未能成为通用的。

大厂的开发平台api我先不敢说，各类小公司、或者很多大公司内部之间，各类各样的的接口签名/受权方式能够说是尽显劳动人民智慧、八仙过海，各显神通。固然，我也曾是八仙中一员大将；

然而，不能总当神仙，偶尔也要作下凡人。下面咱们聊聊常见的服务受权方式；

Basic Auth

Basic Auth使用base64编码把 username:password (注意中间有个半角冒号)加密后放入请求头：

好比帐号密码 hei:123 ， base64后在request--header这样:

Authorization: Basic aGVpOjEyMw==

Postman支持

总结：

优势：简单明了，特别容易理解；

缺点：由于简单，且几乎是明文的形式传递，总得来讲不够安全；且要配合权限啊、受权策略啊要花挺多成本；

看场景使用；

Key Auth

这个别看名字起得高大上，其实也就是你先定义一个 KeyName，KeyValue,调用方和接口定义方约定这个Key放在--header或者Query Params里，到时按约定好的取出就好；

好比我定义了的

KeyName: apikey

KeyValue: hei.key.7LimLB5qXHtuBsI7HpxM9mj447ME3GlNoe7WxKL5

约定好放到Header里。

Postman支持

总结： 跟basic auth 同样，仍是不够安全，虽然能够经过添加超复杂的keyValue提升安全性。但记住，只要是固定的key，永远都是不安全的。看场景使用。

Jwt Auth

这个知识点但是但是博客园的常客了，三天两头都有相关博文；但毕竟本片不是jwt专题，我就不长篇阔论了简单聊聊；

首先jwt是啥

Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（(RFC 7519)，

传递信息的标准的说白了就是一种数据格式，它分红三个部分组成，中间用.隔开：

（图来自龙哥的博客）

//上图三部分通常这样组成，因此整个jwt都是base64的（除了那两个分割的'.'）
base64Url(Header)+"."+base64Url(Payload)+"."+base64Url(Signature)

具体的一个jwt

eyJhbGciOiJSUzI1NiIsImtpZCI6IjY1OTMxODE4QjYxQkIzQTVEMUIxN0Y0MEVCRTlEQkY2IiwidHlwIjoiYXQrand0In0.eyJuYmYiOjE1OTcxNDIxNzgsImV4cCI6MTU5NzE0OTM3OCwiaXNzIjoiaHR0cDovLzE3Mi4xNi4zLjExNzo1MTAwIiwiYXVkIjpbIm9jZWxvdCIsImh0dHA6Ly8xNzIuMTYuMy4xMTc6NTEwMC9yZXNvdXJjZXMiXSwiY2xpZW50X2lkIjoib2NlbG90LmNsaWVudCIsImp0aSI6IkQxRkExNkE3MkM1RDY4RDEyMTMzM0RGRjRDRDBCM0Q4IiwiaWF0IjoxNTk3MTQyMTc4LCJzY29wZSI6WyJvY2Vsb3QuYWRtaW4iXX0.PCN_Q77r0IyaesLy-Q0lTV12EYD9GkywrDMfxrCBj3ac9YltW8RzczAqdn2f92iysf_5Iu6hvTm16z9MJay6-eGWBiuIgJRXaCDlTqWWKcI8rWmW17ncyJT5oIgwip54Tfder9AfJOUJ-K0U2zT0fsrnBf7CZDLmkAAFHoxky1dzmPnh7JM4EkjtC-ybLOu_Aav7GgIOyYfodovxNgMvGHdhmheJLjxpjGblfI6o3rH8fRedwoV8zCY8MxJRGVcqg8slo0E9wfsebNx8hCV1mLHJbuDbJ1DCnDQ_1I1pFEFZCVNE2g0R-LRMC7opfFcveorNvZcJ8zEPWcACqoGXZg

咱们 复制到https://jwt.io/ 解析看看：

能够很清楚的看到， header部分是说明Token的类型和所使用的算法，payload部分就是受权信息，好比用户名啊、哪一个服务器，何时发的、何时失效等等。signature部分是签名信息，防止篡改。

通常是怎么用jwt的

我借龙哥个图来讲明下

1. 通常咱们先定义一个颁发token服务（Auth Service --Api），服务调用方携带受权信息申请token;
2. Auth Service验证受权信息后返回jwt;
3. 服务调用方携带jwt请求受保护接口；
4. 受保护接口验证jwt 的有效性，验证有没有权限、是否在有效期、有没有被篡改等（这里不用到Auth Service验，也就是去中心化的方式，这是jwt的一大有点）。这里写着是网关，其实也能够写在接口的过滤器那里，不过这样每一个项目都要实现一遍验证逻辑了。
5. 这里已经解析完jwt，打扰能够携带jwt的信息去调用接口啦；
6. 响应，流程完；

其实你们都差很少这么用的，不论是自定义实现仍是用第三方的中间件形式，具体看需求；

Postman支持

总结：

优势

• 由于json的通用性，因此JWT是能够进行跨语言支持;

• 由于有了payload部分，因此JWT能够在自身存储一些其余业务逻辑所必要的非敏感信息。

• 便于传输，jwt的构成很是简单，传输字节不大，高性能。

• 去中心化，高性能；

缺点

• 安全性：若是是彻底去中心化的方式，若是jwt给黑客截取了，是没有办法吊销的，开发的时候能够考虑下如何解决这个问题；
• 携带的信息是彻底开放的，不能携带安全性高的加密信息，只能说有限安全性，依然看场景使用，不过个人经验，平常开发绝大部分时候够用了。

Oauth2--client_credentials（客户端凭证）模式

Oauth2.0 有多种模式，好比Authorization Code、Implicit Flow、Password Grant等、咱们今天只来看client_credentials--客户端配置模式吧。

咱们先看官方的流程图：

+---------+                                  +---------------+
     |         |                                  |               |
     |         |>--(A)- Client Authentication --->| Authorization |
     | Client  |                                  |     Server    |
     |         |<--(B)---- Access Token ---------<|               |
     |         |                                  |               |
     +---------+                                  +---------------+

能够看到很是简单，他其实只要:

A、Client携带受权信息（client_id,client_scret，scopes,grant_type等）去Authorization Server 申领AccessToken；

B、Authorization Server 颁发AccessToken；

而后你就能够用这个AccessToken 调用 受保护的接口了；

咱们来看看实例：

一、先请求AccessToken

二、携带AccessToken 调用受保护接口

Postman支持

其实这里的header是这样的：

Authorization: Bearer ZJg0rak2ZYKyZeBTH7zJzDl94AjkfwiE

那能够看到咱们的AccessToken ，很明显很简短，看状况是不携带任何信息的。那意味着它每次调用都须要去Authorization Server验证AccessToken 才行，这样接口调用量瞬间翻倍了，性能确定受影响。咱们能不能像上面提到的jwt同样，用jwt 作token，去中心化呢？

答案是能够的，Oauth2.0-client_credentials模式自己是对流程的标准化，并无限制token类型，因此咱们是能够用jwt作token，可是又涉及到一个问题受权是OAth2.0的活,若是你加入jwt作身份区分那其实已是OpenId Connect的活了，那又是另外一个话题了。但那实际上是一个很是好的设计，咱们.net core里面就用这么个方案实现的框架IdentityServer4；

总结：identityserver4真香；

Hmac Auth

Hmac的全称是Hash-based Message Authentication Code（基于哈希的消息认证码）， 看起来有点蒙，咱们先来看个例子，好比咱们有以下的接口地址：

http://api.hei.com?userid=23233&age=18&type=normal

咱们常常会这样给咱们接口加签名：

1. 先把query参数全小写后，按a-z排序为，用&隔开：age=18&type=normal&userid=23233
2. 对参数32位小写md5, md5_32(“age=18&type=normal&userid=23233”) 获得sign：a8b8a635cc34b95a8788abfa6f6b9ff2
3. 把sign加在请求参数后面：http://api.hei.com?userid=23233&age=18&type=normal&sign=a8b8a635cc34b95a8788abfa6f6b9ff2
4. 服务端按一样的方法验证参数；

若是咱们把以上的 md5_32(“排序参数”）加“盐”改成：md5_32(my_secret_key，“排序参数”） 这就是：

Hmac-Md5 算法，同理，还有：

Hmac-SHA1

Hmac-SHA384

Hmac-SHA256

Hmac-SHA512

等等算法，主要的区别在于哈希算法的不一样。由于安全性有必定的报障，各类语言里面都会有对应的语言无关的实现，好比.net core 里面就有:HMACMD五、HMACSHA一、HMACSHA25六、HMACSHA38四、HMACSHA512 这五个内置类，都是调用里面的ComputeHash()。

固然，生产中的例子可能不像上面的那么简单，好比接口调用方要求必定附加一个时间戳参数在请求里，5分钟内本请求有效，my_secret_key 很是复杂，动态 my_secret_key 等等方式。

这个Postman固然支持：

这是我用网关kong内置的Hmac Auth 插件实现的。

总结：

大总结

我以为接口认证受权这块挺多东西，我如今用IdentityServer4+Hmac比较多，你们平时怎么处理的，也能够聊一聊~

参考

https://www.cnblogs.com/edisonchou/p/talk_about_what_is_jwt.html