web api 安全认证的方案（很严肃）

当你开发了你的网站的 api，就必须对 api 的调用者进行安全认证

现在普遍的方案是（https 是必须的）： 给你一个 app_id 和 secret_id

1. 用 app_id 和 secret_id 换取临牌 token，token 有时效性，一定时间再去换一个新的
2. 每个请求头都附带 app_id ,token 和 timestamps（时间戳）,nonce(随机数)，以及根据某个预设规则把这些东西加上请求内容（请求的内容可以加密）用签名算法(MD5,SHA1 或者 HMCA-MD5)搞成一个签名字符 signature，一起发送给服务端
3. 服务端根据 token 判断是否合法的请求身份，根据 signature 判断请求的有效性（包含时间有效性，是否被篡改），然后如果内容是加密的再进行一次解密

以上方案基本是现在微信，支付宝等的概要（如果那块说的很不对，求大家马上说明）
但我仔细想想还是有如下问题

• 第 1 步 直接传 app_id 和 secret_id 不安全，被截获了不就完了？ 我觉得 secret_id 永远不能直接传送，不过好像支付宝有安全的第一步认证，加密摘要什么的，反正微信是没有，就直接传，这个不是很不好吗？
• token 虽然有时效性，但是签名算法都是公开的，MD5，SHA1 大家都会，被截获了还是有机会短时间被盗用啊？ MHAC 是不错的，但是 HMAC 利用了 secret_id，那我就很好奇了为啥要去搞个 token？

带着第二疑问我看到了七牛的 API，七牛的 API 没有什么远程获取 token 的机制，每次的 token 都是自己生成的，七牛每次的请求需要有一个凭证：这个凭证的生成办法是，对请求的 url 或者内容用 secret_id 做 HMAC 算法，然后转生 base64，加上 app_id 形成最后的凭证

也就是说根本不需要服务器提供 token，因为 HMAC 算法需要一个密钥，用 HMCA 做摘要等于起到了两个目的，1 防止篡改 2 app_id 和 secret_id 的认证，因为错误的 secret_id 无法生成出这个 app_id 的凭证，这不就等同于用户名密码的校验了？

那个为什么还需要远程获取 token 这个动作？？ 个人认为这个东西有所多余了
请大家指正！！！