北京艾锑无限告诉您：单点登陆原理及实现

 

迎战疫情,艾锑无限用爱与您同行

  

为中国中小企业提供免费IT外包服务

 

 

 

这次的肺炎疫情对中国的中小企业将会是沉重的打击，据钉钉和微信两个办公平台数据统计现有2亿左右的人在家远程办公，那么对于中小企业的员工来说不懂IT技术将会让他们面临的最大挑战和困难。

 

电脑不亮了怎么办？系统蓝屏如何处理？办公室的电脑在家如何连接？网络应该如何设置？VPN如何搭建？数据如何对接？服务器如何登录？数据安全如何保证？数据如何存储？视频会议如何搭建？业务系统如何开启等等一系列的问题，都会困扰着并非技术出身的您。

 

 

、

    

 

好消息是当您看到这篇文章的时候，就不用再为上述的问题而苦恼，您只需拨打艾锑无限的全国免费热线电话:400 650 7820，就会有我们的远程工程师为您解决遇到的问题，他们可以远程帮您处理遇到的一些IT技术难题。

如遇到免费热线占线，您还可以拨打我们的24小时值班经理电话:15601064618或技术经理的电话:13041036957，我们会在第一时间接听您的来电，为您提供适合的解决方案，让您无论在家还是在企业都能无忧办公。 

那艾锑无限具体能为您的企业提供哪些服务呢？

 

 

艾锑无限始创于2005年，历经15年服务了5000多家中小企业并保障了几十万台设备的正常运转，积累了丰富的企业IT紧急问题和特殊故障的解决经验，制定了相对应的解决方案。我们为您的企业提供的IT服务分为三大版块:

 

第一版块是保障性IT外包服务:如电脑设备运维，办公设备运维，网络设备运维，服务器运维等综合性企业IT设备运维服务。 

第二版块是功能性互联网外包服务:如网站开发外包，小程序开发外包，APP开发外包，电商平台开发外包，业务系统的开发外包和后期的运维外包服务。 

第三版块是增值性云服务外包:如企业邮箱上云，企业网站上云，企业存储上云，企业APP小程序上云，企业业务系统上云，阿里云产品等后续的云运维外包服务。 

您要了解更多服务也可以登录艾锑无限的官网:www.bjitwx.com查看详细说明，在疫情期间，您企业遇到的任何困境只要找到艾锑无限，能免费为您提供服务的我们绝不收一分钱，我们全体艾锑人承诺此活动直到中国疫情结束,我们将这次活动称为——春雷行动。

  

以下还有我们为您提供的一些技术资讯，以便可以帮助您更好的了解相关的IT知识，帮您渡过疫情中办公遇到的困难和挑战，艾锑无限愿和中国中小企业一起共进退，因为我们相信万物同体，能量合一，只要我们一起齐心协力，一定会成功。再一次祝福您和您的企业，战

胜疫情，您和您的企业一定行。

 

北京艾锑无限告诉您：单点登陆原理及实现 

单点登录（Single Sign On），简称为 SSO，是比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

很早期的公司，一家公司可能只有一个Server，慢慢的Server开始变多了。每个Server都要进行注册登录，退出的时候又要一个个退出。用户体验很不好！你可以想象一下，上豆瓣 要登录豆瓣FM、豆瓣读书、豆瓣电影、豆瓣日记......真的会让人崩溃的。我们想要另一种登录体验：一家企业下的服务只要一次注册，登

录的时候只要一次登录，退出的时候只要一次退出。怎么做？

一次注册。 一次注册不难，想一下是不是只要Server之间同步用户信息就行了？可以，但这样描述不太完整，后续讲用户注册的时候详细说。实际上用户信息的管理才是SSO真正的难点，只是作为初学者，我们的难点在于实现SSO的技术！我们先讨论实现手段。

一次登录与一次退出。 回头看看普通商场的故事，什么东西才是保持登录状态关键的东西？记录器（session）？那种叫做cookie的纸张？写在纸张上的ID? 是session里面记录的信息跟那个ID，cookie不只是记录ID的工具而已。客户端持有ID，服务端持有session，两者一起用来保持登录状态。客户端需要用ID来作

为凭证，而服务端需要用session来验证ID的有效性（ID可能过期、可能根本就是伪造的找不到对应的信息、ID下对应的客户端还没有进行登录验证等）。但是session这东西一开始是每个server自己独有的，豆瓣FM有自己的session、豆瓣读书有自己的session，而记录ID的cookie又是不能跨域的。所以，我们要实现

一次登录一次退出，只需要想办法让各个server的共用一个session的信息，让客户端在各个域名下都能持有这个ID就好了。再进一步讲，只要各个server拿到同一个ID，都能有办法检验出ID的有效性、并且能得到ID对应的用户信息就行了，也就是能检验ID

 

最简单的单点登录实现方式，是使用cookie作为媒介，存放用户凭证。

用户登录父应用之后，应用返回一个加密的cookie，当用户访问子应用的时候，携带上这个cookie，授权应用解密cookie并进行校验，校验通过则登录当前用户。

不难发现以上方式把信任存储在客户端的Cookie中，这种方式很容易令人质疑：

Cookie不安全

不能跨域实现免登

对于第一个问题，通过加密Cookie可以保证安全性，当然这是在源代码不泄露的前提下。如果Cookie的加密算法泄露，攻击者通过伪造Cookie则可以伪造特定用户身份，这是很危险的。

对于第二个问题，更是硬伤。

对于跨域问题，可以使用JSONP实现。 

用户在父应用中登录后，跟Session匹配的Cookie会存到客户端中，当用户需要登录子应用的时候，授权应用访问父应用提供的JSONP接口，并在请求中带上父应用域名下的Cookie，父应用接收到请求，验证用户的登录状态，返回加密的信息，子应用通过解析返回来的加密信息来验证用户，如果通过验证则登录用户。

 

 

这种方式虽然能解决跨域问题，但是安全性其实跟把信任存储到Cookie是差不多的。如果一旦加密算法泄露了，攻击者可以在本地建立一个实现了登录接口的假冒父应用，通过绑定Host来把子应用发起的请求指向本地的假冒父应用，并作出回应。 

因为攻击者完全可以按照加密算法来伪造响应请求，子应用接收到这个响应之后一样可以通过验证，并且登录特定用户。

最后一种介绍的方式，是通过父应用和子应用来回重定向中进行通信，实现信息的安全传递。 

父应用提供一个GET方式的登录接口，用户通过子应用重定向连接的方式访问这个接口，如果用户还没有登录，则返回一个的登录页面，用户输入账号密码进行登录。如果用户已经登录了，则生成加密的Token，并且重定向到子应用提供的验证Token的接口，通过解密和校验之后，子应用登录当前用户。

 

 

这种方式较前面两种方式，接解决了上面两种方法暴露出来的安全性问题和跨域的问题，但是并没有前面两种方式方便。 

安全与方便，本来就是一对矛盾。

使用独立登录系统 

一般说来，大型应用会把授权的逻辑与用户信息的相关逻辑独立成一个应用，称为用户中心。 

用户中心不处理业务逻辑，只是处理用户信息的管理以及授权给第三方应用。第三方应用需要登录的时候，则把用户的登录请求转发给用户中心进行处理，用户处理完毕返回凭证，第三方应用验证凭证，通过后就登录用户。