我们接口开发遇到一个问题，是这样的。例如我们使用 oauth 2.0 的密码协议认证。用户登录后认证系统给一个有时效性的 token，然后客户端每次请求的时候带上这个 toekn 访问 restful 资源。但是遇到一个蛋疼的问题就是怎么保证用户请求的资源是合理的。
场景：
用户a要删除他的车辆信息。那么client 提交过来 用户主键和车辆主键，先判断当前车辆是否属于当前用户，则数据可以进行删除动作。 这时候如果他人拦截模拟登录，然后传递一个非当前用户的主键（胡乱编造的主键）然后主动探测的模式去匹配对应的主键，去恶意删除他人的用户信息。这样就会出现非常大的危害。例如：所有主键都是通过自增的方式生成的，这样恶意删除的几率就会大得多。
怎么样才能避免这种情况出现呢？之前也没设计过关于 restful 相关的内容，也没有这方面的经验。
有种本方法可以实现，就是 把 token 和 用户信息在后端绑定（有点像 session的形式），但是感觉这种又违背了restful 的原则。有没有好的解决方案，或者我理解上的问题？
看你的问题，实际上是防止重复请求攻击（RepeatAttack）和内容被篡改。
参考下面链接S3的做法，发token的同时给每个token准备一个私钥也发给用户，client端的程序用私钥和URI和时间戳生成签名，每次请求除了表明身份的token之外还要有签名sign。你通过token拿到私钥，验证签名就行了。这样就防止了内容被篡改。
另一类的如果这个资源读取都很关键，别人只要拿到读取都很需要。那么就需要像S3那样再建立一个超时拒绝和超时时间段内重复请求拒绝。这样
参考：http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-r...
1，oauth 2.0 的token 只能用于你去访问授权方的RS，而不是你的资源，奇怪的是你为什么每次要带上那个token？
2，纯粹restfull是做不到，常用的解决办法是在request的header里增加sessionId。
3，你需要增加限制，一段时间（可以是session的过期时间）、ip内访问api的次数，来防止暴力获取sessionId
看看JSON Web Token，这里的token中是带有用户信息的，每次收到请求解码token得到用户ID，这样也就防止了client端的恶意篡改。
楼主我告诉你，他们都说的是错的。
正确的做法是在服务端增加逻辑，每一个车辆要有user_id。
对车辆做操作前，先验证这个用户的id是否等于user_id，如果不等于，说明这个车辆不是他的，直接拒绝。
这样就实现了每个人只能删除自己的车辆。
其他人之所以都是错的，是因为楼主的问题在于服务端设计缺陷。通过防止客户端篡改来防范是堵错路了。
可以将id不透明化，就是将id映射成uuid等不唯一且字符串安全的key。这样通过篡改的方式来碰撞数据库相同id可能性就很小，再限制这种大规模的攻击性请求。（以上都是本人在项目中使用的一种办法，之前遇到这个问题也没有找到很好的解决方案，楼主之后是否有更好的方案，可以分享）
HTTPS.
token + id + 签名
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是肯定的。问题是你的设计可以不用拦截，只要注册一个合法用户就可以在有缺陷的鉴权下跨权限访问资源了