微服务架构下的认证与授权

认证是指判断当前请求的用户是谁，授权指的是判断当前用户有什么样的权限。

在胖服务（Monolith）架构下，认证与授权都在服务的代码中，通常认证也可以用一些拦截器进行统一的实现。

每个服务自己实现认证#

但是在微服务架构下，如果每个服务还像胖服务一样自己实现认证，那么就会面临一些问题：

如果认证是有状态的（例如：Session 存储在数据库中或者缓存服务中），那么多个服务都需要访问认证数据的存储。

认证相关的代码需要在每个服务中实现（通过共享lib的方式可以缓解），如果逻辑发生变化，每个服务器都需要重新发布。

认证逻辑可以在认证服务中统一管理，但是每个服务都去调用认证服务，对认证服务要求较高，也会增加请求处理的时间。

在 API Gateway 中实现认证是比较理想的一种方式，因为每个请求都需要经过 API Gateway，这种方式比统一认证服务的方式调用链要短，不会增加请求处理时间。

有状态的认证通常是将 Session 数据存储在外部存储中，程序需要访问 Session 的存储才能进行认证。

无状态的认证是将认证信息存储在Token（通常是 JWT 格式）中，将Token下发到客户端，客户端每次访问时需要传递Token给服务器端，服务器端直接通过算法验证Token是否有效，无需访问外部存储。

个人认同在微服务架构下，无状态认证是更合适的方式。

在客户端存储 Session ID，在 API Gateway 处进行有状态的认证，将 Session ID 转换成 JWT，并将请求转发到后面的微服务中。

这种模式结合了有状态认证的优点（支持 Logout），通过 JWT 将用户基本信息传送给服务，可以减少服务对用户信息的请求。