vue单点登录的实现方式(vue跨域单点登录)

主要实现方式有： 1、 共享 cookies基于共享同域的 cookie 是 Web 刚开始阶段时使用的一种方式，它利用浏览同域名之间自动传递 cookies 机制，实现两个域名之间系统令牌传递问题；另外，关于跨域问题，虽然 cookies本身不跨域，但可以利用它实现跨域的 SSO 。如：代理、暴露 SSO 令牌值等。缺点：不灵活而且有不少安全隐患，已经被抛弃。2、 Broker-based( 基于经纪人 )这种技术的特点就是，有一个集中的认证和用户帐号管理的服务器。经纪人给被用于进一步请求的电子身份存取。中央数据库的使用减少了管理的代价，并为认证提供一个公共和独立的 "第三方 " 。例如 Kerberos 、 Sesame 、 IBM KryptoKnight （凭证库思想 ) 等。 Kerberos是由麻省理工大学发明的安全认证服务，已经被 UNIX 和 Windows 作为默认的安全认证服务集成进操作系统。3、 Agent-based （基于代理人）在这种解决方案中，有一个自动地为不同的应用程序认证用户身份的代理程序。这个代理程序需要设计有不同的功能。比如，它可以使用口令表或加密密钥来自动地将认证的负担从用户移开。代理人被放在服务器上面，在服务器的认证系统和客户端认证方法之间充当一个 " 翻译 "。例如 SSH 等。4、 Token-based例如 SecureID,WebID ，现在被广泛使用的口令认证，比如 FTP 、邮件服务器的登录认证，这是一种简单易用的方式，实现一个口令在多种应用当中使用。5、 基于网关6、 基于 SAML SAML(Security Assertion Markup Language ，安全断言标记语言）的出现大大简化了 SSO ，并被 OASIS 批准为 SSO 的执行标准 。开源组织 OpenSAML 实现了 SAML 规范。
单独登录 (SSO)其实就是让用户通过一次登录访问授权的网络资源。两个系统之间怎么实现单点登录并不复杂，如果是要实现的话，就需要找专业的解决方案了，比如玉符SSO单点登录解决方案。
1、 共享 cookies，这个可能不容易，其中一个需要打开后一个生成cookie页，其实是打开一个，生成两个cookie 2、找一个第三方的，打开其中一个，都是打开第三方用户名密码，

寒假学习的小课题，把之前的笔记整理整理记录一下（长文警告）因为当时看到的东西涉及很多，所以有一些地方没有深入去探讨。 百度百科：单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。简而言之就是用户在多个相互信任的应用系统中，只需要登录一次，就可以访问其他相互信任的应用系统。这里的关键是一次登录，以及一次退出，都对所有的系统生效。在普通的登录中，比如典型的B/S情景，浏览器访问服务器，发送登录请求，在发送完用户名和密码之后，服务器会生成该用户的session来标准该用户的状态，比如已登录还是已注销，并给一个cookie给浏览器，因此，用户继续访问就会带上这个cookies，服务端会根据这个Cookie找到对应的session，通过session来判断这个用户的登录状态。比如php中使用phpsessid。当然也可以自定义session的生命周期，session的生命周期过长的话一旦session被盗用就会出现用户被窃取的情况。同时，生命周期过长的session配置会占用较多的服务器资源。单点登录主要针对同平台下多应用，多系统的情景下多次登录的一种解决方案。单点登录相当于将多个应用的认证体系联通。假设现在一个平台上有3个都带有登录功能的应用，由上面的普通登录的情况可以想到，这3台服务器都会自己的记录session。那么要想达到单点登录，一个最简单的方法就出现了：共享session。共享session的方式来实现单点登录是最方便也是最直接的。在三个子系统中，使用同一个额外的记录session的服务器，比如我们可以使用一个redis服务器来存储三个系统的session。用户登录了应用1，获取了应用1返回的cookies，再次访问应用1的其他功能的候携带了cookie就是已登录的状态了，但是这样又有新的问题，虽然实现了共享session，但是用户登录了应用1，获取了应用1返回的cookie，但是因为cookie是无法跨域的，因此用户无法使用应用1的cookie去访问应用2。这里我们就需要将系统的全局cookie domain的属性设置为顶级域名，比如应用1的域名是1.test.com，应用2的域名是2.test.com。在普通登录的情况下，应用1的cookie domain的属性是1.test.com，指这个cookie只能在该子域名上被使用。我们将系统的全局cookie domain设置为顶级域名，即.test.com，这样就可以实现用户登录了应用1，之后可以以已登录状态访问应用2和3。上面的共享session的情况是三个应用都有登录功能，还有一种类似的情况是应用1和应用2都有登录模块和其他模块，还有一个单独的SSO系统，是仅有登录模块的：共享session的方法虽然简单，但是存在局限性，因为使用了cookie顶域的特性，所以不能做到跨域。一个公司或者一个平台很可能不是所有的域名都在在一个一级域名之下的，所以同域名下的单点登录并不是完整的单点登录。先说说openid，openid是一种认证标准，规定如何认证的标准！即其关注的是登录时身份的认证。官方给出的一个场景，其中一方是一个openid身份服务器，用来存放注册好的openid账号，另一方是受这个openid身份服务器信赖的服务或应用。openid协议就是提供openid身份服务器和被信赖的服务或应用之间的通信的。比如我们在很多网站上可以使用QQ登录，这里的腾讯的QQ就是openid的身份服务器，我们所要登录的网站就是受信赖的服务或应用。在使用openid实现单点登录的方法有很多，可以使用上面共享session的方法，即把openid带在cookie里面，但是这样也会出现一样的cookie跨域的问题。在实际场景中，我们在访问提供服务的应用时检测到未登录就会直接跳转到openid身份服务器，或者没有重定向而是在登录表单附近点击选择使用第三方openid登录，进行账号密码登录（这可以保证我们所登录的服务器无法获取我们的敏感身份认证信息），具体流程如下：CAS全称为Central Authentication Service即中央认证服务，是一个企业多语言单点登录的解决方案，并努力去成为一个身份验证和授权需求的综合平台。CAS就是一个现成的单点登录的demo，企业只需要简单修改就可使用。CAS支持各种协议，SAML，OAuth，OpenID，OIDC等等，支持LDAP，Radius，JWTX，509等等进行身份认证和授权，还有各种常用语言的客户端，Java，PHP，C# 等等。反正就是一个十分完整的，兼容性特别好的SSO框架。简单了解CAS是如何实现单点登录的。在官网上可以看到其给出的一个 流程图 ，。这个图说的特别详细，一下就能看懂，直接原图上进行标注查看：学习了上面几种单点登录的知识，结合实际场景可知，跨域单点登录才是真正的单点登录，因为实际情况下很多平台或者域名不可能都在一个一级域名下。在解决跨域单点登录的问题的时候，上面也给说了几种方式，但是究其根本，就是利用一个SSO认证中心来实现认证与授权的。当然，也会有其他的解决跨域单点登录的方案，但是大体流程都与cas类似。比如在上图的11步骤，也可使用POST包，或者JSONP和iframe方法来跨域发送请求进行重定向。在利用认证中心来实现单点登录是现在比较普遍的解决方案，那么有没有不需要使用认证中心来解决跨域单点登录的方案呢？利用JSONP同步登录状态，大概流程流程如下：在学习单点登录的过程中，在其中认证的过程中授权令牌的传递等相关信息没有特别详细的说明，而且在思考单点登录的时候也会有想过一个比较矛盾的问题：单点登录的目标是为了让用户可以在相互信任的系统中一次登录即可，但是如果真的是做到所有用户都可以访问所有系统，岂不是会带来越权的问题，是否需要对不同的用户以不同的授权，甚至限制访问的应用，但是这样是不是就不是原本狭义的单点认证？在说单点登录的认证和授权之前，先谈一谈我一直想弄清楚的统一身份认证和单点登录的区别。说起单点登录可能很少听过，但是统一身份认证肯定不陌生，不管是企业还是高校都会有这种统一身份认证的系统。统一身份认证最重要的一方面就是身份认证，另一方面就是和身份认证相关的授权控制，权限控制。而单点登录是多应用一次登录，也可以叫统一登录，可以理解为主要在认证方面。对于统一身份认证来说会有账号管理，如LDAP，认证管理OAuth，SMAL等，因此我觉得，统一身份认证一般是包括狭义的单点登录，狭义的单点登录，即只需要满足多应用一次登录即可。但是现在的单点登录，SSO系统并不仅仅是要求这些，他的范围正在慢慢扩大。单点登录的认证和授权，前面说到的CAS实现单点登录里就会看到需要ticket来进行认证，授权。CAS支持多种认证方案，比如OAuth，OpenID，SAML等等，我们可以来比较比较用这些协议的区别，或者说是在哪些场景下使用哪些认证方案较为合适。本身单点登录是没有权限控制的功能的，但是因为这些认证协议的需求，自然支持了权限控制。在使用SAML进行认证的过程中，可以看到下图，其是基本流程都差不多，这里需要注意的就是在用户在认证中心成功登陆之后，重定向的时候返回的是一个SAML token，一个XML节点，这里的token会包括用户的身份信息，用户名等。在OAuth2.0的标准中流程是和上面的基本相同，但是OAuth2因为客户端并没有一点是浏览器，所以token中默认是没有签名的。这里可能没有体现出来，OAuth2的目标是授权，所以token更关注的是权限，token在向认证服务器验证的时候就会有不同的授权，但是既然是授权，就间接实现了认证。在传统的认证中都是基于session机制的，具体的session模式上面也说了，根据其特性可知session的一些确定：https://www.mutuallyhuman.com/blog/choosing-an-sso-strategy-saml-vs-oauth2/https://yq.aliyun.com/articles/636281https://juejin.im/post/5d0dbb7e6fb9a07f0420512d

如果用户的平台，比较大，用户量也比较多，建议把单点登陆单独做成一个服务。如果用户量减少，用户又没有做成单独应用的资金预算，可以将单点登陆，与用户最主要的一个业务系统合并在一起，对外(就是对其他应用系统)提供登陆验证的接口程序。 单点登陆的验证，可以采用多次交互验证的方式验证，流程如下:1.应用系统将账号密码传给单点登陆服务2.单点登陆服务验证账号密码是否正确，如不正确返回错误信息;如正确，随机生成一个验证字符，返回给应用系统3.应用系统，将单点登陆返回的随机字符在发送给单点登陆的验证服务，再次验证这个随机字符是否正确 4.验证成功，则最终登陆成功。
在不同的场景下，单点登录采用不同的实现方式。应用系统是同一域名下的不同站点时，通常采用验证cookie的方式，应用系统在同一域名下但是数据不同子域时，采用cookie与sessionID相结合的方式，应用系统分属不同域时，采用站点间传递cookie和重定向的方式。玉符科技针对不同场景，单点登录方式也不同。
相对来说容易！

一般来说，有三种处理方式： 以Cookie作为凭证媒介最简单的单点登录实现方式，是使用cookie作为媒介，存放用户凭证。通过JSONP实现对于跨域问题，可以使用JSONP实现。通过页面重定向的方式最后一种介绍的方式，是通过父应用和子应用来回重定向中进行通信，实现信息的安全传递。 目前市场上主流的做单点登录的公司比如玉符科技，深耕单点登录SSO领域，可以满足客户遇到的如何实现单点登录？企业如何实现统一认证？的难题，通过玉符单点登录可以快速的帮助企业实现云认证，像SAML、OIDC、CAS、Ouath等主流协议全部支持，可以实现快速部署，交付周期短，适合各行业企业。

一般来说，有三种处理方式： 以Cookie作为凭证媒介最简单的单点登录实现方式，是使用cookie作为媒介，存放用户凭证。通过JSONP实现对于跨域问题，可以使用JSONP实现。通过页面重定向的方式最后一种介绍的方式，是通过父应用和子应用来回重定向中进行通信，实现信息的安全传递。 目前市场上主流的做单点登录的公司比如玉符科技，深耕单点登录SSO领域，可以满足客户遇到的如何实现单点登录？企业如何实现统一认证？的难题，通过玉符单点登录可以快速的帮助企业实现云认证，像SAML、OIDC、CAS、Ouath等主流协议全部支持，可以实现快速部署，交付周期短，适合各行业企业。
登陆后本地保存一个凭证，凭证包含用户认证信息。凭证可以自己随意设置。 其他相关系统在打开的时候，首先检查本地凭证，发现后，检查凭证，确认后，跳过登录界面进入系统。

web应用采用browser/server架构，http作为通信协议。http是无状态协议，浏览器的每一次请求，服务器会独立处理，不与之前或之后的请求产生关联，这个过程用下图说明，三次请求/响应对之间没有任何联系 但这也同时意味着，任何用户都能通过浏览器访问服务器资源，如果想保护服务器的某些资源，必须限制浏览器请求；要限制浏览器请求，必须鉴别浏览器请求，响应合法请求，忽略非法请求；要鉴别浏览器请求，必须清楚浏览器请求状态。既然http协议无状态，那就让服务器和浏览器共同维护一个状态吧！这就是会话机制2、会话机制 浏览器第一次请求服务器，服务器创建一个会话，并将会话的id作为响应的一部分发送给浏览器，浏览器存储会话id，并在后续第二次和第三次请求中带上会话id，服务器取得请求中的会话id就知道是不是同一个用户了，这个过程用下图说明，后续请求与第一次请求产生了关联