postapi签名机制

1、如何使用apipost模拟手机实现请求发送

一、ApiPost中有专门针对于模拟手机请求发送的参数

首先我们新建一个接口，访问www.baidu.com然后点击发送

然后我们在创建一个接口，这个是访问移动版的www.baidu.com不过这里需要设置一下头部参数user-agent

在选择参数值，这里ApiPost自己给我了两个参数值

Android

版本：Mozilla/5.0 (Linux; U; Android 8.1.0; zh-cn;BLA-AL00 Build/HUAWEIBLA-AL00) Chrome/57.0.2987.132 Mobile Safari/537.36

iOS

版本：Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4)AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.113 Safari/537.36

这样就实现了移动端的接口测试了

二、设置User Agent的原因

Web端和移动端它们发送请求的时候请求是不一样的，如何才能更好的去完成移动端的接口测试，就需要去了解User Agent。现在很多网站都同时有web端和移动端，但是用web浏览器和移动端浏览打开它们展示的界面并不是一样的。不一样的原因是User Agent的不同。

User Agent

中文含义用户代理，简称为UA。它是一个特殊字符串头，使得服务器能够识别客户使用的操作系统及版本、CPU 类型、浏览器及版本、浏览器渲染引擎、浏览器语言、浏览器插件等

Web  端常用的User Agent：

1. Chrome  目前使用的User Agent：

MAC：Mozilla/5.0(Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko)Chrome/50.0.2661.102 Safari/537.36

Windows：Mozilla/5.0 (Windows; U; Windows NT 5.2)AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13

2. Firefox

目前使用的User Agent：

MAC：Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11;rv:49.0) Gecko/20100101 Firefox/49.0

Windows：Mozilla/5.0 (Windows; U; Windows NT 5.2)Gecko/2008070208 Firefox/3.0.1

                   Mozilla/5.0 (Windows; U; Windows NT 5.1) Gecko/20070309 Firefox/2.0.0.3

                   Mozilla/5.0 (Windows; U; Windows NT 5.1) Gecko/20070803 Firefox/1.5.0.12

移动端常用的User Agent：

1.   iPhone ：

Safari：

Mozilla/5.0 (iPhone; CPU iPhone OS10_1_1 like Mac OS X) AppleWebKit/602.2.14 (KHTML, like Gecko) Version/10.0Mobile/14B100 Safari/602.1

