安全 前后端分离,App 和 Web 端关于用户验证接口的一些疑惑

will7v · 2016年04月22日 · 最后由 billy 回复于 2016年04月22日 · 6643 次阅读

目前我们是前后端分离,关于用户鉴权部分的接口,web 和 app 想共用一套

web 端原来的方案:

  1. token 用 jwt 包一层,只是用了加密的功能,没有 jwt 的过期,关于 token 有效性和失效时间的管理是用存表判断来管理。前端把下发的 jwt 存在 cookie 里,每次 服务端读取 cookie 里的 token 鉴权。
  2. 尽量用了 RESTful 的规范,幂等的只读接口是用 GET,可能有副作用的用 POST。

现在 app 端开始做对接,app 同事认为 POST 比 GET 更安全(实际抓包的话都是暴露的),GET 请求的话他把 jwt 放在 url 的参数里,认为这样不安全,请问

  1. 前后端分离时各位是怎么设计用户验证这块接口的,有什么更好的方案吗?
  2. app 端除了把 token 放在 url 或者 request 的 header 里,还有什么更好的方案吗?
共收到 5 条回复

登录当然是 POST, 拿到 token。 其他的什么都行, 每一次请求 HEADER 里面都要放 token,后端验证。不要用 cookie, 因为不是什么客户端都方便做 cookie, 而且后端也不需要耦合客户端的实现,大家都按照 HTTP 规范来就好了。

之前项目就是 token 放 header,然后 https。

#1 楼 @billy 登录肯定是 post,我没说清楚,我指的是登录后,已拿到 token 再请求的时候,原来一些 get 请求,比如拉取用户当前关注人列表这种

#2 楼 @yue 嗯,我觉得也是这样,可以让 web 前端也放 header 来共用,或者判断 agent 区分 web 或者 app,对应用 cookie 或者 header

@will7v 拉取列表肯定还是 GET, 又不是要新增什么东西,毫无理由用 POST

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册