PHP中SSO Cookie登录分析与实现

什么是SSO？

单点登录是身份管理的一部分。一种流行的SSO定义是：SSO是指同一用户访问同一服务器不同应用中的受保护资源，只需登录一次，即在一个应用中通过安全验证后访问其他应用中的受保护资源时，无需再次登录验证。

单点登录的用途：

在目前的企业应用环境中，往往有很多应用系统，比如淘宝、天猫、爱淘宝等。以及办公自动化(OA)系统、财务管理系统、档案管理系统、信息查询系统等。这些应用系统服务于企业信息化建设，为企业带来了良好的效益。但是，用户使用这些应用系统并不方便。每次用户使用系统时，必须输入用户名和密码进行身份验证。而且，应用系统不同，用户账号也不同，用户必须同时记住多组用户名和密码。尤其是对于应用系统多、用户多的企业来说，这个问题尤为突出。问题的原因不是系统开发的失误，而是缺乏统筹规划和统一的用户登录平台。单点登录技术可以解决这些问题。

单点登录的优势：

用户友好：从用户实际使用的角度出发。

用户使用应用系统时，可以一次登录，多次使用。用户不再需要每次都输入用户名和密码，也不需要记住多组用户名和密码。单点登录平台可以提高用户使用应用系统的体验。方便管理员：从日常维护管理的角度。

如今，许多大型互联网公司都有许多应用程序。比如下面是淘宝的截图。

天猫巨化头条等都是不同的应用，有的甚至使用完全不同的域名，但所有在淘宝注册的用户都使用一套用户名和密码。如果这些系统不能直接切换同步登录状态，体验很差。比如很多公司的内部系统很多，比如人力资源系统、财务系统、考勤系统等。如果员工登录一个系统，跳转到另一个系统时需要登录，会让人很不开心。

因此，单点登录应运而生。当然，实现这个需求的方法有很多，其中Cookie是比较简单的一种。要解决的主要问题是：Cookie不能跨域传输。如何通知一个域(不在同一个域)内的其他应用Cookies？

所以，如果你不熟悉cookie机制，请先谷歌一下，大致了解一下为什么cookie被设计成不能跨域。

系统管理员只需要维护一套统一的用户账号，方便简单。相比之下，系统管理员过去管理多组用户帐户。每个应用系统都有一套用户账号，不仅给管理带来不便，还容易出现管理漏洞。

简化应用系统开发：从应用扩展的角度。

在开发新的应用系统时，可以直接使用单点登录平台的用户认证服务，简化开发过程。单点登录平台通过提供统一的认证平台，实现单点登录。因此，应用系统不需要开发用户认证程序。如何实现？

单点登录可以通过以下方式实现。

共享Cookie。

当我们的子系统都在一个父域名下时，我们可以在父域下种植cookies，这样浏览器和域名下的cookies就可以共享，这样就可以通过Cookie加解密算法获得用户SessionID，从而实现SSO。

但是后来我们发现这种方法有几个缺点：a .所有域名相同的系统都可以获得SessionID，容易被修改，不安全；b .跨域不可用。

验票，这是我们现在采取的方式。

此单点登录有以下步骤：

A.如果用户访问某个子系统，发现自己没有登录，会被引导跳转到SSO登录页面；b、判断SSO是否已经登录；c .如果已经登录，直接跳转到回拨地址，返回认证票；d、如果未登录，用户正确输入用户名/密码，通过认证后跳转到回拨地址，返回认证票；e .子系统获取票证，调用SSO获取用户uid等信息，成功后让用户登录。

前面说过，如何通过Cookie实现SSO，主要是如何解决跨域的问题。我们先来说说Set-Cookie中的域属性。

Cookie域

为了在一定程度上保持Http协议的上下文，服务器可以在响应的头部添加Set-Cookie，向客户端写入一些数据。

域字段用于指示此cookie所在的域。

栗子：

当我们访问www.cookieexm.com时，如果服务器在返回头中添加了Set-cookie，如果没有指定域，那么这个Cookie的域默认为www.cookieexm.com，也就是说，客户端只有在访问www.cookieexm.com时才会将这个Cookie返回给服务器。如果我们将域指定为。cookieexm.com，客户端可以在访问以下域名时返回cookie。cookieexm.com、a.cookieexm.com、www1.cookieexm.com、www.cookieexm.com。

因此，我们得出一个结论：客户端从一开始就匹配cookie的域。有了这个基础，我们就可以实现我们的单点登录了。

饼干中需要注意的事情。

设置为仅http。

登录凭证(如账单或用户名)应该加密。

Cookie无法存储私有数据。

具体计划

假设我们需要在以下子系统中实现单点登录* * * . a1 . a2 * * . B1 . B2 * * . C1 . C2 * . C1 . C2，首先我们需要一个专门用于单点登录的认证系统(sso.s1.s2)。假设系统目前没有登录，以访问www.a1.a2为例：

分别查看每个步骤功能：

请求www.a1.a2

Www.a1.a2接收请求并检查它是否携带用于登录的cookie。如果目前还没有登录，会重定向到sso认证中心提供的登录窗口，用户输入用户名和密码。单点登录系统验证用户名和密码。

这一步是关键。如果登录成功，首先将单点登录系统的Cookie放在客户端。同时，用户的认证信息通过重定向传输到业务端。请注意，这种传输显然不能通过cookie(不同的域)传输，而是通常通过加密的querystring传输。

业务端的认证系统接收到sso认证信息，在业务端认证通过后，将认证结果的cookie写入a1.a2，此时SSO认证重定向到业务系统wwwa1.a2，从前面的结论来看，此时以. a1.a2结尾的所有业务系统都可以使用这个经过认证的cookie。

反应

说明：业务认证系统不一定存在，一些不太敏感的系统可以直接从SSO Authorization重定向到业务系统，并自带SSO认证信息。

为了继续上述操作，此时，如果用户访问www.b1.b2应用程序，如下图所示：

与访问www.a1.a2不同的是，重定向到SSO Authorization时，我们不需要输入用户名，因为此时sso.s1.s2已经有了cookie，这是通过cookie直接验证的。

上面是一个简单的基于cookie的登录系统。

有几个问题需要着重解决。

如何高效存储大量临时可信数据，如何防止信息传输过程被篡改，如何让SSO系统信任登录系统和免登录系统。对于第一个问题，一般可以采用类似memcached的分布式缓存方案，不仅可以提供扩展数据量的机制，还可以提供高效的访问。

对于第二个问题，一般采用数字签名，要么采用数字证书签名，要么采用md5这样的手段，要求SSO系统在返回免登录URL时，用md5对需要验证的参数进行加密，用token返回。最后，免登录系统在验证信任关系时，需要将这个令牌传递给SSO系统，SSO系统可以通过验证令牌来识别信息是否发生了变化。

对于最后一个问题，我们可以通过白名单来处理。简单来说，只有白名单上的系统可以请求生产信任关系，同样，只有白名单上的系统可以免登录。