**感谢mcfog和yc8332的回答
按照mcfog的回答
如果sign的算法公开的话, sign不就没有校验功能了吗, 恶意攻击的人也可以根据该算法生成sign了**
刚读了一篇相关的博文, 有一点不明, 请大家解惑,谢谢
文中讲到sign是根据用户"请求的所有参数,包括timestamp还有token", 然后通过加密算法生成的sign.
然后他说在验证sign的时候是通过相同的加密规则生成一个sign, 看是否与请求的sign相同.
我的疑惑来了:
用户是怎么知道合法的sign是什么, 是在用户登录成功后, 和token一起返回给客户端的吗?
如果是的话这个token和sign在客户端和服务器端一般是怎么保存的, 是都存放在cookie中和session中?
每次请求的参数和时间戳一定是不同的, 怎么会能"根据用户请求的url参数, 重现出原来加密出的sign", 加密的原始素材只有token没变, 而其他的都变了, 怎么一样呢.
博文的原文如下:
"将所有用户请求的参数按照字母排序（包括timestamp，token），然后根据MD5加密（可以加点盐），全部大写，生成sign签名，这就是所说的url签名算法。然后登陆后每次调用用户信息时，带上sign，timestamp，token参数。"
"根据用户请求的url参数，服务器端按照同样的规则生成sign签名，对比签名看是否相等，相等则放行。（自然url签名也无法100%保证其安全，也可以通过公钥AES对数据和url加密，但这样如果无法确保公钥丢失，所以签名只是很大程度上保证安全）"
阿神2017-04-18 09:32:03
1, sign的算法是服务端公开的，里面的参数都是客户端知道的，客户端每次请求的时候自己计算sign
2, sign每次计算无需保存，token你给的上下文不足，没有说明是什么东西。可能是下面这两种东西
通称"secret" 服务端给客户端颁发的一个私密的字符串，客户端需要保护这个字符串不泄露，每次用这个字符串参与签名来验证客户端的合法身份。客户端一般是放在配置里，服务端一般有个数据库维护各个不同的客户端分别的secret值
通称"access token" 客户端通过登录接口请求拿到的类似session id的字符串，代表登录态
为了防止攻击者篡改／伪造请求，sign的要素中一般至少包含一种攻击者难以获取的要素，最常见的就是双方约定secret
为了防止重放攻击(replay-attack)，数据包中最好包含不重复的请求序号／毫秒级时间等类型的要素，服务器端作去重处理
3, 这个说的是服务端收到请求后的处理方法，通过收到的请求里的各种参数，用sign的算法来计算sign值，并和客户端提交的sign值比对，检查客户端是否计算正确。
建议：题主书看的太多做的太少，去对接几家实际的api接口，尤其是OAuth的，这些东西基本就明白了
