看你的问题，实际上是防止重复请求攻击（RepeatAttack）和内容被篡改。

参考下面链接S3的做法，发token的同时给每个token准备一个私钥也发给用户，client端的程序用私钥和URI和时间戳生成签名，每次请求除了表明身份的token之外还要有签名sign。你通过token拿到私钥，验证签名就行了。这样就防止了内容被篡改。

另一类的如果这个资源读取都很关键，别人只要拿到读取都很需要。那么就需要像S3那样再建立一个超时拒绝和超时时间段内重复请求拒绝。这样

参考： http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-r...

看看 JSON Web Token ，这里的token中是带有用户信息的，每次收到请求解码token得到用户ID，这样也就防止了client端的恶意篡改。

Authentication is the process of ascertaining that somebody really is who he claims to be.

Authorization refers to rules that determine who is allowed to do what.

http://stackoverflow.com/questions/6556522/authentication-versus-autho...

显然你只考虑了Authentication.

http://devcenter.kinvey.com/rest/guides/security

最简单的实现Authorization的方法是在表中加ACL字段定义来实现行级access control

对于防止拦截模拟登陆，https是肯定的。问题是你的设计可以不用拦截，只要注册一个合法用户就可以在有缺陷的鉴权下跨权限访问资源了

1，oauth 2.0 的token 只能用于你去访问授权方的RS，而不是你的资源，奇怪的是你为什么每次要带上那个token？

2，纯粹restfull是做不到，常用的解决办法是在request的header里增加sessionId。

3，你需要增加限制，一段时间（可以是session的过期时间）、ip内访问api的次数，来防止暴力获取sessionId

token + id + 签名

HTTPS .

楼主我告诉你，他们都说的是错的。
正确的做法是在服务端增加逻辑，每一个车辆要有user_id。
对车辆做操作前，先验证这个用户的id是否等于user_id，如果不等于，说明这个车辆不是他的，直接拒绝。

这样就实现了每个人只能删除自己的车辆。

其他人之所以都是错的，是因为楼主的问题在于服务端设计缺陷。通过防止客户端篡改来防范是堵错路了。