到目前为止已经实现了一个基于session的SSO
优点:
1,安全 。所有的token的信息都是放在session里(客户端应用session、认证服务器session),在浏览器里只有一个jsessionId,在浏览器这边只要做好session固定攻击的防护,一般是不会有什么风险的。
2,可控性高。token信息存在了数据库,登录信息存在了redis,想让谁下线就让谁下线,想让谁失效就让谁失效。
3,跨域。客户端应用部署在哪个域名下,都可以直接跟认证服务器交互。
缺点:
1,复杂度高。 session和token机制混合使用,session又分为客户端服务器和认证服务器两种,各自有各自的过期时间,access_token和refresh_token 又都有各自的过期时间。你必须非常清楚每个东西是干嘛的,过期后对系统会产生什么影响,系统的行为是什么,你要怎么处理,都要心里很清楚,才能用好这种方案。
2,性能低。session、token的存取占用服务器资源,当用户量大的时候会有各种问题。比如当用户上亿的时候用这种方案是不可行的。
适用场景:
1,适用于百万以下用户。token表最多一百来万数据,这个性能是可以保证的,也不会占用服务器太多资源,也不用考虑分库分表、读写分离。
2,内部的管理系统。每一个客户端应用都是一个XX中心,如用户中心,订单中心,商品中心等,每一个中心都是可以单独部署的,他们都用同一个页面风格,各个系统可以跳来跳去,后边是一个统一的认证服务器,网关来访问微服务。用户看来是一个系统,适合于一定规模的内部管理系统。
原文地址:https://www.cnblogs.com/lihaoyang/p/12169298.html
时间: 2024-11-05 09:28:32