简单来说，单点登录(SSO )是一个多系统共存的环境，用户只需在一个位置登录，就无需登录其他系统。 这意味着用户的一次登录将受到所有其他系统的信任。 单点登录在大型网站上使用非常频繁。 例如，像阿里巴巴这样的网站，网站背后有成百上千个子系统，用户一次操作和交易可能涉及数十个子系统的协作。 如果每个子系统都需要用户验证，不仅会打乱用户，而且每个子系统也会打乱这种重复验证许可证的逻辑。 要实现单点登录，最终需要解决如何生成和存储该信任，以及其他系统如何验证该信任的有效性。 因此，要点也有以下两个。
在本文中，如果验证存储可靠性的系统达到了最初描述的效果，则即使是单点登录，单点登录也有不同的实现方法。 这里介绍一下我在开发中遇到的实现方法。
以Cookie为证书介质的最简单的单点登录的实现方式是以Cookie为介质，存储用户证书。 当用户登录父APP应用程序时，APP应用程序会返回加密的cookie，当用户访问子APP应用程序时，会携带该cookie，验证APP应用程序会解密并验证cookie，如果验证成功，则会登录当前用户
可以看到，上述方法将信任保存在客户端的cookie中。 这个方法容易产生疑问。
针对首要问题是Cookie不安全，不能实现域间的免登录，通过加密Cookie可以保证安全性。 当然这是以源代码不泄露为前提的。 如果cookie的加密算法被泄露，攻击者可以通过伪造cookie来伪造特定的用户id。 这很危险。 关于第二个问题，是更硬的伤口。
使用JSONP实现，可以针对域间问题使用JSONP实现。 当用户登录父APP应用程序时，如果客户端存储了与Session匹配的cookie，并且用户需要登录子APP应用程序，则授权的APP应用程序将访问父APP应用程序提供的JSONP接口，并在请求中APP父父APP应用程序收到请求，验证用户的登录状态，返回加密信息，子APP应用程序解析返回的加密信息，对用户进行认证，认证成功后登录用户。
这种方法可以解决域间的问题，但安全性实际上等同于在cookie中存储信任。 如果泄露了加密算法，攻击者可以构建在本地实现登录接口的假父APP应用程序，并通过绑定Host从子APP应用程序向本地假父APP应用程序响应请求。 由于攻击者可以根据加密算法完全伪造响应请求，因此子APP应用在接收到该响应后也同样能够通过认证并登录到特定用户。
页面重定向方式最后介绍的方式是父APP应用和子APP应用在重定向中进行通信，从而实现信息的安全传递的方式。 父APP应用程序提供GET登录界面，用户通过子APP应用程序重定向连接方式访问此界面，如果用户尚未登录，则返回的登录页面，用户输入帐户密码如果使用者已登入，则会产生加密的Token，并将其重新导向至验证子APP应用程式提供的Token的介面。 经过解密和验证，子APP应用程序将登录到当前用户。
这种方式比前两种方式解决了前两种方法中发现的安全问题和域间问题，但不如前两种方式方便。 安全和便利，本来就矛盾。
使用独立登录系统，在大型APP应用程序中，有关授权逻辑和用户信息的逻辑独立于单个APP应用程序(称为用户中心)。 用户中心不处理业务逻辑，只处理用户信息管理和对第三方APP应用程序的批准。 如果第三方APP应用需要登录，则将用户的登录请求转发给用户中心进行处理，用户处理后返回证书，第三方APP应用验证证书，通过后登录用户。