最近有个老项目为了过三级等保需要修改一些登录的逻辑，对代码重新进行梳理修改完成后，对登录的业务流程进行重新梳理
用户在完成登录操作以后，系统需要下发标识记录一下用户的登录信息。在之前非前后端分离的项目中，登录标识都是存储在服务器的session中的。当前的会话只要是session中存在标识，那么后续的访问都可以在session中直接获取到登录信息。但是随着技术的迭代与业务场景的复杂化，很多项目都变成了前后端分离的形式。后端下发token给前端以后，前端根据token去请求合法的数据。
相比于之前的session的存储标识的简单方式，这种复杂的前后端分离项目我们作为后端工程师需要如何去设计呢？
首先需要考虑的是登录所需要的业务场景
- 登录成功下发token
- 退出登录清除&&失效掉token
- 超时无操作使token失效
- 有操作时候刷新token
- 同一个账号只允许单点或者多点登录
- 冻结/禁用账号时候，踢掉当前已登录的账号
- 。。。更多的实际情况
哈哈，我刚搞php的时候。只会扔个标识完事儿。现在做了一些项目了。开始搞这些业务的时候也了解这些业务可能会涉及到的场景，这些场景是需要在前期设计时候就设计好的，否则后期要修改可费劲了。
具体的场景分析
1 登录成功下发token
目前主流的基本都是 用jwt的方式去实现了。jwt提供了一套加解密的方案。把用户信息加密以后生成一个唯一标识，生成的token标识存储在redis中。
bash
composer require firebase/php-jwt2 退出登录清除&&失效掉token 登录下发的token是存储在redis中，只要用得到的token算出redis中存储的键干掉即可。
3 超时无操作使token失效 这个可以在存储redis数据时候设置好当前数据的过期时间。到期以后当前token就会失效掉。
4 有操作时候刷新token 这个是需要有正常访问的时候，重置掉redis中的那个过期时间。
5 同一个账号只允许单点或者多点登录 多点的情况不需要处理，但是假设是单点登录的情况。那么就需要记录下当前账号下发过的所有token。这就是令牌桶的一个概念。
6 冻结/禁用账号时候，踢掉当前已登录的账号 上面有了同一个账号所有的令牌的一个桶。踢掉的时候把当前账号所有的token全部干掉即可。
以上是对于登录逻辑的一些整理。