这是一段防爬代码块，我不介意文章被爬取，但请注明出处
console.log("作者主页：https://www.cnblogs.com/w-blogg");
console.log("原文地址：https://www.cnblogs.com/w-blogg/p/18328093");

最近公司搞新项目，有个需求登陆，简单记录一下：

1. app 端实现一个登陆系统，七天内如果操作过，则不需要登陆，否则重新登陆
2. 需要保证密码不泄漏
3. 可通过邮箱、密码登陆
4. 换绑邮箱需要验证老邮箱，再验证新邮箱
5. 支持登出
6. 更换密码需要验证邮箱
7. 暂时支持邮箱注册

鉴权方案

1. cookie-session 方式，安卓端对于 cookie 支持并不是很好
2. token 方式，其中 JWT 需要进行加解密操作，并且不支持登出，如果要做需要存储，本身 JWT 理念就是服务端不存储数据，这样就违背了理念，不是很想采用这种方式
3. Oauth2.0，与第三方登陆有关，得看需求后续要不要接入，与要实现的内容并不耦合

综上，可以选择 token 方式，结合 1 进行一定的改造

具体方案

邮箱登陆、访问其他接口大致流程图

提供发送验证码接口

1. 需要注意要做防刷逻辑
2. 不同接口的类型验证码不可混用，发送后的验证码放入 redis 后，注意后续清除操作

提供验证验证码的接口

1. 验证成功后颁发 email token，这个接口只能说明邮箱存在，并且本人操作，并不意味着邮箱对应着系统中的用户，用户是否存在需要在后续接口中做验证
2. 注意需要清除 1 中生成的验证码

提供密码登陆接口

1. 注意密码需要使用 RSA 公钥加密，避免泄漏密码比对通过后，生成随机 access token 和
2. refresh token，access token 放入 redis 中，一小时自然过期，refresh token 存入数据库，有效期七天

网关

1. access token、email token 的验证逻辑统一在中实现，验证通过后，把用户 id 放入 header 中，方便 controller 层和后续业务直接取
2. 由于验证验证码的流程被剥离出来后，后续分步骤验证，换绑等操作得以实现，只需要更改网关验证流程即可

提供邮箱登陆接口

1. 由于在网关中已经验证 email token 有效性，直接验证邮箱是否存在对应用户，颁发 token 即可
2. 剩余逻辑与 3 一样

提供 token 刷新接口

1. 由于 access token 是自然过期的，需要使用 refresh token 申请新 token，并且给 refresh token 续期到七天后

其他

1. 请求需要使用 https 加密
2. 密码使用私钥解密验证成功后，需要使用 BCrypt + salt 加密，以保证密码加密并且相同密码加密结果不一致。
3. 使用 Redis 共享 session 解决后续扩展导致的共享问题