下图是公司的集成登录界面。
许多子系统的登录页面不再使用，所有登录都将进入统一登录页面，并在登录时选择您要登录的系统。 这里以我改造的安全管理系统为例。
在安全管理系统项目中添加集成的jar包实际上是截获所有请求，检查请求中是否有移动登录ID (该ID包括集成登录端生成的唯一ID )，否则在集成登录页面上返回
然后，在子系统的web.xml中放置并启用此阻止程序。
然后，每次从集成登录页面登录时，请选择子系统并输入用户名和密码。 用户名和密码在前台加密，同时携带的是集成登录端生成的唯一UUID，以及status字段和UUID。 (如果AuthoFilter拦截器位于（1）进入子系统上，并且没有理由检查请求是否携带，则集成登录端的一些参数和子系统(如果存在)将在本地初始情况下运行
进行许可，在集成登录端进行一系列认证(用户名、密码、PSID、子系统等)，最后进行（2-1）请求统一登录服务
再次进入子系统过滤器，进行验证，这次的代码不是null，所以获取http://www.Sina.com/Token，
根据服务器端子系统的唯一标识和username查找token，如果找不到则生成token，然后返回（2-2）跳到子系统
然后子系统得到token，执行下一个过滤器。 以下过滤器将再次去验证用户名和密码
注意：这次不是在集成登录端验证，而是在集成登录端上次保存的redis库中验证。 确认之后的系统操作正常进行。
这是部署认证中心。
认证中心是专门处理登录请求的独立Web服务。
用户在认证中心批量登录，登录成功后，认证中心会记录用户的登录状态，并将Token写入Cookie。 (请注意，此Cookie来自认证中心，APP应用程序系统无法访问。 ）
该APP应用程序将检查当前请求中是否有Token，如果没有，则表明用户尚未登录到当前系统，并将页面跳转到认证中心。 由于此操作会自动携带认证中心的cookie，因此认证中心可以根据cookie知道用户是否登录。 如果认证中心发现用户尚未登录，它将返回登录页面并等待用户登录。 如果发现用户已登录，则不重新让用户登录，而是跳转到目标URL，在跳转前生成Token，连接到目标URL之后，然后返回到目标APP应用程序系统。
系统获得Token后，必须向认证中心确认Token的合法性，防止用户伪造。 确认无误后，APP应用程序会记录用户的登录状态，将Token写入Cookie，并允许这次访问。 (请注意，此Cookie是当前的APP应用程序系统，其他APP应用程序系统无法访问。 )当用户再次访问当前的APP应用程序系统时，此Token会自动带来，APP应用程序系统会验证用户是否已登录，并且认证中心中没有任何内容。
这里介绍了两个认证中心的开源实现。
Apereo CAS是企业级的单点登录系统，CAS意味着“中央认证服务”。 最初是耶鲁大学研究所的项目，但转让给了JASIG组织，项目名称更改为JASIG CAS。 后来并入Apereo基金会，项目名称也改为Apereo CAS。
XXL-SSO是一个简单的单点登录系统，由大众点评工程师zxdyx个人开发，代码比较简单，没有安全控制，因此不建议直接应用于项目。 在这里列举作为参考。
总结：这种实现方式比较复杂，跨域支持、可扩展性好，是单点登录的标准做法。
通常是这样的步骤。
用户访问系统1的受保护资源，系统1发现用户未登录，跳转到sso认证中心，将其地址作为参数
sso认证中心发现用户没有登录，并引导用户进入登录页面
输入用户名密码提交登录申请
sso认证中心验证用户信息，创建用户与sso认证中心之间的会话(称为全局会话)，并创建授权令牌
sso认证中心拥有令牌跳跃会的第一个请求地址[系统1]
系统1获得令牌并前往sso认证中心检查令牌是否有效
sso认证中心检查令牌，使其生效并向系统1注册
系统1使用此令牌创建与用户的会话，称为本地会话，并返回受保护的资源
用户访问系统2中的受保护资源
系统2发现用户没有登录，跳转到sso认证中心，以自己的地址作为参数
sso认证中心发现用户已登录，然后跳到系统2的地址并附加令牌
系统2获得令牌并前往sso认证中心检查令牌是否有效
sso认证中心检查令牌，使其生效并向系统2注册
系统2使用此令牌创建与用户的本地会话并返回受保护的资源