**感谢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的，這些東西基本上就明白了
