多维系统下单点登录之整理解决方案

从淘宝天猫的单点登录说起

1.1 SSO单点登录

• 概述 随着互联网大数据不断发展，应用服务的不断增多，单点登录越来越能够凸显其作用。单点 登录SSO(Single Sign On)，顾名思义就是单个节点登录，全局使用。是目前最为流行的统一登录 解决方案。
• 为什么使用? 目的就是为了快速实现用户认证，统一管理用户信息， 避免重复维护用户数据; 分离用户与业务数 据，让业务服务专注于业务功能的实现，让用户中心服务统一认证，减少频繁认证次数， 同时保 障数据的安全性。
• 应用场景
• 内部的服务统一认证与授权，比如电商网站， 内部的用户服务、订单服务、库存服务、资金 服务等，以用户服务作为认证服务中心，实现统一认证与授权。
• 外部的第三方登录认证与授权，比如登录某个论坛网站, 可以采用FaceBook或者Google账号进行登录。
• 云服务应用，比如使用阿里云的消息推送服务，但不想创建和管理用户，就可以采用基于 SAML协议实现SSO单点登录。

1.2 淘宝天猫登录场景解析

访问淘宝网站， 登录之后， 再访问天猫网站， 你会发现， 天猫也是处于登录状态，那么具体是如何实现的？

• 登录技术方案分析 淘宝登录

• 天猫登录

• 目前整个登录体系是以淘宝作为中心，天猫通过淘宝作鉴权登录。整个鉴权体系是采用跨域cookie + 分布式session作为解决方案:
• 淘宝是如何解决Cookie跨域问题

目前淘宝是采用如下方案做处理: 通过内嵌iframe，访问统一域名，实现Cookie信息共享，如果禁用Cookie，你会发现无法正常登录；同时利用静态资源不受同源策略的限制，通过JSONP跨域方式来获取用户的登录状态。

Response会返回Token信息:

