提供给第三方的API的签名验证问题

目前的状况

公司目前有若干的第三方API, 这些API是供第三方的一些渠道对接，让渠道可以访问到一些公司的业务信息，他们是这么设计的。

1. 使用Bear Token 作为第三方访问API的时候的唯一验证方式， 当第三方需要访问公司的API的时候，任何请求需要在请求头里面添加 Authorization：头信息， 用来提供Token给服务器 从而验证当前的请求是否有效。
2. 有一些操作我们想要回避第三方渠道， 如客户需要提交一些信息给服务器 第三方渠道不需要知道这些信息的时候， 我们会让访问第三方渠道的客户跳转到一个单独页面， 当然这个页面也需要有单独的token， 获取这个token的时候需要第三方渠道用带有 Authorization token的请求 去访问对应的生成token的API, 从而可以授权客户访问单独的页面和我方做交互
3. 这些token 作为第三方渠道是完全可以看得到的，也就是说第三方渠道是可以冒充任何客户来和我们公司做交互。 但是君子协议说他们不会这么做。 这样出现的任何客户单独和我们做交互的页面的信息的丢失 第三方渠道是不需要负责任的。
4. token并没有任何验证机制， 生成token 只是生成随机的固定长度的二进制数据， 然后转换为16进制， 然后做了一个有效时间验证保证token在6个小时内有效。没有任何的签名， 防重放攻击验证。

应该如何做签名验证

网上大概查了查 结合之前对接亚马逊 MWS接口的时候的经验，列一下一般的签名验证方法。

1. 任何和API做对接的第三方都需要进行注册步骤， 通过注册后API会给第三方生成一个clientID 和一个SecketKey。 clientID是公开的， 用来唯一表示一个第三方渠道， 而secretKey是保密的只有第三方渠道和API知道， 用来加密计算散列值。
2. API需要制定唯一的签名计算规则， 例如MWS使用Hmac, 使用key加密所有参数以一定固有规则排列好的 参数的散列值(包括clientID，以及时间戳, clientID可以确认是谁