权限认证SpringCloud GateWay、SpringSecurity、OAuth2.0、JWT一网打尽！

权限认证SpringCloud GateWay、SpringSecurity、OAuth2.0、JWT一网打尽

一、SpringCloud GateWay

1.它是如何工作的？

客户端向 Spring Cloud Gateway 发出请求。如果Gateway处理程序映射确定一个请求与路由相匹配，它将被发送到Gateway Web处理程序。这个处理程序通过一个特定于该请求的过滤器链来运行该请求。过滤器被虚线分割的原因是，过滤器可以在代理请求发送之前和之后运行逻辑。所有的 "pre" （前）过滤器逻辑都被执行。然后发出代理请求。在代理请求发出后，"post" （后）过滤器逻辑被运行

2.SpringCloudGateway主要有什么用？

路由转发：这是网关最主要的功能，通过配置统一将请求转发至相应的服务，否则客户端需多次请求不同的微服务，增加客户端代码或配置编写的复杂性，目前官网给出的配置条件有：After（某个时间后的请求转发至该服务）、Before（某个时间前的请求转发至该服务）、Between（某个时间范围的请求转发至该服务）、Cookie（匹配到对应的Cookie值）、Header（匹配到对应的Header值）、Host（匹配到对应的域名）、Method（匹配到对应的get/post请求）、Path（匹配到对应的url）、Query（匹配到对应的参数）、RemoteAddr（匹配到对应的RemoteAddr）、Weight（设定分流的权重）原文链接：https://blog.csdn.net/wen5026/article/details/122333171
熔断：可以通过配置FallbackHeaders GatewayFilter Factory进行熔断
限流：可以通过配置RequestRateLimiter GatewayFilter Factory对请求进行限流

鉴权：网关层可以进行统一鉴权，实现Global Filters完成全局的鉴权，实现Gateway Filter可完成单个路由的鉴权

