精华内容
下载资源
问答
  • 单点登录实现方案
    千次阅读
    2020-04-07 09:15:32

    当需要自动一次登录多个系统可用时,这个时候需要用到的技术就是Single Sign-On(SSO), 中文名单点登录

    具体来说,就是打个比方,我们假设有一个系统集A(例如ERP),其中包含多个子系统(例如CRM, HCM)。

    我们期望任意子系统登录后,以CRM为例,整个ERP系统里的所有子系统都可以使用当前的会话信息、无需二次登录。这就是SSO。为了实现SSO,我们需要做到以下几步。

    首先,需要考虑用什么样的用户账号进行登录。这里我们有两个选择:

    • 选择一:ERP专用用户账号。即ERP有自己的账号,每个用户需要向ERP申请账号和密码
    • 选择二:用户电脑的Domain账号。简单理解就是电脑开机账号/密码。

    如果使用选择一:ERP专用用户账号,那么单点登录流程是:

    1. (前提:用户未登录)用户访问CRM登录页,手动输入用户名/密码。
    2. 登录请求被重定向到SSO认证中心。
    3. SSO认证通过。
    4. CRM登录成功。
    5. 此时访问别的ERP子系统,则自动登录成功,无需手动登录。

    如果使用选择二:用户电脑的Domain账号,那么单点登录的方案有2种:

    • SSO认证中心实现CAS登录
    1. (前提:用户未登录)用户访问CRM系统。CRM自动发送登录请求到SSO认证中心。
    2. SSO使用CAS机制,用用户电脑的Domain账号进行登录认证。
    3. SSO认证通过。
    4. CRM自动登录成功。
    5. 此时访问别的ERP子系统,则自动登录成功,无需手动登录。
    • CRM实现CAS登录
    1. (前提:用户未登录)用户访问CRM系统。CRM自动生成登录请求。
    2. CRM使用CAS机制,用用户电脑的Domain账号进行登录认证。
    3. CRM SSO认证通过。
    4. CRM自动登录成功。
    5. 但是此时访问别的ERP子系统并不会实现自动登录。

    附录:图解CAS架构

    icon源于这里

    更多相关内容
  • 单点登录实现方案

    2017-11-30 21:53:40
    一种单点登录实现方案,以jdk为例应用keytool自己制作https证书。
  • 单点登录方案设计

    千次阅读 2021-07-11 08:59:41
    单点登录在任何稍成规模的分布式系统,或者sass,或者中台型的架构中,都是必不可少的,单点登录主要达到的目的是:一处登录,处处登录 这里主要提2种实际生产环境下比较常用的2种业务场景,第一种,产品自身的单点...

    前言

    单点登录在任何稍成规模的分布式系统,或者sass,或者中台型的架构中,都是必不可少的,单点登录主要达到的目的是:一处登录,处处登录

    这里主要提2种实际生产环境下比较常用的2种业务场景,第一种,产品自身的单点登录需求,比如像下面这张图:

    在这里插入图片描述
    这张图反映的是一些类似sass系统或者业务中台类似的体系架构,一个系统的各个产品均能通过一个统一的登录入口进入,然后由各个产品应用图标,再进入各自的模块产品

    第二种业务场景是,当涉及到和第三方应用进行对接的时候,第三方系统希望共享与本系统的部分用户信息,通俗来讲就是,本系统的某些产品对接了第三方平台的应用,客户端希望能够在本系统和外部系统之间来回切换,而不用重复在2个平台之间进行登录,以下图进行理解:

    在这里插入图片描述

    本篇以上面的2个需求点入手,从业务的角度引申到实际方案的实现进行一些探讨和经验的分享

    平台内部单点登录实现方案

    1、cookie实现方案

    这是一种最简单的单点登录实现方式,是使用cookie作为媒介,存放用户会话凭证

    简而言之,用户登录父应用之后,应用返回一个cookie(或加密的cookie),当用户访问子应用的时候,携带上这个cookie,授权应用拿到cookie并进行校验,校验通过则允许该用户访问当前应用

    在这里插入图片描述

    cookie信息通常可以在浏览器中进行查看,如果后端没有做任何的处理,通常以jsessionid进行展示

    我们知道,对于sass平台或类似的系统,父应用或者顶级应用在登录成功后,会进入主域名,比如taobao.com,然后再从主域名进入各个子系统,即二级域名下,如果是同域的情况下,cookie的会话信息是可以共享(或者传递)的,这样的话,当主域名的用户关键信息存至cookie后,其他子域下的系统就可以拿到当前cookie的信息进行解析并获取用户信息

    cookie方案可使登录后的用户在各个应用之间正常的访问,当然,在实际生产中,同一个用户在各个应用之间的切换与访问也是有前提条件的,那就是权限体系的认证,即至少保证当前用户拥有要访问应用的权限

    在小编过往的项目中,sass平台有一个统一用户系统,所有访问系统的用户均需在用户的体系下存在,然后在用户系统中进行对使用其他应用的访问权限进行统一配置(赋权)之后,才能进行各个应用之间的切换,从具体的实现来说,主要分为如下步骤:

    1. 用户中心注册用户(或管理员添加)
    2. 其他应用访问权限配置(菜单,资源授权等)
    3. 用户登录统一认证系统
    4. 各应用通过用户中心统一dubbo接口返回值做进一步业务处理
    5. 校验是否切换至不同应用

    在这里插入图片描述
    2、token实现方案

    cookie方案在实际实施的时候,被很多人吐槽的点有2个,容易被截取(不够安全),不够轻量级,就这2点,就足够成为分布式应用下如何高效进行会话传输被舍弃的因素了,因此在本人经历的项目以及从主流的解决方案下,token方案开始越来越被很多互联网公司接受

    token的实现相对简单,前后端交互方便,存储的安全性可以根据采用的加密技术提升安全性,主流的实现像:springsecurity , jwt+shiro 等,都是不错的实现思路

    具体来说,token的实现方案和cookie的实现方案本质不同点在于会话信息的传输上有所不同,其基础的架构体系并没有太大的差别,但token解决这个问题更灵活的地方在于,

    • 可以根据业务需要定制化加密方案
    • 可以在数据库层面或者其他数据存储上面存储
    • 可以灵活的做会话的自动续期

    总的来说,业务层面的操作和上面cookie方案中的没有本质差别,只体现在具体的实现上,这样以来,用户中心的总体业务层的规划可按如下理解

    在这里插入图片描述
    关于token的具体落地实现方案,有兴趣的同学可以参考我之前的2篇文章:springboot+shiro实现安全认证以及基于springcloud实现安全认证

    总结一下,以上两种实现方案适合初具中台规模或者类sass系统的平台,拥有独立的用户中心体系,需要通过独立的用户中心进行其他应用的资源配置,认证,授权等,在这种架构下,采用单点登录具有它存在的价值和意义,毕竟单独把用户中心拆分成独立的微服务,是需要投入一定的技术和人力成本的

    与第三方平台对接时单点登录实现方案

    当sass系统做大了之后,比如像支付宝,很多其他第三方应用为了对接支付宝的支付体系,举例来说,当我们在美团下单时,提示我们选择支付宝支付的时候,需要跳转到支付宝的一个认证页面进行认证,只有认证通过之后,才能进行支付

    这里涉及到一个用户信息的转换问题,可以理解为认证中心,这个认证中心具备用户认证,以及分发凭证的功能,认证中心的实现我们无从得知,但是可以参考springsecurity的认证功能实现,和oauth2那一套大体类似

    我们这里探讨的是一种更通用的基于sass平台或者中台模式的实现,即假定通过我们自身的sass平台跳转到第三方平台的应用系统,或者由第三方应用系统跳转到我们自身的sass系统,该如何实现的问题

    方案一:第三方应用作为自身平台的一个应用注册

    第三方系统作为一个应用,集成到自身的sass平台。用户以自身平台为入口登录并跳转至第三方系统

    同域

    当自身平台与第三方系统同域时,第三方系统能够直接通过Cookie获取本平台用户会话信息(token),通过调用本平台提供的相关dubbo接口即可获取用户信息,进而同步用户至第三方系统并实现免登录

    在这里插入图片描述

    同域情况下,第三方应用可以拿到本平台的cookie信息,拿到之后,进一步调用本平台提供的dubbo接口获取用户的数据,一般来说,这种情况下,第三方系统为了更好的管理用户数据,需要和本平台的用户信息进行适配,对第三方系统来说,只需要自己的系统用户表中做一个映射即可达到目的

    非同域

    当自身sass平台与第三方系统非同域时,第三方系统就无法通过浏览器Cookie信息获取自身sass平台用户会话信息,这时候可以借助中间件,通过中间件传递用户信息

    • 在上一步的基础上,仍然将第三方应用注册到本平台
    • 第三方平台需要监听特定的消息队列
    • 本平台用户登录成功后,向消息队列推送当前用户会话信息
    • 第三方平台从消息队列解析用户信息,执行自动登录

    方案二:将本平台作为一个应用注册到第三方系统

    此种方案需要提供本平台用户登录的URL给第三方系统,同样需要考虑同域和非同域的情况

    同域

    需要根据情况实现特殊单点登录SPI服务

    当本平台与第三方系统同域时,第三方系统将会话信息(识别用户即可)写入浏览器Cookie,随即跳转至本平台登录页面,特殊单点登录SPI服务(需要实现)读取Cookie中的用户信息,对用户进行同步、免登录等。

    通常这种方式涉及到2个系统的对接,需要对方的开发人员提供一些配置信息,比如本系统提供登录的URL,而第三方系统提供登录回调的URL,这样的话在本系统完成登录的逻辑之后才知道调回的路径

    但是本人经历的项目中是这么做的,提供一个基于spi实现的一个验证token的jar包,这个jar包可立即为一个简单的工程,该工程实现了一个关键的接口,在该接口中实现的逻辑是,校验token,解析出用户信息,然后执行自动登录,并跳转url

    在这里插入图片描述

    很明显,这个jar包是作为连接本系统和第三方系统用的

    非同域

    当本平台与第三方系统非同域时,第三方系统无法将会话信息写入浏览器Cookie,这时候需要实现中间件部署在与本平台同域环境中,第三方系统先跳转至中间件页面,通过中间件将用户信息写入Cookie,最后跳转至UYUN平台登录页面,特殊单点登录SPI服务(需要实现)读取Cookie中的用户信息,对用户进行同步、免登录等。

    在这里插入图片描述

    图中的中间件可理解为一个需要通过消息中间件实现用户信息传递的一个工程,该工程部署在和本平台同域的环境上

    方案三:CAS单点登录

    这种方案的实现网上可以参考的资料非常多,也是当下比较简单的一种实现,开发者只需要对cas证书做配置,这里不再赘述了

    展开全文
  • 从技术本身的角度分析了单点登录技术的内部机制和实现手段,并且给出Web-SSO和桌面SSO的实现、源代码和详细讲解;还从安全和性能的角度对现有的实现技术进行进一步分析,指出相应的风险和需要改进的方面。本文除了从...

    单点登录(SSO)的技术被越来越广泛地运用到各个领域的软件系统当中。本文从业务的角度分析了单点登录的需求和应用领域;从技术本身的角度分析了单点登录技术的内部机制和实现手段,并且给出Web-SSO和桌面SSO的实现、源代码和详细讲解;还从安全和性能的角度对现有的实现技术进行进一步分析,指出相应的风险和需要改进的方面。本文除了从多个方面和角度给出了对单点登录(SSO)的全面分析,还并且讨论了如何将现有的应用和SSO服务结合起来,能够帮助应用架构师和系统分析人员从本质上认识单点登录,从而更好地设计出符合需要的安全架构。

    单点登录是什么?

    单点登录(Single Sign On),简称为 SSO,是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。所以你会看到很多域名直接是sso.domain.com,也就是用来做单点登录的。

    979966f3fa23300daac911c74a3be32f.png

    如上图,一个用户请求N个系统,给用户的感觉是一个系统的感觉,而不要重复登录。

    单点登录是一个概念性东西,既然是概念,那么就有很多实现方式。

    实现方案

    根据不同的业务场景来不同的实现方式。下面来罗列一下对应的场景以及实现单点登录的方式。

    一、方案一。

    域名:a.sojson.com 、b.sojson.com、c.sojson.com、n.sojson.com

    描述:N个系统,但是一级域名是一致的。如果不懂一级域名、二级域名是什么意思先查看这篇博客。《单个项目多个二级域名简单实现思路》。这个案例实现相对简单,如下图:

    9ae12f4e6a0e43a2c5234f13514989e1.png

    PS:这个方案比较简单,只要提供公共的SDK即可,不需要第三个系统的出现,这个SDK的工作需要管理Cookie和用户信息。

    原理:其实质这里就是利用了二级域名写一级域名的Cookie。

    优点:轻量级、可插拔、效率非常高。

    缺点:局限性限于一级域名是一样的。

    二、方案二

    域名:www.sojson.com、a.sojson.com、www.itboy.net、www.wenyiba.com。

    描述:域名比较乱,有同一个一级域名的(www.sojson.com、a.sojson.com),也有不同域名的。

    这个稍微复杂一点,如下图:

    58dfccd81987fe8ea79a8f6bedc73d5a.png

    原理:通过SSO系统(登录、退出),Iframe引用的方式引入Cookie.domain.com的方式,利用Javascript操作(写入 / 删除 / 修改) cookie,而这个cookie.domain.com 域名是放入CDN上 ,获取用户信息当前系统直接通过Redis(只读)获取。

    优点:因为是采用压力分化,Cookie.domain.com 部署在CDN上,这样的话,对各个系统造成的压力是 0 ,用第三方系统(SSO)维护,权限更大,操作性更强,但又Cookie信息在当前域名的一级域下,获取简单,大量减少对sso的访问量。

    缺点:如果浏览器安全性过高,Iframe的方式操作Cookie将会失败。比如IE浏览器,目前正在攻克IE浏览器。

    三、方案三

    域名:www.sojson.com、a.sojson.com、www.itboy.net、www.wenyiba.com。

    描述:域名比较乱,有同一个一级域名的(www.sojson.com、a.sojson.com),也有不同域名的。

    (条件和方案二一样),实现思路如下图:

    b9a6b19039daf47573f5274155dcebdb.png

    原理:所有的请求(登录、退出、获取用户信息、当前用户状态)都请求sso系统,sso系统维护用户信息,Session,UserInfo。

    优点:实现较为简单。

    缺点:SSO压力非常大。

    四、方案四

    域名:www.sojson.com、a.sojson.com、www.itboy.net、www.wenyiba.com。

    描述:域名比较乱,有同一个一级域名的(www.sojson.com、a.sojson.com),也有不同域名的。

    (条件和方案二一样),实现采用CAS方式,这里就不做介绍了,资料非常多。

    原理:和方案三类似。

    优点:现成的,资料较多。

    缺点:繁重、灵活性差。

    如果本文对你有帮助,那么请你赞助我,让我更有激情的写下去,帮助更多的人。

    ¥我需要走的更远,点击我 赞助。

    如果还有疑问,点击我加群,为你提供最好的解答。

    展开全文
  • 通过redis(缓存)实现单点登录

    热门讨论 2015-05-19 16:45:44
    跨应用访问 通过redis实现单点登录。即保证安全又减少多次输入密码的繁琐。
  • SSO 单点登录 OAuth 第三方登录 一、Cookie + Session 登录 HTTP 是一种无状态的协议,客户端每次发送请求时,首先要和服务器端建立一个连接,在请求完成后又会断开这个连接。这种方式可以节省传输时占用的连接...

    登录是每个网站中都会用到的一个必备功能,但是如何实现一个优秀的登录功能,如何根据自己的项目来选择一个适合自己的登录方案?今天我们就来介绍几种常用的登录方案。

    • Cookie + Session 登录
    • Token 登录
    • SSO 单点登录
    • OAuth 第三方登录

    一、Cookie + Session 登录

    HTTP 是一种无状态的协议,客户端每次发送请求时,首先要和服务器端建立一个连接,在请求完成后又会断开这个连接。这种方式可以节省传输时占用的连接资源,但同时也存在一个问题:每次请求都是独立的,服务器端无法判断本次请求和上一次请求是否来自同一个用户,进而也就无法判断用户的登录状态。

    为了解决 HTTP 无状态的问题,Lou Montulli 在 1994 年的时候,推出了 Cookie。
    Cookie 是服务器端发送给客户端的一段特殊信息,这些信息以文本的方式存放在客户端,客户端每次向服务器端发送请求时都会带上这些特殊信息。

    在 B/S 系统中,登录功能通常都是基于 Cookie 来实现的。当用户登录成功后,一般会将登录状态记录到 Session 中。要实现服务端对客户端的登录信息进行验证都,需要在客户端保存一些信息(SessionId),并要求客户端在之后的每次请求中携带它们。在这样的场景下,使用 Cookie 无疑是最方便的,因此我们一般都会将 SessionId 保存到 Cookie 中,当服务端收到请求后,通过验证 Cookie 中的信息来判断用户是否登录 。

    Cookie + Session 实现流程

    Cookie + Session 的登录方式是目前最经典的一种登录方式,现在仍然有大量的企业在使用。

    用户初次登录时:

    Cookie + Session 实现流程

    1. 用户访问 a.com/pageA,并输入密码登录。
    2. 服务器验证密码无误后,会创建 SessionId,并将它保存起来。
    3. 服务器端响应这个 HTTP 请求,并通过 Set-Cookie 头信息,将 SessionId 写入 Cookie 中。

    服务器端的 SessionId 可能存放在很多地方,例如:内存、文件、数据库等。

    第一次登录完成之后,后续的访问就可以直接使用 Cookie 进行身份验证了:

    Cookie + Session 实现流程

    1. 用户访问 a.com/pageB 页面时,会自动带上第一次登录时写入的 Cookie
    2. 服务器端比对 Cookie 中的 SessionId 和保存在服务器端的 SessionId 是否一致。
    3. 如果一致,则身份验证成功,访问页面;如果无效,则需要用户重新登录。

    小结

    虽然我们可以使用 Cookie + Session 的方式完成了登录验证,但仍然存在一些问题:

    1. 由于服务器端需要对接大量的客户端,也就需要存放大量的 SessionId,这样会导致服务器压力过大。
    2. 如果服务器端是一个集群,为了同步登录态,需要将 SessionId 同步到每一台机器上,无形中增加了服务器端维护成本。
    3. 由于 SessionId 存放在 Cookie 中,所以无法避免 CSRF 攻击。

    二、Token 登录

    为了解决 Cookie + Session 机制暴露出的诸多问题,我们可以使用 Token 的登录方式。

    Token 是通过服务端生成的一串字符串,以作为客户端请求的一个令牌。当第一次登录后,服务器会生成一个 Token 并返回给客户端,客户端后续访问时,只需带上这个 Token 即可完成身份认证。

    Token 机制实现流程

    用户首次登录时:

    Token 机制实现流程

    1. 用户访问 a.com/pageA,输入账号密码,并点击登录。
    2. 服务器端验证账号密码无误,创建 Token
    3. 服务器端将 Token 返回给客户端,由客户端自由保存
    后续页面访问时:

    Token 机制实现流程

    1. 用户访问 a.com/pageB 时,带上第一次登录时获取的 Token
    2. 服务器端验证该 Token ,有效则身份验证成功,无效则踢回重新的登录。

    Token 生成方式

    最常见的 Token 生成方式是使用 JWTJson Web Token),它是一种简洁的、自包含的方法,用于通信双方之间以 JSON 对象的形式安全的传递信息。

    使用 Token 后,服务器端并不会存储 Token,那怎么判断客户端发过来的 Token 是合法有效的呢?

    答案其实就在 Token 字符串中,其实 Token 并不是一串杂乱无章的字符串,而是通过多种算法拼接组合而成的字符串。

    JWT 算法主要分为 3 个部分:header(头信息),playload(消息体),signature(签名)。

    • header 部分指定了该 JWT 使用的签名算法;
    • playload 部分表明了 JWT 的意图;
    • signature 部分为 JWT 的签名,主要为了让 JWT 不能被随意篡改。

    关于 JWT,这里简单说明一下,具体细节大家可以去看一下 JWT 官网

    小结

    根据上面的案例,我们可以分析出 Token 的优缺点:

    • 服务器端不需要存放 Token,所以不会对服务器端造成压力,即使是服务器集群,也不需要增加维护成本。
    • Token 可以存放在前端任何地方,可以不用保存在 Cookie 中,提升了页面的安全性。
    • Token 下发之后,只要在生效时间之内,就一直有效,但是如果服务器端想收回此 Token 的权限,并不容易。

    有了 Token 之后,登录方式已经变得非常高效。


    三、SSO 单点登录

    单点登录是指在同一帐号平台下的多个应用系统中,用户只需登录一次,即可访问所有相互信任的应用系统。本质就是在多个应用系统中共享登录状态。举例来说,百度贴吧和百度地图是百度公司旗下的两个不同的应用系统,如果用户在百度贴吧登录过之后,当他访问百度地图时无需再次登录,那么就说明百度贴吧和百度地图之间实现了单点登录。

    SSO 机制实现流程

    用户首次访问时,需要在认证中心登录:

     SSO 机制实现流程

    1. 用户访问网站 a.com 下的 pageA 页面。
    2. 由于没有登录,则会重定向到认证中心,并带上回调地址 www.sso.com?return_uri=a.com/pageA,以便登录后直接进入对应页面。
    3. 用户在认证中心输入账号密码,提交登录。
    4. 认证中心验证账号密码有效,然后重定向 a.com?ticket=123 带上授权码 ticket,并将认证中心 sso.com 的登录态写入 Cookie
    5. a.com 服务器中,拿着 ticket 向认证中心确认,授权码 ticket 真实有效。
    6. 验证成功后,服务器将登录信息写入 Cookie(此时客户端有 2 个 Cookie 分别存有 a.comsso.com 的登录态)。
    认证中心登录完成之后,继续访问 a.com 下的其他页面:

    SSO 机制实现流程
    这个时候,由于 a.com 存在已登录的 Cookie 信息,所以服务器端直接认证成功。

    如果认证中心登录完成之后,访问 b.com 下的页面:

    SSO 机制实现流程
    这个时候,由于认证中心存在之前登录过的 Cookie,所以也不用再次输入账号密码,直接返回第 4 步,下发 ticketb.com 即可。

    SSO 机制实现方式

    单点登录主要有三种实现方式:

    1. 父域 Cookie
    2. 认证中心
    3. LocalStorage 跨域

    一般情况下,用户的登录状态是记录在 Session 中的,要实现共享登录状态,就要先共享 Session,但是由于不同的应用系统有着不同的域名,尽管 Session 共享了,但是由于 SessionId 是往往保存在浏览器 Cookie 中的,因此存在作用域的限制,无法跨域名传递,也就是说当用户在 a.com 中登录后,Session Id 仅在浏览器访问 a.com 时才会自动在请求头中携带,而当浏览器访问 b.com 时,Session Id 是不会被带过去的。实现单点登录的关键在于,如何让 Session Id(或 Token)在多个域中共享。

    1. 父域 Cookie

    Cookie 的作用域由 domain 属性和 path 属性共同决定。domain 属性的有效值为当前域或其父域的域名/IP地址,在 Tomcat 中,domain 属性默认为当前域的域名/IP地址。path 属性的有效值是以“/”开头的路径,在 Tomcat 中,path 属性默认为当前 Web 应用的上下文路径。

    如果将 Cookiedomain 属性设置为当前域的父域,那么就认为它是父域 CookieCookie 有一个特点,即父域中的 Cookie 被子域所共享,也就是说,子域会自动继承父域中的 Cookie

    利用 Cookie 的这个特点,可以将 Session Id(或 Token)保存到父域中就可以了。我们只需要将 Cookiedomain 属性设置为父域的域名(主域名),同时将 Cookiepath 属性设置为根路径,这样所有的子域应用就都可以访问到这个 Cookie 了。不过这要求应用系统的域名需建立在一个共同的主域名之下,如 tieba.baidu.com 和 map.baidu.com,它们都建立在 baidu.com 这个主域名之下,那么它们就可以通过这种方式来实现单点登录。

    总结:此种实现方式比较简单,但不支持跨主域名。

    2. 认证中心

    我们可以部署一个认证中心,认证中心就是一个专门负责处理登录请求的独立的 Web 服务。

    用户统一在认证中心进行登录,登录成功后,认证中心记录用户的登录状态,并将 Token 写入 Cookie。(注意这个 Cookie 是认证中心的,应用系统是访问不到的)

    应用系统检查当前请求有没有 Token,如果没有,说明用户在当前系统中尚未登录,那么就将页面跳转至认证中心进行登录。由于这个操作会将认证中心的 Cookie 自动带过去,因此,认证中心能够根据 Cookie 知道用户是否已经登录过了。如果认证中心发现用户尚未登录,则返回登录页面,等待用户登录,如果发现用户已经登录过了,就不会让用户再次登录了,而是会跳转回目标 URL ,并在跳转前生成一个 Token,拼接在目标 URL 的后面,回传给目标应用系统。

    应用系统拿到 Token 之后,还需要向认证中心确认下 Token 的合法性,防止用户伪造。确认无误后,应用系统记录用户的登录状态,并将 Token 写入 Cookie,然后给本次访问放行。(这个 Cookie 是当前应用系统的,其他应用系统是访问不到的)当用户再次访问当前应用系统时,就会自动带上这个 Token,应用系统验证 Token 发现用户已登录,于是就不会有认证中心什么事了。

    总结:此种实现方式相对复杂,支持跨域,扩展性好,是单点登录的标准做法。

    3. LocalStorage 跨域

    单点登录的关键在于,如何让 Session Id(或 Token)在多个域中共享。但是 Cookie 是不支持跨主域名的,而且浏览器对 Cookie 的跨域限制越来越严格。

    在前后端分离的情况下,完全可以不使用 Cookie,我们可以选择将 Session Id (或 Token )保存到浏览器的 LocalStorage 中,让前端在每次向后端发送请求时,主动将 LocalStorage 的数据传递给服务端。这些都是由前端来控制的,后端需要做的仅仅是在用户登录成功后,将 Session Id (或 Token )放在响应体中传递给前端。

    在这样的场景下,单点登录完全可以在前端实现。前端拿到 Session Id (或 Token )后,除了将它写入自己的 LocalStorage 中之外,还可以通过特殊手段将它写入多个其他域下的 LocalStorage 中。

    总结:此种实现方式完全由前端控制,几乎不需要后端参与,同样支持跨域。

    SSO 单点登录退出

    目前我们已经完成了单点登录,在同一套认证中心的管理下,多个产品可以共享登录态。现在我们需要考虑退出了,即:在一个产品中退出了登录,怎么让其他的产品也都退出登录?

    原理其实不难,可以在每一个产品在向认证中心验证 ticket(token) 时,其实可以顺带将自己的退出登录 api 发送到认证中心。

    当某个产品 c.com 退出登录时:

    1. 清空 c.com 中的登录态 Cookie
    2. 请求认证中心 sso.com 中的退出 api
    3. 认证中心遍历下发过 ticket(token) 的所有产品,并调用对应的退出 api,完成退出。

    四、OAuth 第三方登录

    OAuth 第三方登录方式通常使用以下三种方式:
    在这里插入图片描述

    OAuth 机制实现流程

    这里以微信开放平台的接入流程为例:
    OAuth 机制实现流程

    1. 首先,a.com 的运营者需要在微信开放平台注册账号,并向微信申请使用微信登录功能。
    2. 申请成功后,得到申请的 appidappsecret
    3. 用户在 a.com 上选择使用微信登录。
    4. 这时会跳转微信的 OAuth 授权登录,并带上 a.com 的回调地址。
    5. 用户输入微信账号和密码,登录成功后,需要选择具体的授权范围,如:授权用户的头像、昵称等。
    6. 授权之后,微信会根据拉起 a.com?code=123 ,这时带上了一个临时票据 code
    7. 获取 code 之后, a.com 会拿着 codeappidappsecret,向微信服务器申请 token,验证成功后,微信会下发一个 token
    8. 有了 token 之后, a.com 就可以凭借 token 拿到对应的微信用户头像,用户昵称等信息了。
    9. a.com 提示用户登录成功,并将登录状态写入 Cookie,以作为后续访问的凭证。

    其他平台的接入方式可以去对应得官方文档查看,流程基本类似。


    总结

    上面四种登录实现方案,基本囊括了现有的登录验证方案,原理以及实现流程基本都了解。

    • Cookie + Session 历史悠久,适合于简单的后端架构,需开发人员自己处理好安全问题。
    • Token 方案对后端压力小,适合大型分布式的后端架构,但已分发出去的 token ,如果想收回权限,就不是很方便了。
    • SSO 单点登录,适用于中大型企业,想要统一内部所有产品的登录方式的情况。
    • OAuth 第三方登录,简单易用,对用户和开发者都友好,但第三方平台很多,需要选择合适自己的第三方登录平台。

    参考文章:
    https://cnblogs.com/yonghengzh/p/13712729.html
    https://mp.weixin.qq.com/s/lcryd6TPXWqfQPGGt0qkmQ

    展开全文
  • 前后端分离模式下 CAS 单点登录实现方案前言知识点前后端分离单点登录CAS用户登录登录用户访问其他资源CAS ServerCAS ClientTicket Grangting Ticket(TGT)Ticket-granting cookie(TGC)Service ticket(ST)...
  • SSO跨域单点登录实现方案

    万次阅读 2018-08-28 11:28:43
    SSO简介 定义: 传统的单站点登录访问授权机制是:登录成功后将用户...单点登录是一种多站点共享登录访问授权机制,访问用户只需要在一个站点登录就可以访问其它站点需要登录访问的资源(url)。用户在任意一个站点...
  • CAS实现单点登录

    千次阅读 多人点赞 2022-01-25 22:15:34
    1.单点登录(Single Sign On),简称为 SSO,是比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。 CAS下载安装 1.CAS是Central ...
  • 使用Redis实现CAS单点登录技术方案

    千次阅读 2019-02-19 13:10:45
    单点登录(Single Sign On),简称为 SSO,是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。 我们目前的系统存在诸多子系统,而...
  • 上篇文章讲了 CAS 单点登录以及 CAS Server 的搭建问题,CAS Server 搭建好了,接下来我们要搭建具体的应用,本文我们就来看看 Spring Security+CAS 如何实现单点登录。 本文在上篇文章的基础上继续完成,如果小伙伴...
  • 文章目录一、什么是单点登录二、单点登录原理三、单点登录实现方式1.基于Cookie+Redis的单点登录2.分布式session方式实现单点登录3.token验证4.session广播5.CAS 中央认证服务 一、什么是单点登录 单点登录的英文名...
  • 跨域单点登录解决方案

    千次阅读 2020-10-10 10:23:46
    单点登录有两种模型,一种是共同父域下的单点登录(例如域名都是 xx.a.com),还有就是完全跨域下的单点登录(例如域名是xx.a.com,xx.b.com),本文我们讲一下完全跨域下的单点登录该怎么实现。基于安全考虑,想...
  • 单点登录方案实战

    千次阅读 2019-02-20 13:53:14
    单点登录先介绍下:oauth2与单点登陆的区别session-cookie机制session共享方式,实现单点登陆使用场景实现方法Session共享方式的限制顶级域名不一样的网站怎么办?这时候就需要CAS登场了cas单点登陆方案 先介绍下...
  • 单点登录的几种方案

    千次阅读 2021-03-23 20:12:37
    单点登录单点登录存在原因方案方案二:session同步方案三:第三方存储件存储session方案四:对接第三方系统的单点登录 视频讲解链接 单点登录存在原因 分布式微服务成为主流的情况下,需要解决只能在单个用户模块...
  • 基于JWT实现单点登录

    千次阅读 2022-05-15 00:00:25
    单点登录概述: 多系统共存下,用户在一处地方登录,得到其他所有系统的信任,无需再次登录。 自己的理解:在进行用户登录的时候,jwt生成一个token,用户带着这个token去其他页面进行验证。(token设置过期时间) ...
  • PHP 单点登录实现方案

    万次阅读 2017-10-26 11:26:54
    PHP 单点登录实现方案
  • Oauth2方式实现单点登录

    万次阅读 多人点赞 2020-07-30 11:18:48
    单点登录实现 下面我们就要开始动手了。 第一步,配置哪些应用可以到我们服务器中来获取认证。 可以看下图里面的关键往上,clientId,redirectUri 就是我们在上面的原理介绍中包括的, 这里还有一个关键的信息 ...
  • 单点登录的核心思路是客户端存储AuthToken,服务端存储登录信息。由于客户端将AuthToken存储在Cookie中,所以要解决Cookie的跨域读写问题。 回顾Cookie的路径(path)和域(domain) cookie路径 cookie 一般都是由于...
  • java实现单点登录的两种方式

    千次阅读 2021-02-12 12:36:41
    1.如果两个网站域名的一级域名相同,可以使用cookie和filter实现单点登录,因为网站有可能(具体看cookie的设置)可以共享cookie。例如:www.bbs.aa.cnwww.news.aa.cn。第一个网站在登录后,把用户信息写到cookie中,...
  • CAS方式实现单点登录

    千次阅读 2021-11-01 10:51:44
    单点登录,英文是 Single Sign On,缩写为 SSO。 多个站点(192.168.1.20X)共用一台认证授权服务器(192.168.1.110,用户数据库和认证授权模块共用)。用户经由其中任何一个站点(比如 192.168.1.201)登录后,可以免登录...
  • 前端实现单点登录的几种方式

    千次阅读 2021-10-09 11:33:03
    在进入另一个系统时,利用vue的路由管理判断用户信息是否一致,一致则进入系统,不一致跳转至登录页。 2、认证中心 单独建立认证中心,负责处理登录请求的独立服务,由认证中心检测token并返回给客户端,客户端作...
  • java实现完全跨域SSO单点登录

    万次阅读 多人点赞 2018-08-16 16:33:01
    SSO(Single Sign On)单点登录实现多个系统之间统一登录的验证系统,简单来说就是:有A,B,C三个系统,在A处登录过后,再访问B系统,B系统就已经处于了登录状态,C系统也是一样。举个生活中栗子:你同时打开天猫...
  • 单点登录原理及其实现方案

    千次阅读 2021-02-02 12:54:47
    单点登录(Single sign-on,简称 SSO),一种对于许多相互关连,但是又是各自独立的软件系统,提供访问控制的属性。 当拥有该属性时,当用户登录时,就可以获取所有系统的访问权限,不用对每个单一系统都逐一登录。所以...
  • 1.为什么需要单点登录 三个角度: 1.1 方便用户的使用:用户登录一次,可以使用不同的服务和页面,省了忘记密码的痛苦 1.2 简化开发:'SSO'让开发人员只要开发一个通用的身份验证框架,就不用为身份验证操心了 1.3...
  • 单点登录解决方案

    2015-10-09 10:19:43
    描述单点登录是什么,如何实现单点登录单点登录的优势等。
  • https://github.com/u014427391/jeeplatform 欢迎start(s收藏),打算集成单点登录到自己的开源项目里,所以先搭建环境 【集群简介】 使用nginx作为负载均衡,使用redis存储tomcat session,来实现集群中tomcat ...
  • 有关token实现单点登录步骤

    千次阅读 2021-01-02 21:32:59
    有关token实现单点登录步骤 服务端 1. 客户端使用username和pwd进行请求登录 2. 服务端收到请求,验证用户名和密码 3. 验证通过之后,服务端会签发一个token令牌,(存储到redis 还可以设置有效时间)再把token发送...
  • JWT单点登录的三种解决方案

    千次阅读 2020-07-16 12:46:41
    看过不少JWT和单点登录系统的文章,大部分说的比较片面。 这里就根据自己的实际开发经验谈一下我的理解。 可以总结为以下三种方案: 三种方案: 1. 纯Jwt 2. Jwt + 认证中心Redis 3. Jwt + 认证中心Redis + 多...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 714,976
精华内容 285,990
关键字:

单点登录实现方案