深入浅出单点登录---2、解决方案-灵析社区

提笔写架构

设计方案-Cookie

概述

用户登录之后, 将认证信息存储至Cookie，当再次访问本服务或者访问其他应用服务时，直接从Cookie中传递 认证信息，进行鉴权处理。

问题

1. 如何保障Cookie内用户认证信息的安全性?

第一, Cookie内不能存放用户名和密码等敏感信息, 可以生成一串Token进行替代;

第二, 通过加密方式存储Cookie信息，并且采用https加密方式传输，设定Cookie有效期，在服务端设定 Token的有效   期，避免攻击者伪造用户身份。

2. 如何解决跨域问题?

在实际应用中， 经常会存在各种服务需要鉴权处理， 但受浏览器同源策略限制，无法去正常操作 Cookie数据, 解决方式有两种:

第一种，采用iframe方式解决跨域问题, 实现Cookie共享，但要注意，父窗口获取子窗口在跨域下可以 正常获取，子窗口后去父窗口仍会存在跨域问题， 这点在实现的时候要注意。

第二种，采用JSONP方式实现跨域传输，这需要在服务端设置允许跨域请求， response.setHeader(“Access-Control-Allow-Origin”, “*”); 设置允许任何域名跨域访问，服务端返回数 据时，再设置callback，才能完成跨域请求。

跨域Cookie设计实现方案


设计方案-分布式Session

概述

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

实现流程


技术框架

Spring Session : 它是目前主流的Session 管理解决方案，Spring Session 并非特定应用于HTTP， 它是一种 广义的分布式统一Session，支持WebSocket和WebSession等，并且可以基于Redis、MongoDB等多种高性 能缓存来实现。

XXL-SSO: 它是一个分布式单点登录框架。只需要登录一次就可以访问所有相互信任的应用系统。拥有”轻量 级、分布式、跨域、Cookie+Token均支持、Web+APP均支持”等特性。现已开放源代码，开箱即用。架构图:

设计方案-客户端令牌Token

概述

根据客户端身份信息由认证服务生成签名令牌，令牌中会包含基本的用户信息，客户端在请求资源服务时会 附带令牌，资源服务根据加密协议在本地进行验证， 或者发送给认证服务端进行校验。它可以解决分布式会 话的安全性问题，比如会话劫持，同时不需要集中统一维护session，能够做到无状态化处理。OAuth2和JWT 都是基于令牌Token实现的认证方案。

适用场景

JWT (JSON Web Token) 是一个开放安全的行业标准,用于多个系统之间传递安全可靠的信息。它由三部分组 成，头部(Header)、载荷(playload)与签名(Signature)。Token实质是一个无意义的UUID，需要服务端做记录与认证， 但JWT则赋予了用户的身份信息，可以采用自定义算法进行加密与解密，直接实现信息的传输交 换。那具体适用于哪些场景?

  • 可以适用于微服务应用， 无论是内部服务节点的认证与授权， 或是令牌与API网关结合的认证。
  • 可以适用于开放式的API接口访问，比如前后分离API对接，第三方API接口对接等。

实现流程

设计方案-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了。

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.当用户第一次登录时，将用户名 密码发送给用户服务

2.验证用户将用户标识OpenId返回到客户端

3.客户端进行存储

4.访问子系统 将OpenId发送到子系统

5子系统将OpenId转发到验证服务

6.验证服务将用户认证信息返回给子系统

7.子系统构建用户验证信息后将授权后的内容返回给客户端

工作模式

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

Token和Refresh Token通过后端获取，混合使用， 可以弥补两种模式的缺点，一般推荐使用混合模式。

SAML2.0认证

概述

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

OAuth2认证

概述

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

阅读量：2021

点赞量：0

收藏量:0