@Component
@Slf4j
public class GatewayAuthFilter implements GlobalFilter, Ordered {//白名单private static List<String> whitelist = null;static {//加载白名单try (InputStream resourceAsStream = GatewayAuthFilter.class.getResourceAsStream("/security-whitelist.properties");) {Properties properties = new Properties();properties.load(resourceAsStream);Set<String> strings = properties.stringPropertyNames();whitelist= new ArrayList<>(strings);} catch (Exception e) {log.error("加载/security-whitelist.properties出错:{}",e.getMessage());e.printStackTrace();}}@Autowiredprivate TokenStore tokenStore;@Overridepublic Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {String requestUrl = exchange.getRequest().getPath().value();AntPathMatcher pathMatcher = new AntPathMatcher();//白名单放行for (String url : whitelist) {if (pathMatcher.match(url, requestUrl)) {return chain.filter(exchange);}}//检查token是否存在String token = getToken(exchange);if (StringUtils.isBlank(token)) {return buildReturnMono("没有认证",exchange);}//判断是否是有效的tokenOAuth2AccessToken oAuth2AccessToken;try {oAuth2AccessToken = tokenStore.readAccessToken(token);boolean expired = oAuth2AccessToken.isExpired();if (expired) {return buildReturnMono("认证令牌已过期",exchange);}return chain.filter(exchange);} catch (InvalidTokenException e) {log.info("认证令牌无效: {}", token);return buildReturnMono("认证令牌无效",exchange);}}

3.还有其他网关吗？

网关常用的还有Zuul、基于Nginx的OpenResty

4.和过滤器相比的区别：

过滤器：对单个服务器的请求进行拦截控制
网关：对所有的服务器的请求进行拦截控制

5.zuul和spring cloud gateway的对比

zuul：是Netflix的，是基于servlet实现的，阻塞式的api，不支持长连接。
gateway：是springcloud自己研制的微服务网关，是基于Spring5构建，能够实现响应式非阻塞式的Api，支持长连接

6.网关和nginx的区别

相同点：都是可以实现对api接口的拦截，负载均衡、反向代理、请求过滤等，可以实现和网关一样的效果。
- 不同点：
  - Nginx采用C语言编写，Gateway属于Java语言编写的，能够更好让我们使用java语言来实现对请求的处理。
  - Nginx 属于服务器端负载均衡器。
  - Gateway 属于本地负载均衡器。原文链接：https://blog.csdn.net/bufegar0/article/details/117355172
7.主要组成部分
- Route（路由）: 网关的基本构件。它由一个ID、一个目的地URI、一个谓词（Predicate）集合和一个过滤器（Filter）集合定义。如果集合谓词为真，则路由被匹配。
- Predicate（谓词）: 这是一个 Java 8 Function Predicate。输入类型是 Spring Framework ServerWebExchange。这让你可以在HTTP请求中的任何内容上进行匹配，比如header或查询参数。
- Filter（过滤器）: 这些是 GatewayFilter 的实例，已经用特定工厂构建。在这里，你可以在发送下游请求之前或之后修改请求和响应。

二、SpringSecurity

Spring Security是一个Java框架，用于保护应用程序的安全性。它提供了一套全面的安全解决方案，包括身份验证、授权、防止攻击等功能。Spring Security基于过滤器链的概念，可以轻松地集成到任何基于Spring的应用程序中。

1.认证

SecurityContextHolder

Spring Security 的认证模型的核心是 SecurityContextHolder。它包含了SecurityContext。

SecurityContext context = SecurityContextHolder.createEmptyContext(); 
Authentication authentication = new TestingAuthenticationToken("username", "password", "ROLE_USER"); 
context.setAuthentication(authentication);SecurityContextHolder.setContext(context);

AbstractAuthenticationProcessingFilter

2.授权

Authentication 讨论了所有 Authentication 实现如何存储 GrantedAuthority 对象的列表。这些对象代表已经授予委托人（principal）的权限。GrantedAuthority 对象由 AuthenticationManager 插入到 Authentication 对象中，随后由 AccessDecisionManager 实例在做出授权决定时读取。

GrantedAuthority 接口只有一个方法。

String getAuthority();

3.防止攻击

主要提供了对CSRF、HTTP Header、HTTP的保护

三、OAuth2.0

1.OAuth2设计的角色

资源所有者（Resource Owner） :通常是 用户（User） ，如昵称、头像这些资源的拥有者(用户只是将这些资源放到服务提供商的资源服务器中)。
第三方应用 ：或者称为第三方客户端(Clinet),希望使用资源服务器提供的资源
认证服务器(Authorization Server) :专门用于对资源所有者的身份进行认证，对要访问的资源进行授权、产生令牌的服务器。访问资源，需要通过认证服务器由资源所有者授权才可以访问。
资源服务器(Resource Server) :存储用户的资源，验证令牌有效性。比如：微信资源服务器存储了微信用户信息，淘宝资源服务器存储了淘宝的用户信息。
服务提供商(Service Provider) :认证服务和资源服务归属于一个机构，该机构就是服务提供商。

2.授权码模式

学成在线：

四、JWT

JSON Web Token（JWT）是一种使用JSON格式传递数据的网络令牌技术，它是一个开放的行业标准（RFC 7519），用于在通信双方传递json对象，传递的信息经过数字签名可以被验证和信任，它可以使用HMAC算法或使用RSA的公钥/私钥对来签名，防止内容篡改。

1.Header

头信息指定了该JWT使用的签名算法:

header = '{"alg":"HS256","typ":"JWT"}'

2.payload

消息体包含了JWT的意图：

payload = '{"loggedInAs":"admin","iat":1422779638}'//iat表示令牌生成的时间

3.signature

未签名的令牌由base64url编码的头信息和消息体拼接而成（使用"."分隔），签名则通过私有的key计算而成：

key = 'secretkey'  
unsignedToken = encodeBase64(header) + '.' + encodeBase64(payload)  
signature = HMAC-SHA256(key, unsignedToken)

最后在未签名的令牌尾部拼接上base64url编码的签名（同样使用"."分隔）就是JWT了：

token = encodeBase64(header) + '.' + encodeBase64(payload) + '.' + encodeBase64(signature) # token看起来像这样: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI

4.jwt和security的对比：

JWT的优点：

无需再服务端存储用户数据，减轻服务端压力
轻量级，json风格，比较简单
跨语言

JWT的缺点：

token一旦签发，无法修改
- 无法更新token有效期，用户登录状态刷新难以实现
- 无法销毁一个token，服务端不能对用户状态进行绝对控制
不包含权限控制

SpringSecurity：

优点：
- 用户信息保存再服务端，服务端可以对用户状态绝对控制
- 基于Spring，无缝整合，修改登录逻辑，其实就是添加过滤器
- 整合权限管理
缺点：
- 限定了语言
- 实现复杂，基于一连串的过滤器链
- 需要再服务端保存用户信息，增加服务端压力

五、RBAC

RBAC允许您通过分配一组权限来创建和实施高级访问。权限基于特定用户类别执行其职责所需的访问级别。换句话说，公司中的不同人员可以完全基于其工作职能和职责等因素拥有完全不同的访问权限级别和类型。

1.好处

RBAC最大的优点之一是它提供了一种系统化的方法，用于定义和维护角色，使您能够仅根据用户需要一致地授予访问权限，从而降低数据泄露或数据丢失的风险。

但RBAC还有很多其他好处，包括：

通过根据人力资源属性自动为新员工分配访问权限来加速入职
简化IT管理工作，例如，通过在全球范围内跨多个平台和应用程序快速重新分配权限
改善对欧盟《一般数据保护规则》（GDPR）或美国《健康保险可移植性和责任法案》（HIPAA）等法规的遵守
通过为供应商和业务合作伙伴等外部用户提供预定义的角色来降低第三方风险
通过在角色更改时自动更新访问权限来维护“最低权限”的最佳实践
降低高级访问控制的成本，尤其是在大型复杂环境中

2.缺陷

需要了解组织结构知识

没有一种一刀切的方法来定义角色。在决定如何对角色进行分类以及如何管理这些角色的访问权限时，组织必须跨部门协调。这需要清楚地了解组织的理想结构以及支持它的技术基础设施。

在大型或成长中的组织中，如果IT或安全经理需要在没有人力资源或执行决策者帮助的情况下定义角色，这可能是一项艰巨的任务，会变得更加困难。这种简化实施的常见尝试实际上使问题变得更糟，导致与公司更大的目标不一致。

需要深思熟虑的实施

分配角色可能是一项挑战。可能会出现很多问题，答案并不总是清晰的。例如：安全团队是否需要访问他们试图保护的数据，包含哪些访问权限（创建/读取/更新/删除）？是否应为用户分配部门之外的角色，以确保临时访问特权文件？

缺乏灵活性

RBAC以过于死板著称，这也难怪。组织成长，团队扩张，访问需求发生变化。在RBAC项目开始时定义的角色可能不再符合公司目标。

结果如何？人员的角色和权限级别可能不一致。例如，一个人可能被赋予过多的角色权限、分配过多的角色，或者两者兼而有之。虽然这些努力可能会起到快速修复的作用，但它们也会造成安全漏洞和法规遵从性挑战，从而打消了您最初实施RBAC的全部原因。

导致角色爆炸

一些团队试图通过定义越来越细粒度的角色、在出现新需求时创建临时角色，或将太多的角色分配给单个用户来回避上述问题。虽然这可能会在短期内缓解摩擦，但也会让RBAC变得混乱，难以管理。

这个问题通常被称为角色爆炸，是RBAC最常见的反对意见之一。当现实世界中的角色和访问需求与您的政策文件中概述的角色和访问需求不同时，甚至在很小的程度上也会出现这种情况。而作为临时解决方案创建的角色有时管理员可能会忘记或甚至故意选择保留这些角色，即使为其创建这些角色的人员离开或更换组织内的工作。结果是：特权蔓延和混乱。
AC的全部原因。