Spring Cloud Alibaba 实战(十一) - Spring Cloud认证授权

欢迎关注全是干货的技术公众号:JavaEdge

本文主要内容:

如何实现用户认证与授权？

实现的三种方案,全部是通过画图的方式讲解.以及三种方案的对比

最后根据方案改造Gateway和扩展Feign

0 相关源码

1 有状态 vs 无状态

1.1 有状态

也可使用粘性会话，即:对相同IP的请求，NGINX总会转发到相同的Tomcat实例，这样就就无需图中的Session Store了。不过这种方式有很多缺点:比如用户断网重连，刷新页面，由于IP变了，NGINX会转发到其他Tomcat实例，而其他实例没有Session，于是就认为用户未登录。这让用户莫名其妙。

粘性会话不是本章重点，如果感兴趣可以百度一下(用得越来越少了)

1.2 无状态

这里讲的是解密Token直接拿到用户信息;事实上要看项目的具体实现;有时候Token里不一定带有用户信息;而是利用Token某个地方查询，才能获得用户信息。

1.3 对比小结

2 微服务认证方案

2.1 “处处安全”

代表实现

Spring Cloud Security : https://cloud. spring.io/spring-cloud-security/reference/html/
Jboss Keycloak : https://www.keycloak.org

示例代码

Spring Cloud Security认证授权示例代码
Keycloak认证授权示例代码(基于Servlet实现,无法和SpringCloudGateway整合)

优劣分析

安全性好
但是实现成本高,而且多次token交换和认证,所以有性能开销

2.2 外部无状态，内部有状态

架构过于复杂,微服务和传统架构混合双搭

2.3 网关认证授权，内部裸奔

登录成功后,网关颁发token,之后用户的每个请求都会携带该token,网关对其解密是否合法,过期等,token中会携带用户信息,所以网关还可解析token即可知道用户是谁,比如解析出了id和name,就会将其加入请求的header中进行转发,每个服务就知道是啥子用户啦!

优劣

优点是实现简单,性能佳,但是一旦网关的登录认证被攻破,就凉了

2.4 “内部裸奔”改进方案

请求经过网关到认证授权中心去登录,成功则颁发token,之后用户请求都会携带该token,但是网关不对token做操作
这样降低了网关的设计复杂度,网关不再关注用户是谁了(不再解密解析token),只负责转发
让系统也避免了裸奔的尴尬
但是要想解密token,还是需要密钥,现在每个微服务都要去做解密工作,意味着每个服务都知道密钥了.被泄露的风险随之增大,需要防止这种情况,可以定期更新密钥,想办法不让开发直接看到密钥本身(但是一般吧,除非有内部脑残人士才会泄露密钥,一般还是很安全的)