这是一段防爬代码块，我不介意文章被爬取，但请注明出处
console.log("作者主页：https://www.cnblogs.com/w-blogg");
console.log("原文地址：https://www.cnblogs.com/w-blogg/p/18328093");
最近公司搞新项目，有个需求登陆，简单记录一下：
- app 端实现一个登陆系统，七天内如果操作过，则不需要登陆，否则重新登陆
- 需要保证密码不泄漏
- 可通过邮箱、密码登陆
- 换绑邮箱需要验证老邮箱，再验证新邮箱
- 支持登出
- 更换密码需要验证邮箱
- 暂时支持邮箱注册
鉴权方案
- cookie-session 方式，安卓端对于 cookie 支持并不是很好
- token 方式，其中 JWT 需要进行加解密操作，并且不支持登出，如果要做需要存储，本身 JWT 理念就是服务端不存储数据，这样就违背了理念，不是很想采用这种方式
- Oauth2.0，与第三方登陆有关，得看需求后续要不要接入，与要实现的内容并不耦合
综上，可以选择 token 方式，结合 1 进行一定的改造
具体方案
邮箱登陆、访问其他接口大致流程图
提供发送验证码接口
- 需要注意要做防刷逻辑
- 不同接口的类型验证码不可混用，发送后的验证码放入 redis 后，注意后续清除操作
提供验证验证码的接口
- 验证成功后颁发 email token，这个接口只能说明邮箱存在，并且本人操作，并不意味着邮箱对应着系统中的用户，用户是否存在需要在后续接口中做验证
- 注意需要清除 1 中生成的验证码
提供密码登陆接口
- 注意密码需要使用 RSA 公钥加密，避免泄漏密码比对通过后，生成随机 access token 和
- refresh token，access token 放入 redis 中，一小时自然过期，refresh token 存入数据库，有效期七天
网关
- access token、email token 的验证逻辑统一在中实现，验证通过后，把用户 id 放入 header 中，方便 controller 层和后续业务直接取
- 由于验证验证码的流程被剥离出来后，后续分步骤验证，换绑等操作得以实现，只需要更改网关验证流程即可
提供邮箱登陆接口
- 由于在网关中已经验证 email token 有效性，直接验证邮箱是否存在对应用户，颁发 token 即可
- 剩余逻辑与 3 一样
提供 token 刷新接口
- 由于 access token 是自然过期的，需要使用 refresh token 申请新 token，并且给 refresh token 续期到七天后
其他
- 请求需要使用 https 加密
- 密码使用私钥解密验证成功后，需要使用 BCrypt + salt 加密，以保证密码加密并且相同密码加密结果不一致。
- 使用 Redis 共享 session 解决后续扩展导致的共享问题
