RESTful 接口如何保证客户端请求的用户唯一性

[ytwman]

我们接口开发遇到一个问题，是这样的。例如我们使用 oauth 2.0 的密码协议认证。用户登录后认证系统给一个有时效性的 token，然后客户端每次请求的时候带上这个 toekn 访问 restful 资源。但是遇到一个蛋疼的问题就是怎么保证用户请求的资源是合理的。

场景：
用户A要删除他的车辆信息。那么client 提交过来 用户主键和车辆主键，先判断当前车辆是否属于当前用户。若数据可以进行删除动作。 这时候如果他人拦截模拟登录，然后传递一个非当前用户的主键（胡乱编造的主键）然后主动探测的模式去匹配对应的主键，去恶意删除他人的用户信息。这样就会出现非常大的危害。例如：所有主键都是通过自增的方式生成的，这样恶意删除的几率就会大得多。

怎么样才能避免这种情况出现呢？之前也没设计过关于 restful 相关的内容，也没有这方面的经验。
有种本方法可以实现，就是 把 token 和 用户信息在后端绑定（有点像 session的形式），但是感觉这种又违背了restful 的原则。有没有好的解决方案，或者我理解上的问题？

[Madimo]

HTTPS，然后客户端本地存 token 的时候加密

[Septembers]

引入 悲观锁 概念？

[mhycy]

所有请求都有伪造的可能，所以所有用户隔离的操作，都必须在服务器有一层验证。
理想的方式应该是把数据鉴权操作封装到model供前端API调用。

所以总的来说你需要两样东西
1：能保证不被伪造的用户相关的TOKEN，以便确定用户。
2：利用这个用户的id进行操作鉴权，无论是操作上的还是数据上的。

[faceair]

token必须跟用户绑定啊 不然用户请求自有的资源你们是怎么搞定的？

[skydiver]

token用签名的方式计算，这样才可以防重放攻击。

token = hash (url + timestamp + secret + nonce)
发送请求的时候带上token,username,nonce，服务器验证token和timestamp

[ytwman]

@skydiver token 的生成方式，我们到不担心，目前使用的是 jwt 的模式生成。

[df4VW]

用UUID防干。

我没明白的是，操作之前还不是要验证ownership的么。比如用户只能删自己的帖子的话就算被hack了最差也是所有自己的帖子被删

[skydiver]

@ytwman 不担心你怕什么重放……换一个主键url就变了，token就失效了，为啥还怕人攻击

[otakustay]

传递用户主键干嘛，你应该根据token去确认当前用户，而不是信赖对方给你的主键

[cloudzhou]

@otakustay 这个做法才是对的，既然使用了 token，理所当然知道这个用户是谁，否则你们的设计太奇怪了吧。