单点登录SSO(singlesignon )简单来说就是在一个多系统共存的环境中，用户在一个位置登录，就不需要再登录其他系统了。 这意味着用户只需登录一次，即可受到所有其他系统的信任。 单点登录在大型网站上使用非常频繁。 例如，像阿里巴巴这样的网站，网站背后有成百上千个子系统，用户一次操作和交易可能涉及几十个子系统的合作。 如果每个子系统都需要用户身份验证，则不仅用户会发疯，而且每个子系统也会被这些重复身份验证许可证的逻辑打乱。 要实现单点登录，最终还需要解决如何生成和保存该信任，以及其他系统如何验证该信任的有效性。 因此，要点也有以下两个。
如果验证存储可靠性的系统达到了最初描述的效果，那么即使是单点登录，单点登录也有不同的实现方法。 下面介绍我在开发中遇到的实现方法。
以Cookie作为凭证媒介
最简单的单点登录实现方法是使用cookie作为介质并存储用户证书。
当用户登录父APP应用程序时，APP应用程序会返回加密的cookie，当用户访问子APP应用程序时，它会携带该cookie，验证APP应用程序会对cookie进行解密和验证，并在验证通过后登录当前用户
您可以看到，上述方法在客户端的cookie中存储了信任。 这个方法容易产生疑问。
Cookie不安全，无法实现跨域免登录是首要问题，加密Cookie可以保证安全性。 当然这是以源代码不泄露为前提的。 如果cookie的加密算法被泄露，攻击者可以通过伪造cookie来伪造特定的用户身份。 这很危险。
关于第二个问题，是更硬的伤口。
通过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应用验证证书，通过后登录用户。
本文转载自JC_Huang
原文链接： http://www.Jian Shu.com/p/613 e 44 d4a 464