关于 REST authorization 授权设计的疑问

[lml12377]

假设现在需要保存登陆状态，按照最简便的 token 设计，先请求一个 resource 比如 POST /authorization 送过去账号密码，拿到 token 值（ github api 好像是 GET ？），下次请求需要登陆的资源就用 jwt 或者干脆 ?token=xxx 直接带过去。

但是有个问题，不是说 REST api 是无状态，不应该维持用户的登陆状态的吗？这里所说的无状态指的是不关联客户端的 cookie，还是说完全不关心用户是否登陆？

涉及到需要登陆的资源，感觉 REST 根本无法做到不涉及登陆状态，即使登陆模块独立出去，客户端请求 api 获取当前登陆用户的某个资源，跟登陆模块交涉的行为还是需要 api 拿到客户端的凭证之后自己来做（客户端自己交涉登陆模块拿到当前已登陆用户的 ID，再用这个 ID 去请求 api 拿到此登陆用户的资源，貌似完全不合理...）。

另外还有个问题，这个 “授权”，最终获得授权的 token 持有者身份究竟是 “客户端”，还是使用客户端的 “用户”？比如开发了 iOS app，那 token 描述的是 app 还是拿着手机登陆发帖的普通用户？

[jucelin]

可以参考 OAuth2.0 的。新浪微博里的文档：
http://open.weibo.com/wiki/%E6%8E%88%E6%9D%83%E6%9C%BA%E5%88%B6%E8%AF%B4%E6%98%8E

[baiyi]

> 在服务器组件之上不允许有会话状态(session state). 从客户发给服务器的每个请求中, 都必须包含理解请求所必需的全部信息, 不能利用任何保存在服务器上的上下文(context), 会话状态应全部保存在客户端

以上是 REST 论文中对于无状态这一约束的描述.

20 天前, 我以我对这段话的理解, 向 V 友们请教了《为什么 session 机制没有被 JWT 所取代?》. 因为在我看来 session 的机制毫无疑问的有利用在服务器上存储的上下文. 是不符合规范的. 而 JWT 的形式是全部保存在客户端, 而后服务器端每次验证, 是符合规范的.

token 的机制与 session 是没有区别的.

结论大概就是由于 JWT 不能存储过多的会话状态与一些需要安全保密存储的会话状态, 所以 JWT 并不能完全取代 session 机制, 只能是有些时候更加适用罢了

https://www.v2ex.com/t/381996

[whileFalse]

restful 无状态通常指不使用 session 等在服务端维护状态的机制。
客户端提交请求的时候还是要提交全部需要的参数的。
也就是说，每个索取用户私有信息的请求，客户端都需要提交 token。

所谓 token，就是和登录状态等价的信息。最糙的，用户名密码拼起来就可以作为 token。但对于公众使用的 app，在 app 内明文保存密码是不安全的。通常做法是使用用户名和密码登陆后，生成一个代表用户状态的随机字符串。

[hisway]

无状态指的是任意一个 Web 请求必须完全与其他请求隔离，当请求端提出请求时，请求本身包含了相应端为相应这一请求所需的全部信息。
获得授权的 token 持有者身份是 “用户”，客户端只是帮你转发下~

[lml12377]

@baiyi 已收藏～

[baiyi]

@lml12377 #5 希望能对你有所帮助