微服务网关统一鉴权（微服务网关权限控制）

本篇文章给大家谈谈微服务网关统一鉴权，以及微服务网关权限控制对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享微服务网关统一鉴权的知识，其中也会对微服务网关权限控制进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、微服务架构认证鉴权方案
• 2、微服务权限终极解决方案（spring-cloud-gateway-oauth2）
• 3、微服务方式实现双重网关
• 4、微服务的四种认证鉴权方式

微服务架构认证鉴权方案

微服务架构中推荐采用无状态 API 模式微服务网关统一鉴权，主要有两种方案比较普遍。其中 OAuth2.0 能够完全满足。此外 JWT 除了不能满足 SSOff(一次登出全部登出) 外微服务网关统一鉴权，其微服务网关统一鉴权他都能满足，且是所有方案里最为简便轻巧微服务网关统一鉴权的一个，可通过搭配 API 网关来满足 SSOff 特性的要求，因此 JWT + API 网关也是一个推荐的方案。

API 网关作为服务访问的统一入口，所有用户请求都会过 API 网关，很适合用来做认证鉴权这类切面型服务。网关可以拦截用户请求，获取请求中附带的用户身份信息，调用认证授权中心的服务，对请求者做身份认证，即确认当前访问者确实是其所声称的身份，检查该用户是否有访问该后台服务的权限。

目前主流的认证鉴权方案有 2 种。

第一种是引入 Redis 做分布式会话，即用户登录成功后，将用户身份、权限信息存入 Redis，以一个唯一 ID 作为 Key，并设置信息在 Redis 里的失效时间。这个唯一 ID 的 Key 将返回给客户端，客户端可以放入 Cookie，sessionStorage 等处做本地存储。下次访问的时候，将这个唯一 ID 放入请求参数中一起发送（一般放入 Header）。服务端通过检查 Redis 里有无这个 ID 来判断用户是否登录，获取用户身份和权限信息。客户端如果长时间没有操作，则存储在 Redis 里会话信息过期自动删除。客户端每访问一次服务端，需刷新一次会话信息的过期时间，避免固定过期时间带来的低用户体验。

第二种是 JWT，即 Java Web Token。用户登录成功后，服务端向客户端返回的唯一 ID 不再是无意义的字符串，而是包含了用户身份、权限、失效时间等信息的加密字符串。并且这个字符串包含数字签名，服务端可对这个字符串做数字签名验签，确保该字符串未经篡改和伪造。相比分布式会话方案，JWT 虽省去了 Redis 存储，但是每次访问都要做数字签名验证，增加了 CPU 的资源损耗。

微服务权限终极解决方案（spring-cloud-gateway-oauth2）

我们理想的微服务权限解决方案应该是这样的，认证服务负责认证，网关负责校验认证和鉴权，其他API服务负责处理自己的业务逻辑。安全相关的逻辑只存在于认证服务和网关服务中，其他服务只是单纯地提供服务而没有任何安全相关逻辑。

通过认证服务( oauth2-auth )进行统一认证，然后通过网关（ oauth2-gateway ）来统一校验认证和鉴权。采用Nacos作为注册中心，Gateway作为网关，使用nimbus-jose-jwtJWT库操作JWT令牌。

接下来搭建网关服务，它将作为Oauth2的资源服务、客户端服务使用，对访问微服务的请求进行统一的校验认证和鉴权操作

最后我们搭建一个API服务，它不会集成和实现任何安全相关逻辑，全靠网关来保护它

在此之前先启动我们的 Nacos 和 Redis 服务，然后依次启动 oauth2-auth 、 oauth2-gateway 及 oauth2-api 服务

我这里测试使用的 Docker 跑的单机版的 Nacos

github.com/it-wwh/spring-cloud-gateway-oauth2

微服务方式实现双重网关

