头发掉得多了,总有机会接触/调到各种各样的接口,各种面向Api编程实际上已经嵌入到我们的习惯中,没办法现在服务端通信还得是http(s),其他协议还未能成为通用的。
大厂的开发平台api我先不敢说,各种小公司、或者不少大公司内部之间,各种各样的的接口签名/授权方式可以说是尽显劳动人民智慧、八仙过海,各显神通。当然,我也曾是八仙中一员大将;
然而,不能总当神仙,偶尔也要做下凡人。下面我们聊聊常见的服务授权方式;
Basic AuthBasic 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的我借龙哥个图来说明下
一般我们先定义一个颁发token服务(Auth Service --Api),服务调用方携带授权信息申请token;
Auth Service验证授权信息后返回jwt;
服务调用方携带jwt请求受保护接口;