阿里、腾讯云 API 签名设计怎么都这么麻烦，还要转大写排序之类的步奏，为什么不设计成全部参数一起 base64 后签名，传 base64 和签名，一样能防篡改

[edis0n0]

[Chad0000]

我的更简单，整个 Raw Body 直接签名。

前提是 Post 一把梭。

[lhx2008]

不排序，同一个请求的签名没有唯一性

[edis0n0]

@lhx2008 #2 base64 一下就是唯一的了，防重放可以签名前 append 一个随机数

[neptuno]

防止大家不懂，乱写签名，然后上网提工单询问

[chenqh]

java 的 base64 和一般语言的 base64 不一样,好像会加换行

[nightwitch]

不是所有语言都有 base64 编解码的标准库，即使有，实现也会有差别。

[yin1999]

@edis0n0 base64 一下怎么保证唯一，签名算法要做得尽量通用，不论是用 js 、Java 、go 、Python 还是其它语言。不排序如何保证最终要处理的字符串是相同的

[gwy15]

这跟 base64 有啥关系……

[lovelylain]

整个签名后内容和签名分别放到哪里呢？再嵌套一层放到原内容地方的话，要解析两次参数，不会所有人认为这样更优雅吧。微信支付新的 api 是整个 body 签名，签名放 header 。

[eason1874]

楼主的意思是先 base64 再签名，那相当于给字符串签名，没有唯一性问题

但是这样做比排序的计算量大多了，体积也增加三分之一，浪费资源，我也不赞同

[rekulas]

base64 后签名自然是不行，不过题主提出的问题确实也存在，现在各大平台签名计算很麻烦，有 sdk 还好，没 sdk 还要自己封装，而且各个平台的签名并不完全统一，有些要求全小写，有些全大写，有些海外平台要求更复杂

其实以前签名很简单，直接提供一个 key ，把 key 传递过去即可，不过可能处于安全、隐私
防重放考虑，逐渐改为签名方式了，但是签名计算着实有点反人类

我有个想法，直接非对称鉴权，平台提供用户私钥自身保存公钥，用户直接使用私钥对请求参数、随机数、时间戳进行加密传递给平台，这样也不需要考虑签名问题了，非对称加密都是全语言统一的，在不担心泄露 key 的情况下完成了鉴权，也杜绝了重放攻击，实现也简单。在对接过的各个平台中似乎也有过类似方式的，但太久远已经忘了是谁了，毕竟不是主流

[vagusss]

如果接口用 post ，参数用 json ，直接对整个 json 字符串签名，这时候应该就不用排序了吧。

[yyf1234]

“base64 一下就是唯一的”，你能保证每个语言的 json 序列化后顺序一样吗

[leido]

兼容 aws

[unco020511]

你不排序咋保证参数列表生成的签名是唯一的,不唯一怎么在服务端校验?http 传递过程可能能确保你的参数顺序不变,但经过类似 retroft/spring 的框架转换之后可就不一定,所以当然需要先排序啊

[baobao1270]

Amazon 也是这样设计的啊
猜测一下：可能身份验证在边缘节点处理了，所以要尽可能降低对性能的需求