最近在做一个多项目整合的工作，因为每个项目都有自己的一套网关，每个网关都有自己的加解密算法，整合到一起要求对外提供统一的用户鉴权，而且不对原有系统做大规模的重构，基于这些现实考虑使用两重API网关架构来构建新系统的统一网关体系。

备注：其中的统一网关、业务网关、业务微服务都是微服务的模式注册到微服务中心。

这个网关采用zuul来进行网关过滤及路由，其中过滤规则由各个业务网关以微服务方式提供，通过Feign来调用，这个方式也是区别于传统网关的，也是实现双重网关的关键所在。
这里要遵循的基本原则是：授权/鉴权一体化，即授权策略和鉴权方法都是由各个业务网关自己维护，这样就确保了功能的封闭性和一致性，在开发和后期维护中都非常的方便高效。

备注：这个类是zuul的主类实现了过滤/路由，其中的鉴权部分调用了相关的微服务，这些微服务以@Autowired的方式注入进来。
接口定义如下：

路由策略通过配置实现，因为是微服务所以直接指定路由到的微服务id即可，配置文件可以存储到微服务治理中心的配置中心。

备注：其中的user-base、user-org分别是两个业务微服务。

这个网关集群按照业务划分，每个网关实现了授权和鉴权的策略算法，并以微服务的方式提供，其中授权是对相关敏感信息做加密并以token的方式存储到cookie中，鉴权是将存储在客户端的token通过相应的解密算法进行核验和鉴权，确保该token的合法性、有效性，只有有效的token才能够通过鉴权并解析出敏感信息传递到指定的路由服务中。

备注：该网关使用JWT进行敏感数据加密

备注：该网关使用RSA进行敏感数据加密
H5业务网关以微服务方式提供了授权/鉴权服务，其中授权服务直接暴露给客户端，客户端调用后将业务类型app_type和授权token写入cookie，鉴权服务暴露给统一网关，对传递的token进行鉴权，鉴权成功后将token中的加密信息解析出来后返回给统一网关，由统一网关路由到业务微服务并将该参数传递下去。

备注：其中register、login是生成授权token流程，readUserinfo是通过token鉴权后访问业务微服务的流程。

微服务的四种认证鉴权方式

1. 单点登录（SSO）

这种方案意味着每个面向用户的服务都必须与认证服务交互微服务网关统一鉴权，这会产生大量非常琐碎的网络流量和重复的工作，当动辄数十个微应用时，这种方案的弊端会更加明显。
2. 分布式 Session 方案

分布式会话方案原理主要是将关于用户认证的信息存储在共享存储中，且通常由用户会话作为 key 来实现的简单分布式哈希映射。当用户访问微服务时，用户数据可以从共享存储中获取。在某些场景下，这种方案很不错，用户登录状态是不透明的。同时也是一个高可用且可扩展的解决方案。这种方案的缺点在于共享存储需要一定保护机制，因此需要通过安全链接来访问，这时解决方案的实现就通常具有相当高的复杂性微服务网关统一鉴权了。
3. 客户端 Token 方案

令牌在客户端生成，由身份验证服务进行签名，并且必须包含足够的信息，以便可以在所有微服务中建立用户身份。令牌会附加到每个请求上，为微服务提供用户身份验证，这种解决方案的安全性相对较好，但身份验证注销是一个大问题，缓解这种情况的方法可以使用短期令牌和频繁检查认证服务等。对于客户端令牌的编码方案，Borsos（David Borsos） 更喜欢使用 JSON Web Tokens（JWT），它足够简单且库支持程度也比较好。
4. 客户端 Token 与 API 网关结合

这个方案意味着所有请求都通过网关，从而有效地隐藏了微服务。 在请求时，网关将原始用户令牌转换为内部会话 ID 令牌。在这种情况下，注销就不是问题，因为网关可以在注销时撤销用户的令牌。 关于微服务网关统一鉴权和微服务网关权限控制的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 微服务网关统一鉴权的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于微服务网关权限控制、微服务网关统一鉴权的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。