APP与web服务端接口Token验证上的一个疑问？

如果我通过抓包得到了api_token，user_token等等所有参数以及header，那在短时间内，我直接带上我获取到的参数，验证规则一样通过， 我不就可以用这个接口了？ 个人能想到的办法就是把token验证的时间弄短一点。 不知道大神们是怎么解决这个问题的？

回复内容：

token就是起这个作用的啊……不就是为了让你能用才设计的token么。设计token的主要目的是不希望长时间保存用户的用户名和密码，所以转换成一个随机码，这个码本身就有替代用户名和密码的作用，所以一旦泄露了，自然后果也会很严重。
现在安全级别高的API一般都只能使用HTTPS，这样从路径中间是抓不到连接上的内容的，所以不会把token泄露给其他人。至于两头， 一头本来就是用户，一头是你自己的服务器，这个token本来就是应该在两边共享的内容吧。
以前有另一种设计是使用api_key和secret_key两个值，其中api_key在HTTP当中明文传输，而secret_key不出现在HTTP明文中，而是作为MD5 Hash的一部分参与进来，一般将整个URL参数正规化（按参数名排序，统一转换成小写，正确进行URL编码），然后加上secret_key，计算MD5，然后把MD5作为一个附加的sig参数通过HTTP传递，这样即使中间抓到包，也只能看到api_key，看不到secret_key，就无法自由使用这个接口。但这个设计对于重放是有弱点的，虽然我不能自由地重新组合参数，但是我可以重新使用之前抓到的参数，这仍然是不安全的；而且，缺乏一个将secret_key安全分发到终端的手段。所以其实还是直接使用HTTPS比较有效。

作为参考我们来看一下OAuth 2.0的设计，OAuth 2.0是第三方登录，涉及到用户、认证中心、第三方应用三方面的关系，它遇到的问题就要更复杂一些，我们可以看它如何获取token，并且防止token被泄露给不应当泄露的一方：

1. OAuth服务器与第三方服务器同时知道相同的api_key, secret_key
2. 用户与第三方服务器同时知道api_key（通常是由第三方应用或者Web网页携带的）
3. 用户与OAuth服务器同时知道相同的用户名密码，第三方应用不知道
4. 用户申请第三方登录时，使用api_key调用OAuth服务器登录接口（一般由第三方应用引导），使用OAuth服务器的页面输入用户名密码，OAuth服务器返回auth_code，这可以看作一个临时的token。这一步必须使用https，保证用户名和密码不被窃取。
5. 用户使用auth_code调用第三方应用的接口（通常由callback机制自动完成），这一步可以使用HTTP，所以auth_code可能会泄露
6. 第三方应用使用auth_code + api_key + secret_key调用OAuth服务器的第二步登录接口，获取access_token，也就是正式的token。虽然auth_code可能泄露，但是由于secret_key攻击者无法获得，也就无法利用auth_code来换取token。这一步必须使用HTTPS，保证secret_key不泄露。

至此，第三方应用成功获取到了access_token，而这个access_token只在OAuth服务器和第三方服务器之间共享，不会泄露给包括用户在内的第三方。可见这个过程中主要是依赖HTTPS的加密特性来保证最重要数据（用户名、密码、secret_key）不被泄露。此外，不同安全级别的token应该有不同的超时时间，比如auth_code超时时间非常短，而access_token有相对长的超时时间。

接口用https， 抓包都是乱码。但是也有伪装中间人的方法？ 谢邀……
最极端的办法：
每个token只一次有效……

当然，这涉及到大量的读写操作。
SO……一般不这么搞…… 随机数加token加时间戳进行md5签名 把签名和随机数 时间戳一起传给服务器 不是这样子的，在服务器端先要判断session，通过之后才会进入到我们写的token验证中。 1:https；
2:认证模块独立，token入session，再次校验，这个和认证的设计有关系；
3:高频率更换token，具体看业务重要性；

以上个人看法，可能不太严谨