公开和私有混合的API有什么简单有效的验证用户方法？

现有一个resetful api，是给手机APP使用的，APP大多数内容是不需要登录即可浏览，但是也有一部分是注册用户登录后才能使用的，有什么办法能验证这个登录后的用户真实性，想过返回一个access_token(自定义的，非oauth方法)，但还是感觉会有冒用的风险。请教有什么办法验证这个用户的真实性而不是盗用access_token冒充的？

回复内容：

现有一个resetful api，是给手机APP使用的，APP大多数内容是不需要登录即可浏览，但是也有一部分是注册用户登录后才能使用的，有什么办法能验证这个登录后的用户真实性，想过返回一个access_token(自定义的，非oauth方法)，但还是感觉会有冒用的风险。请教有什么办法验证这个用户的真实性而不是盗用access_token冒充的？

这是一个典型的如何证明我是我的问题，没有绝对安全的方法，只能通过增加难度来提高安全性。方法有很多，你所说的令牌是其中一种常用方法，除此之外最简单最有效的就是使用https加密传输。其他的还有，比如重要操作每次都要求输入密码、以及动态密码等等。

上面是技术性的做法，还有一种安全手段是非技术性的，更多的属于社会学范畴（当然最终肯定都是要通过技术手段来实现的）。比如特征库。每个用户都有一组特征来标识，随着使用次数的增加，这种特征的收集会越来越详细，然后系统就可以用这些特征来验证使用者是否是本人。例如用户的常用登录地、手机设备特征、输入习惯、使用习惯、兴趣爱好等等。这些就像是一个人的指纹一样，很难伪造。不过这个东西实现起来并不是那么容易就是了。

安全性就是这样，矛和盾的关系，没有无坚不摧的矛，更没有绝对防御的盾。一切都要折衷，只要破解的成本大于破解后得到的利益，就可以认为系统是安全的。

resetful 无状态，就肯定有会有被冒用的可能性。

使用和客户端同一套加密方式产生token。
token不合法，直接拒绝。
验证通过，根据里面的信息，比如有个用户id=1，服务器解密后判断id=1用户是否登录即可。
如果客户端被反编译，算法被知道，用户还是要登录才行，因为登录信息在服务器。
理论上说，如果每次token都不一样，是不存在被抓包的可能性的，那样没意义。

私有API可以使用token来验证用户身份，再控制好用户的请求频度，避免API滥用。