这是一个创建于 2045 天前的主题，其中的信息可能已经有所发展或是发生改变。
制作了一个流程图，如下：
大佬们请帮忙指点一二，不胜感激！
 |
1
fy 2018-09-12 10:36:18 +08:00
稍微有一点经验，记得考虑多设备的记录（此时多个 token ）
|
 |
3
qwx 2018-09-12 12:58:13 +08:00
更新过期时间这事是不是放在前端好一点，手动 refresh。
|
 |
4
swcat 2018-09-12 13:51:12 +08:00 via Android
jwt
|
 |
5
superbiger 2018-09-12 14:41:02 +08:00
登录是登录 授权是授权 显示是显示
sso、oauth、菜单控制 三个概念搞清楚了，各有各的难点和要解决的问题的 |
 |
6
thisisgpy 2018-09-12 18:51:28 +08:00
为什么每次请求接口都要返回新的 Token ？这个方案不能解决前后端分离情况下，单点登录跨顶级域的所有具备前端页面的前后端分离的业务系统的能力。
|
 |
7
libook 2018-09-13 00:25:48 +08:00
既然 Token 内已经存了过期时间，就完全可以把 Redis 干掉，验证 Token 是否过期只需要解密 Token 比对过期时间就好了，这样对于分布式系统比较有利，鉴权阶段完全不依赖于数据库。除非需要做多端登录互踢，那样的话 Token 里要纪录一个 UUID，Redis 里纪录有效的 UUID，每次验证 Token 的时候去 Redis 里看一下是否 UUID 还在，一旦需要踢掉用户的登录状态，只需要在 Redis 里删掉这个 UUID 就可以了。
|
 |
9
agoodob 2018-09-13 13:38:16 +08:00
JSON Web Token ？
|
 |
10
GTim 2018-09-14 09:05:59 +08:00  1
@libook 赞同，Token 应该自带用户属性、时间属性和 checksums。这样，无论哪里打开都可以自动校验而不依赖于具体的环境
|
|
11
libook 2018-09-14 10:31:09 +08:00 1
@qwx 如果是整个丢到 Redis 里就失去了 Token 的价值了，那样的话没必要用 Token，随机生成一串字符串完全就能满足要求。
Token 的价值在于内部可以加密储存信息，那你可以想想，在用户会话验证阶段都需要哪些信息，如用户 ID、角色、权限、会话过期时间等等，把这些信息加密生成的密文就是 Token，当用户发送请求的时候携带 Token，你的服务器就可以不依赖数据库及其他资源，直接解密 Token 取出里面的数据就可以完成用户会话验证。 这种 API 设计叫做“无状态 API （ Stateless API ）”，这是个 REST API 设计风格的核心思想，有了这种设计后系统就会变得很简单，不需要考虑用户上一个请求是什么，也无需考虑用户是否把请求发给过集群里的其他服务器，每一台服务器的每一个线程都可以独立完成请求的处理。因为能够独立处理请求，所以不存在因为某一层是单节点处理而造成的性能瓶颈，你的服务就可以无限横向扩展，集群里加几倍的服务器就能有几倍的算力。 |
|
12
qwx 2018-09-14 15:05:33 +08:00
@libook 用法我理解，我也会把用户的部分信息放到 token 里面，我只是觉得存整个 token 到 redis 里或者把 token 中的某个不重复 id 存在 redis 里差不多而已，反正 token 也不长，对吧。要做的事情就是为了禁止重复登陆，这个用户在其他地方登陆了我就更新最新 token，要完成这个事情肯定需要把 token 或 token 的一部分存入 redis。。。好吧，其实就是我不想在 token 里加字段，就是懒（狗头）
|
 |
13
yuanfnadi 2018-09-14 23:55:10 +08:00 via iPhone
如果不需要让 token 失效。完全可以只用 jwt
|
 |
14
artandlol 2018-09-15 20:50:36 +08:00 via iPhone
Kong
|
 |
15
ivydom 2019-10-10 16:47:54 +08:00
用 authing，authing 自带登录表单和各种用户管理代码，可以让开发者使用五六行代码实现认证（使用 jwt token ）
|
|
16
ivydom 2019-10-10 16:48:31 +08:00
authing 自带登录表单和各种用户管理代码，可以让开发者使用五六行代码实现认证（使用 jwt token ）
|
Select Language