从淘宝天猫的单点登录说起
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登录实现流程解析
- 用户进入淘宝登录页面,调用地址: https://login.taobao.com/newlogin/login.do
- 调用成功之后,同步Cookie,保存Token认证信息。
- 访问天猫网站,从Cookie里面拿取Token信息,采用jsonp方式,获取淘宝的登录状态:
- 如果不是从淘宝登录, 由天猫发起登录,会请求至淘宝登录页面, 登录完成之后写入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设计实现方案
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的接口,用户获取用户的更完整的信息。 -
工作流程
术语解析:- EU(End User):代表终端用户。
- RP(Relying Party): 指OAuth2中受信任的客户端。
- OP(OpenID Provider):有能力提供EU认证的服务(比如OAuth2中的授权服务),为RP提供EU的身份认证信息.
- ID Token:JWT格式的数据,包含EU身份认证的信息。
- UserInfo Endpoint:用户信息接口(受OAuth2保护),当RP使用Access Token访问时,返回授权用户的信息,此接口必须使用HTTPS
-
工作模式
- 默认模式/简化模式(Implicit Flow):如果是Web应用服务,其所有的代码都有可能被加载到浏览器暴露出来,无法保证终端client_secret的安全性,则采用默认模式。
- 授权码模式(Authentication Flow): 如果是传统的客户端应用,后端服务和用户信息是隔离的,能保证client_secret的不被泄露,就可以使用授权码模式流程。
- 混合模式(Hybrid Flow): 实质上是以上两种模式的融合,混合模式下ID Token通过浏览器的前端通道传递,而Access Token和Refresh Token通过后端获取,混合使用, 可以弥补两种模式的缺点,一般推荐使用混合模式。
2.6 技术方案-SAML2.0认证
- 什么是SAML
SAML 全称是 Security Assertion Markup Language。SAML是支持身份认证的协议,它可以通过支持XACML协议进行权限控制。SAML是基于XML实现的协议,较OAUTH来说较复杂些,但功能也十分强大,支持认证,权限控制和用户属性识别等。目前在云服务的接入使用比较广泛,作为重点内容, 在下面的章节做详细讲解。
2.7 技术方案-OAuth2认证
- 什么是OAuth
OAuth 2.0 是一个行业的标准授权协议,它的最终目的是为第三方应用颁发一个有时效性的令牌token,使得第三方应用能够通过该令牌获取相关的资源。它的主要作用可以实现登录认证与授权,常见的场景:比如第三方登录,当你要登录某个论坛,但没有账号,通过QQ 登录的过程就是采用 OAuth 2.0 协议, 通过OAuth2的授权,可以获取QQ头像等资源信息。OAuth2是目前应用最为广泛的认证授权协议,这是重点内容,在下面的章节做详细深入讲解