1、单体应用下的常用方案
传统的单体应用,一般会写一个固定的认证和鉴权的包,里面包含很多的认证和鉴权的类,当用户请求时可以利用session的方式,把用户存入session并生成一个sessionid,之后返回客户端。客户端可以存在cookie里,从而在后续的请求中顺利通过验证。
![10c36496c40711c3ae6e08e617343827.png](https://i-blog.csdnimg.cn/blog_migrate/40ac56191e414305b8d8c1e77737152d.jpeg)
2、微服务下的SSO单点登陆方案
单点登录(Single Sign On),简称为 SSO,是目前比较流行的企业业务 整合的解决方案之一。SSO的定义是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统,如CAS(Central Authentication Service),是耶鲁大学开发的单点登录系统(SSO,single sign-on),应用广泛,具有独立于平台的,易于理解,支持代理功能。
但是针对微服务(服务之间调用):每个 服务都进行每个用户端 的sso动作,那么每个服务里都会做用户的认证和鉴权,可能保存每个用户的信息或者每个用户都会和鉴权服务打交道,这些情况都会带来非常大的网路开销和性能消耗,也有可能会造成数据的不一致,所以不建议用这种方案。
![812c7754d00c4d8e0fd9f75e51cd6239.png](https://i-blog.csdnimg.cn/blog_migrate/4b4f789d482855d91a77d0d3aea3b2bf.jpeg)
3.分布式Session与网关结合方案
spring cloud分布式Session方案的执行步骤
![4061522551b3876a8f34f166a5dee277.png](https://i-blog.csdnimg.cn/blog_migrate/ea18a857b0f38d6e6b5b990af3cd1ffd.jpeg)
1)用户在网关进行sso登陆 ,进行用户认证,检查用户是否存在和有效
2)如何用户通过,则将用户信息存储在第三方中间件中,如mysql、redis
3)后端可以从共享存储拿到用户的数据
很多 场景下,这种方案是推荐的,因为方便扩展,也 可以保证高可用的方案。但是这种方案的缺点是依赖于第三方中间件,且这些部件需要 做高可用,并且增加安全的控制,所有对于实现有一定的复杂度
4.客户端Token与 网关结合方案
![17da0456a2d858357d4c9b138ab7a6ed.png](https://i-blog.csdnimg.cn/blog_migrate/eb1a97c2295f00e2828636ab5c5acf8e.jpeg)
实现步骤
1)客户端持有一个token,通常可用jwt或者其它加密的算法实现自己的一种Token,然后通过token保存用户的信息
2)发起用户请求并携带token,token传到网关层后,网关 层进行认证和校验。
3)校验通过,携带token到后端服务中
4)如果涉及到用户的大量信息存放,token就有可能不太合适(或者用中间件来存放)
这种方案也是业界很常用的方案,但是对于 token来说,他的注销有一定的麻烦,需要在网关层进行Token的注销
5. 浏览器Cookie与网关结合方案
这种方式和上面的方式类似,但不同的是我们把用户的信息存放在cookie里,然后通过网关来解析cookie,从而 获取用户的相关信息,这种方式在一些老系统做改造时遇到的比较多,适合做为老系统改造时采取的方案,因为很多系统需要继承,这时cookie在别的系统中也是同样的适用。
6. 网关Token和 服务间鉴权结合
我们都知道网关适合做认证和鉴权,但是在安全层面,我们要求更严格的权限,对于有些项目来说,本身网络跟外部隔离,再加上其它的安全手段,所以我们只要求在网关上鉴权就可以了。
但是有些时候服务对 服务之间的调用进行鉴权,知道某个用户是否有权限调用某个接口,这些都需要进行鉴权。
这时的方案如下。
1)在gateway网关层做认证,通过用户校验后,传递用户信息到header中,后台做服务在收到header后进行解析,解析完后查看是否有调用此服务或者某个url的权限,然后完成鉴权
2)从服务内部发出的请求,在出去时进行拦截,把用户信息保存在header里,然后传出去,被调用方取到header后进行解析和鉴权
![23a40cde260334a249f595748506e459.png](https://i-blog.csdnimg.cn/blog_migrate/8b63e389f34f4d11d69c1e41202dd0d3.jpeg)