服务端一般怎么处理 token？

[AscenZ]

之前一直在写 iOS ，前后端分离，每次请求带上 token 就行了。

现在想写一下后端，想问一下一般是怎么处理 token 的？

用户登录的时候根据 userID 加上时间戳 或者 加上一个自定义值 用加密算法生成 token 之后，

1.存到数据库中（能设置过期时间吗？），每次客户端请求的时候取出来验证

2.存到 redis 中，设置过期时间，每次客户端请求的时候取出来验证

3.不存，每次客户端请求的时候根据之前的生成方法再生成一次来验证

哪种方法成本更低？ 或者有更好的方法吗？

[jarlyyn]

@sampeng

Session 一般（除了 cookie based session ）就是基于 token 的一种具体实现啊。

不就是把 token 存在对应的 cookie 里么……

[kulove]

aes 加密用户 id ，过期时间 每次请求解密判断是否过期

[phx13ye]

如果 jwt 也要存，不就变成 session 了么,后续又会遇到一对分布式 session 要处理的问题，这样好处在哪？求详细说明

[avichen]

@phx13ye #23 jwt 在 local 本地存储，每次请求带过去，让 server 校验，不会存在分布式的问题

[phx13ye]

@avichen 想把 JWT 作为 app 端和网页端登录凭证。那么 logout 的时候，一般也只是客户端删掉 JWT 吗？

假如在 payload 里设置过期时间 60 秒，如何防止在 59 秒还可以成功请求， 61 秒就要求用户重新登录的情况呢？ JWT 有自带的机制去处理吗

[vjnjc]

1 ， 2 看起来一样。 1 的话存的时候带过期时间呀。
3 的话看起来不安全，通过逻辑生成总是有漏洞（/规律）

[avichen]

@phx13ye #25 logout 时可以采用你说的删除 token ，另外 59 秒的问题，貌似没有解决办法，这一秒请求完了，下一秒再请求，它不就过期了嘛，对你的业务影响会很大吗？

[behappy]

@jarlyyn
请教一个问题，假如我先打开网页 A ，这时候服务器在努力运算生成 token,但是出于某种原因卡住了。然后我又开了个新标签仍然打开网页 A, 然而这次服务端生成 token 后很快就返回了然后写入 cookie 成功了。然后前一次的 token 慢悠悠的返回了，把第二次的 token 覆盖掉了。这种情况该咋整

[Ouyangan]

@behappy jwt 的话没有影响 , token 合法就成了 , 因为服务器根本就没存 token.

[jarlyyn]

@behappy

你的 token 是存在 cookie 的吗？

这是标准的 session 啊。

应该是最后一个 token 生效。

[CareiOS]

@sfwn 就是服务器用对称加密，将数据加密得到一个 string ，然后返回给 client, 每次 client 请求都带上这个 string, 服务器收到后解密，判断是否过期等....

[asen477]

一般 app 端存 token 不会做短期的时间验证
一般存在本地都会很长时间。

[behappy]

@jarlyyn 好的

[chuanwu]

@phx13ye 对于这种场景， jwt 确实没有好的方式解决，这时候可以依赖服务端来做啊。

[phx13ye]

@avichen 想知道有没有最佳实践

[phx13ye]

@chuanwu 嗯，之前的做法是在记录一下心跳时间，导致服务端要记录。也许可以在快要过期时重新分配一个 token 更好

[yankbytes]

@behappy 再去拿个 token ？一般来说除了 accesstoken 还会有 refreshtoken

[sutra]

spring-session