Mozilla/5.0 (iPhone; CPU iPhone OS5_1_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9B206Safari/7534.48.3

QQ浏览器：MQQBrowser/38 (iOS 4; U; CPU like Mac OS X; zh-cn)

UC浏览器：IUC(U;iOS 5.1.1;Zh-cn;320*480;)/UCWEB8.9.1.271/42/800

微信自带浏览器：Mozilla/5.0(iPhone; CPU iPhone OS 5_1 like Mac OS X) AppleWebKit/534.46 (KHTML, likeGecko) Mobile/9B176 MicroMessenger/4.3.2

2.   Android ：

自带浏览器：Mozilla/5.0(Linux; U; Android 4.0.3; zh-cn; M032 Build/IML74K) AppleWebKit/534.30 (KHTML,like Gecko) Version/4.0 Mobile Safari/534.30

QQ浏览器：Mozilla/5.0 (Linux; U; Android 4.0.3; zh-cn; M032Build/IML74K) AppleWebKit/533.1 (KHTML, like Gecko)Version/4.0 MQQBrowser/4.1Mobile Safari/533.1

UC浏览器：JUC (Linux; U; 2.3.7; zh-cn; MB200; 320*480)UCWEB7.9.3.103/139/999

微信自带浏览器：Mozilla/5.0 (Linux; U; Android2.3.6; zh-cn; GT-S5660 Build/GINGERBREAD) AppleWebKit/533.1 (KHTML, like Gecko)Version/4.0 Mobile Safari/533.1 MicroMessenger/4.5.255

2、API接口签名验证_MD5加密出现不同结果的解决方法

系统在提供接口给第三方系统使用时，通常为了安全性会做接口加密。
设计原则 ：使用HTTPS安全协议 或 传输内容使用非对称加密，这里采用后者。

在对参数进行加密，生成sign时，相同的参数两次加密的结果不一样。

加密规则：

1.拼接出来的字符串不一致
测试时，在加密前将要加密的字符串打印出来比较，发现两次字符串一致。

2.编码问题
加密时，两次的默认编码不一致。
在上述加上默认编码： byte[] btInput = content.getBytes("utf-8"); ，问题解决。

简单实现：
1.接口调用方和接口提供方约定好统一的参数加密算法。
2.接口调用方在调用时把加密后的signature放在参数中去请求接口。
3.判断时间戳有效期。
4.将参数用约定号的加密算法进行加密，与参数中的signature进行比较，一致则调用接口。

3、常见认证机制总结

阅读这篇文档你可以了解到一些常见的认证方式及其优缺点，在实际场景中该如何去搭配各种认证方式​。​

了解 Authorization 前，需要先了解以下术语

认证是对身份的一种确认过程；也可以说是身份有效性的确认；Are you who you say you are?

授权是指对行为或资源允许的过程；Are you allowed to do this action?
对应的是鉴权，是对行为或资源是否允许的确认过程

资源的拥有者，一般都是用户自己

资源的认证服务器，提供 Authorization Endpoint 及 Token endpoint

请求 authorization API

请求 access_token API

资源服务器，具体的 Service 上的 API

需要申请访问资源的应用，可以是 APP、JS APP、Server 等

Access token 是由 Authorization Server 通过安全认证后，生成临时用于访问 Resource 的凭证；
JWT 就是一种具体的实现方式.
可以标识身份；
也可以是 self-contain 认证权限信息；
一般有效期较短；
用于 Resource Server 的请求中

可以参考 JWT ，
有个使用中的小问题，记录下
Base64URL 与 Base64 算法
Base64 有三个字符+、/和=，在 URL 里面有特殊含义，所以要被替换掉：=被省略、+替换成-，/替换成_ 。这就是 Base64URL 算法。JWT 会使用 Base64URL 编码的，主要是考虑到一般 jwt Token 会直接被放在 URL 上。

Refresh token 是由 Authorization Server 通过安全认证后，生成用于长时间内获取 access_token 的凭证；
仅用于 Authorization Server 的请求中（不可传输给其他服务）；
若 access_token expire 了，则使用 Refresh token 去 Authorization Server 重新获取；
refresh token 可以管理 access token，防止 access_token 被多个 client 使用；

参考

参考

该方式在调用 API 前需要先在该 API Provider 那申请一个（对）API key，如 APPID 和 APPSecret，在请求的过程中在 query 或 header 中加上这个（对）API key；其中 APPSecret 一般都是在 Server-to-Server 的场景中使用，而 APPID 可通过终端 JS 传递到后端服务器，然后获取内存中的 APPSecret，一起放在 query 或 header 中转发到 API 服务；

图中因为仅考虑认证的机理。
优点：
这种认证模式的好处就是简单且能识别 API 调用者的身份；
有 APPSecret，所以一般都是在 Server-to-Server 的场景中使用；

该方式其实就是采用了 base64 对 username 及 password 进行混淆编码后放在 header 中，形如

该方式比较简单，但是如果在互联网传输，那么需要保证协议是 https 的，防止被拦截解码获取明文。

该方式是一种更高级别、更安全的授权方式，API provider 与 API caller 事先约定一个 Secret Key 及算法，然后保证只有双方知道，Caller 在调用 API 时，按照双方规定的算法对请求进行签名，得到 signature，并将该 signature 一并发到 Server 端，Server 端同理对请求进行签名，也得出一个 signature，然后对比两个 signature 是否 match，match 则认证通过，否则拒绝；

该方式重点就是在保存 Secret Key，所以一般 Web 或能直接查看到 JS 源码的场景都不适用；一般在 IOS、Android 等 Native 应用中使用场景较多；

优点：

OAuth2.0 主要是解决了在互联网上 Resource Owner 与 Client Application、third-parties 访问数据安全的问题。提供了一套安全的认证标准。

该认证方式是一种较安全的认证方式（虽然流程看起来复杂），其中主要是涉及到两个步骤一个是授权服务请求 authorization 过程，另一个是 Application client 请求 access_token 过程（这里有 CORS 问题，所以 Authorization Server CORS 必须是 allow 的），在网上找到以下图，完美使用了 Authorization Code 的认证方式；

解析

虽然目前 Authorization Code 的方式还是使用的比较多，但据 APP 开发童靴了解到，在 APP 端恶意的 APP 的确能拦截到 Authorization Endpoint 的响应，获取到 code，然后去获取 access_token 的问题。具体的问题可参考 IETF，感兴趣童鞋可搜索【IOS 逆向安全】相关话题。

下图是 Authorization Code 认证方式扩展后的认证方式即 PKCE，主要差异有两点：

该方式是一种 Authorization Code 的简化后的认证方式，它将交换 Authorization Code 请求直接简化（删除），Application Client 直接携带 client_id 去发起 request access_token 的请求，即省略了图中的 ⑥⑦ 步骤，直接跳到 ⑧ 返回 access_token。

【前世今生】
该方式最初是为了给 Native APP 和 JS APP 使用的，它所出现的原因是因为最初浏览器有 CORS 的困扰，POST 请求只能在同 domain 下访问 Authorization Server（见图中 ⑤ 输入账号密码后向自己的 AuthorizationServer 请求认证）而 ⑦ 步骤是 POST 请求且跨域，无法实现，所以省略了 ⑥⑦ 步骤，是一种妥协的方案；而如今 CORS 已不是什么问题，只要 Server 允许就可以访问，但现在已经推荐使用 PKCE 的方式去实现。
authorization 请求

其 response 仅仅是采用了 access_token

IETF 规定 Authorization Server 上 Authorization Endpoint 必须同时支持 POST 和 GET 请求，而 Token Endpoint 必须仅支持 POST 请求。

认证流程，如图

逻辑相对较简单，对于用户而言，基本没有授权可言（可能用户就不知道有后面这一步）。
2 中请求

认证流程，如图，该认证方式一般在安全可信且是 https 的 server-to-server 场景中使用

1 中请求

目前在国内大部分云厂商都是采用 AK/SK 的认证模式；一般都是先在云厂商平台注册应用，并生成一对 access key 和 access secret，然后对请求参数及其它按照云厂商提供的算法生成签名，签名与 access key 一起发送到服务器端，然后使用相同的算法生成签名，比较。这种方式相对其它的认证方式会更安全，一般使用场景是在 machine-to-machine（M2M），保证了 access secret 不会被泄露且不会在网络中传输，一般情况下生成签名的算法也都是不可逆的，所以即使被拦截也无法篡改数据；

大致描述了 AK/SK 的简单过程，signature 的算法也可以参考该地址
可以与 HMAC 进行对比下，可能会发现比较相似，可以认为是升级版。

最后推荐一个网站，需要设计 Authorization Portal 的可以参考一波。

https://aaronparecki.com/oauth-2-simplified/

https://tools.ietf.org/html/rfc7636#section-1.1 PKCE
https://www.ibm.com/support/knowledgecenter/zh/SSPREK_9.0.4/com.ibm.isam.doc/config/concept/oauth_pkce.html PKCE

https://oauth.net/2/ OAuth

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Access_control_CORS CORS

https://tools.ietf.org/html/rfc6749#page-21 Token Endpoint 及 Authorization Endpoint

https://support.huaweicloud.com/devg-apisign/api-sign-algorithm.html AK/SK

https://juejin.im/post/5c9ada58e51d453fea4a99bc

https://jwt.io/introduction/ JWT

https://tools.ietf.org/html/rfc7519 JWT

4、淘宝调用接口(API)时需要对请求参数进行签名验证。

根据参数的升序排序,连接起来,然后加上密钥进行MD5加密,产生SIgn用于数据安全校验,他们API那边也会以相同的方式加密,然后对比,一致的话,就通过,不一致的话,就拒绝访问.!

5、如何通过json把签名一起反馈

应用基于HTTP POST或HTTP GET请求发送Open API调用请求时，为了确保应用与百度REST服务器之间的安全通信，防止Secret Key盗用、数据篡改等恶意攻击行为，百度REST服务器使用了参数签名机制。应用在调用百度Open API之前，需要为其所有请求参数计算一个MD5签名，并追加到请求参数中，参数名为“sign”。百度REST服务器在接收到请求时会重新计算签名，并判断其值是否与应用传递过来的sign参数值一致，以此判定当前Open API调用请求是否是被第三者伪造或篡改。
应用在调用Open API之前需要通过 百度OAuth2.0服务获得用户或平台的授权，获取到授权后将会拿到以下3个重要参数：
access_token：基于https调用Open API时所需要的访问授权码；
session_key：基于http调用Open API时所需要的访问授权码；
session_secret：基于http调用Open API时计算参数签名用的签名密钥。
其中，session_secret这个参数就是做参数签名时所需要的签名密钥。这与Facebook、人人网等平台稍微有所区别，这两个平台在做参数签名时所用的签名密钥一般有2个：
如果是通过应用服务端调用Open API，则注册应用时所拿到的应用密钥（即API Key）就是参数签名密钥；
如果是通过JavaScript、ActionScript等客户端语言调用Open API，则应用获取到用户授权后所拿到的Session Secret就是参数签名密钥。当然，通过服务端调用Open API时也可以用Session Secret作为签名密钥。
签名算法
假设参与参数签名计算的请求参数分别是“k1”、“k2”、“k3”，它们的值分别是“v1”、“v2”、“v3”，则参数签名计算方法如下：
将请求参数格式化为“key=value”格式，即“k1=v1”、“k2=v2”、“k3=v3”；
将格式化好的参数键值对以字典序升序排列后，拼接在一起，即“k1=v1k2=v2k3=v3”；
在拼接好的字符串末尾追加上应用通过百度OAuth2.0协议获取Access Token时所获取到的session_secret参数值；
上述字符串的MD5值即为签名的值。
注意：计算签名时的请求参数中不要包含sign（签名）参数，因为sign参数的值此时还不知道，有待计算。
另外，计算签名的时候不需要对参数进行urlencode处理（“application/x-www-form-urlencoded”编码），但是发送请求的时候需要进行urlencode处理，这是很多开发者最容易犯错的地方。

转载请带上网址：http://www.pos-diy.com/posjitwo/111170.html