各位小伙伴们，提到系统的鉴权认证，大家应该都不陌生，比较常见的就是登录模块。输入账号、输入密码传到后台进行登录，认证通过就跳转主页，一般都是这个逻辑。
传统的模式是基于 session 的，登录之后后台接口会返回一个 session ID，然后前端将其保存在 cookie 里。访问页面时会带上 cookie 里的 session 到服务端去做校验，校验成功就允许访问，校验失败就拒绝访问，这是传统基于 session 的处理方案。我已经差不多有六七年没做相关校验了，用 session ID 一般也都是在单体架构里才会用。
随着系统的扩展，到了分布式系统下，整个服务会分割成很多小模块，又叫微服务，比如像用户中心、课程中心、商城中心、通知中心、物流中心等等好多模块。每一个模块可能都需要做鉴权，都要做认证，这太浪费了，而且也不现实。而且现在很多的认证需要同时支持账号密码、短信验证码、号码一键登录、微信登录，还要支持 app、h5、pc 端等很多类型终端的访问。所以呢，就迫切需要有一套统一的对外鉴权的认证中心。
session 的模式很明显不太适合，主要是基于 cookie 的，在 app 端不能用。而且服务端的存储同步也是个问题，因为涉及多个端，需要满足一个地方登录，然后所有地方都能同步使用，在整个服务端的存储方面也是个问题。
目前绝大部分的情况都是基于 token 的方式来对外提供鉴权和认证服务的。实现的原理其实很简单，用户登录时，通过短信验证码或者账号密码认证通过后，接口就会生成一个 token，其实就是字符串。然后服务端要把这个 token 存起来，一般会放在分布式缓存 redis 里面，有一定的有效期。有效期内，所有模块的鉴权访问都可以从 redis 里面获取到 token，如果存在就说明认证成功，如果不存在就说明已经失效，是非法请求。对于前端，需要把认证返回的 token 保存在本地，其他接口请求的时候带上这个 token，当然也可以塞到请求头里，效果都是一样的。基于 token 模式，一般也都是采用 springboot tool 的鉴权方案。
不管是哪种认证方式，比如账号密码、验证码、微信一键登录等，认证之后都会生成一个全局的 token。另外 token 的生成方式也有几种，比较常见的就是 JWT，也就是 JSON Web Token，里面存储了一大堆用户的基本信息并加密存储。好处是不需要再去查数据库，可以直接从 token 里面解析出用户信息。不好的地方就是这个字符串太长了，传来传去影响网络 io。我们一般用的其实都是采用 uid 来生成，然后存在 redis 里面做一些基础信息的存储。
好了，本期关于分布式系统鉴权认证的内容就到这里啦，如果您对本期内容有任何疑问，欢迎大家在评论区给我留言，谢谢大家！