var userCookie= 
{dnk:'',_nk_:'',_l_g_:'',ck1:'',tracknick:'',mt:'ci=0_0',l:'eBMMyMa4QmFJBq7p 
BO5aourza77T3Idb4sPzaNbMiInca6BPO3JuhNQqw5H95dtjgtC3xetzm21B9dLHR3fRwxDDBTJb 
WMu- 
exvO.',uc1:'',t:'aa749f01717bd2e29ccacc35701ebef7',unb:'',cna:'y4PeFr/mbEoCA 
XQZX0Z2u8bq',_tb_token_:'e6163b18b5154',version:'4.0.0'};window.TB && 
TB.Global && TB.Global.run && TB.Global.run();

12345678

淘宝是如何解决分布式Session管理问题呢? 为了解决此问题，淘宝专门推出两个重要产品：第一个是tbsession, 基于Tair缓存体系实现的共享Session；另一个是passcookie，解决不同域名之间Cookie同步的问题，上述的登录鉴权Cookie信息就是通过passcookie实现的统一管理。淘宝是如何防范Session劫持?CSRF/XSRF 攻击的原理，就是利用浏览器对嵌入资源不做限制的行为进行跨站请求伪造攻击， 比 如<script> 等标签。

淘宝是生成一个随机的Token给客户端，然后提交时在服务端进行校验， 由于Token是不断变化，并且具有私密性，只内嵌到当前的用户页面中， 这样就可以防止CSRF的攻击，保护资源。

• SSO登录架构设计

• SSO登录实现流程解析

1. 用户进入淘宝登录页面，调用地址: https://login.taobao.com/newlogin/login.do
2. 调用成功之后，同步Cookie，保存Token认证信息。

1. 访问天猫网站，从Cookie里面拿取Token信息，采用jsonp方式，获取淘宝的登录状态：

1. 如果不是从淘宝登录, 由天猫发起登录，会请求至淘宝登录页面， 登录完成之后写入Cookie信息， 再返回至天猫网站。

2. 单点登录之整体解决方案

2.1 设计方案-Cookie

• 概述用户登录之后, 将认证信息存储至Cookie，当再次访问本服务或者访问其他应用服务时，直接从Cookie中传递认证信息，进行鉴权处理。
• 问题
• 如何保障Cookie内用户认证信息的安全性? 第一, Cookie内不能存放用户名和密码等敏感信息, 可以生成一串Token进行替代; 第二, 通过加密方式存储Cookie信息，并且采用https加密方式传输，设定Cookie有效期，在服务端设定Token的有效期，避免攻击者伪造用户身份。
• 如何解决跨域问题? 在实际应用中， 经常会存在各种服务需要鉴权处理， 但受浏览器同源策略限制，无法去正常操作Cookie数据, 解决方式有两种: 第一种，采用iframe方式解决跨域问题, 实现Cookie共享，但要注意，父窗口获取子窗口在跨域下可以正常获取，子窗口后去父窗口仍会存在跨域问题， 这点在实现的时候要注意。第二种，采用JSONP方式实现跨域传输，这需要在服务端设置允许跨域请求，response.setHeader(“Access-Control-Allow-Origin”, “*”); 设置允许任何域名跨域访问，服务端返回数据时，再设置callback，才能完成跨域请求。
• 跨域Cookie设计实现方案

image-20240825221924134

2.2 设计方案-分布式Session

• 概述大型应用服务无论是整体拆分，还是集群部署，都会涉及到统一会话问题，如何保障各服务节点都能够统一有效鉴权？某个服务节点宕机，重启后如何恢复登录状态? 在Cookie禁用的情况下如何实现SSO? 由此产生了分布式Session设计方案。分布式Session方案，实质是通过自定义的Session机制来处理用户的登录鉴权信息，实现单点登录。
• 实现流程

• 技术框架Spring Session : 它是目前主流的Session 管理解决方案，Spring Session 并非特定应用于HTTP， 它是一种广义的分布式统一Session，支持WebSocket和WebSession等，并且可以基于Redis、MongoDB等多种高性能缓存来实现。XXL-SSO: 它是一个分布式单点登录框架。只需要登录一次就可以访问所有相互信任的应用系统。拥有”轻量级、分布式、跨域、Cookie+Token均支持、Web+APP均支持”等特性。现已开放源代码，开箱即用。架构图:

2.3 设计方案-客户端令牌Token

• 概述根据客户端身份信息由认证服务生成签名令牌，令牌中会包含基本的用户信息，客户端在请求资源服务时会附带令牌，资源服务根据加密协议在本地进行验证， 或者发送给认证服务端进行校验。它可以解决分布式会话的安全性问题，比如会话劫持，同时不需要集中统一维护session，能够做到无状态化处理。OAuth2和JWT都是基于令牌Token实现的认证方案。
• 适用场景JWT (JSON Web Token) 是一个开放安全的行业标准,用于多个系统之间传递安全可靠的信息。它由三部分组成，头部(Header)、载荷(playload)与签名(Signature)。Token实质是一个无意义的UUID，需要服务端做记录与认证， 但JWT则赋予了用户的身份信息，可以采用自定义算法进行加密与解密，直接实现信息的传输交换。那具体适用于哪些场景?
• 可以适用于微服务应用， 无论是内部服务节点的认证与授权， 或是令牌与API网关结合的认证。
• 可以适用于开放式的API接口访问，比如前后分离API对接，第三方API接口对接等。
• 实现流程

2.4 技术方案-CAS认证

• 概述CAS（Central Authentication Service）是耶鲁大学的开源项目，宗旨是为web应用系统提供一种可靠的单点登录解决方案。CAS从安全性角度来考虑设计，用户在CAS输入用户名和密码之后通过ticket进行认证，能够有效防止密码泄露。CAS广泛使用于传统应用场景中，比如企业内部的OA，ERP等应用，不适用于微服务领域。

• 设计实现流程

• CAS代理认证有两个应用App1和App2，它们都是受Cas Server保护，请求它们时都需要通过Cas Server的认证。现需要在App1中以Http方式请求访问App2，显然该请求将会被App2配置的Cas的AuthenticationFilter拦截并转向Cas Server，Cas Server将引导用户进行登录认证，这样我们也 就不能真正的访问到App2了。针对这种应用场景，Cas也提供了对应的支持。

代理认证具体流程: App1先通过Cas Server的认证，然后向Cas Server申请一个针对于App2的proxy ticket，之后在访问App2时把申请到的针对于App2的 proxy ticket 以参数 ticket 传递过去。App2的 AuthenticationFilter 将拦截到该请求，发现该请求携带了 ticket 参数后将放行交由后续的Ticket Validation Filter处理。Ticket Validation Filter将会传递该ticket到Cas Server进行认证，显然该ticket是由Cas Server针对于App2发行的，App2在申请校验时是可以校验通过的，这样我们就可以正常的访问App2了。

2.5 技术方案-OpenID认证

• 概述OIDC( OpenID Connect) 是属于是OAuth 2.0协议之上的简单身份层，用API进行身份交互，允许客户端根据授权服务的认证结果确认用户的最终身份，它支持包括Web、移动、JavaScript在内的所有客户端类型。它与OAuth的主要区别是在于, OpenID 只用于身份认证，例如允许一个账户登录多个网站；而OAuth可以用于授权，允许授权的客户端访问指定的资源服务。
• 应用场景如果有独立账号体系，需要为外部提供统一认证服务， 可以采用OIDC，OIDC目前有很多企业在使用，比如Google的账号认证体系，Microsoft的账号体系也采用了OIDC。
• 如何工作OAuth2提供了Access Token来解决授权第三方客户端访问受保护资源的问题；OIDC在这个基础上提供了ID Token来解决第三方客户端标识用户身份认证的问题。OIDC的核心在于在OAuth2的授权流程中，一并提供用户的身份认证信息（ID Token）给到第三方客户端，ID Token使用JWT格式来包装，得益于JWT（JSON Web Token）的自包含性，紧凑性以及防篡改机制，使得ID Token可以安全的传递给第三方客户端程序并且容易被验证。此外还提供了UserInfo的接口，用户获取用户的更完整的信息。
• 工作流程术语解析:

1. EU（End User）：代表终端用户。
2. RP（Relying Party）：指OAuth2中受信任的客户端。
3. OP（OpenID Provider）：有能力提供EU认证的服务（比如OAuth2中的授权服务），为RP提供EU的身份认证信息.
4. ID Token：JWT格式的数据，包含EU身份认证的信息。
5. UserInfo Endpoint：用户信息接口（受OAuth2保护），当RP使用Access Token访问时，返回授权用户的信息，此接口必须使用HTTPS

• 工作模式

1. 默认模式/简化模式（Implicit Flow）：如果是Web应用服务，其所有的代码都有可能被加载到浏览器暴露出来，无法保证终端client_secret的安全性，则采用默认模式。
2. 授权码模式（Authentication Flow）：如果是传统的客户端应用，后端服务和用户信息是隔离的，能保证client_secret的不被泄露，就可以使用授权码模式流程。
3. 混合模式（Hybrid Flow）：实质上是以上两种模式的融合，混合模式下ID Token通过浏览器的前端通道传递，而Access Token和Refresh Token通过后端获取，混合使用， 可以弥补两种模式的缺点，一般推荐使用混合模式。

2.6 技术方案-SAML2.0认证

• 什么是SAMLSAML 全称是 Security Assertion Markup Language。SAML是支持身份认证的协议，它可以通过支持XACML协议进行权限控制。SAML是基于XML实现的协议，较OAUTH来说较复杂些，但功能也十分强大，支持认证，权限控制和用户属性识别等。目前在云服务的接入使用比较广泛，作为重点内容， 在下面的章节做详细讲解。

2.7 技术方案-OAuth2认证

• 什么是OAuthOAuth 2.0 是一个行业的标准授权协议，它的最终目的是为第三方应用颁发一个有时效性的令牌token，使得第三方应用能够通过该令牌获取相关的资源。它的主要作用可以实现登录认证与授权，常见的场景：比如第三方登录，当你要登录某个论坛，但没有账号，通过QQ 登录的过程就是采用 OAuth 2.0 协议， 通过OAuth2的授权，可以获取QQ头像等资源信息。OAuth2是目前应用最为广泛的认证授权协议，这是重点内容，在后面的章节做详细深入讲解。