如何设计大型网站的用户登录系统？

web应用系统的演进总是从简单到复杂，从单一功能到多功能模块再到多个子系统。

目前，大中型Web-Internet应用基本上是由多个系统组成的应用组，协同为用户提供服务。

多系统应用组是指每个系统相对独立，并保持一定的连接。

独立性是指为用户提供相对完整的功能服务，如C2C商城、B2C商城等。接触是指从用户的角度来看，无论企业提供的服务如何多样化、系列化，在用户的角度来看，它们仍然是一个整体，用户体验不受影响。

例如，对于用户的帐户管理，用户应该有一个统一的帐户。不应允许用户在每个子系统中分别注册、登录和注销。系统的复杂性不应该由用户承担。

使用系统服务的登录用户可以看作是一个用户会话过程。在单个web应用程序中，有一个非常传统的解决方案用于用户登录、登录状态判断、用户注销和其他操作。

在一个多系统应用程序组中，这个问题变得有点复杂。这以前不是问题，但现在可能成为一个重大的技术问题。我们需要用技术手段来屏蔽底层系统本身的技术复杂性，为用户提供自然而超酷的用户体验。

这就是我们所说的单点登录（SSO）。当然，我们主要讨论的是web系统。准确地说，它应该被称为websso。

让我们看看现实中的SSO示例，比如阿里巴巴系统：

阿里旅行？前往：机票预订、酒店查询、酒店住宿、旅游度假、机票签证阿里旅游。当用户访问这些应用程序时，他们需要登录

显然，对于用户来说，他不希望每个子应用程序单独登录，因为这都是阿里巴巴的服务。在用户看来，它相当于一个大系统。

当我登录淘宝等应用程序，然后访问阿里巴巴旅游、天猫等其他系统时，我们发现系统会显示登录状态。

当您注销任何系统，然后刷新以访问其他系统时，将显示注销状态。

如您所见，阿里巴巴已经实现了SSO。事实上，几乎所有提供复杂服务的互联网公司都实现了sso，如阿里巴巴、百度、新浪、网易、腾讯、58

SSO问题是Java架构师必须掌握的技能之一，是大中型web应用程序经常遇到的问题。

单点登录的技术难点是什么？为什么我们不能像解决单个web应用程序登录那样自然地解决它呢？为了澄清这个问题，我们需要了解应用系统下用户登录的解决方案。

我们讨论的应用程序是web应用程序。众所周知，对于web应用，系统采用浏览器/服务器体系结构，浏览器与服务器之间的通信协议采用HTTP协议。

HTTP是一种无状态协议。也就是说，对于服务器，每次接收的浏览器HTTP请求都是独立的。服务器不考虑两个HTTP请求是否来自同一个会话，即HTTP协议是非连接会话状态协议。

对于web应用的登录，意味着成功登录后的后续访问可以看作是登录用户和服务器之间的会话交互过程，直到用户注销并结束会话。

如何基于无连接会话协议管理会话？我们需要更多的手段。

通常有两种方法，一种是传递HTTP请求参数，这种方法对应用程序更具侵入性，通常不使用。

Cookie是HTTP提供的一种机制。Cookie表示少量数据。设置服务器的HTTP响应后，浏览器将自动将下一个请求带回服务器。

通过这种机制，我们可以管理应用层的登录会话状态。例如，登录成功后，服务器可以创建一个登录会话，并通过cookie将会话ID返回给浏览器。浏览器下次访问浏览器时将自动带上此ID。服务器可以根据ID来判断这个会话中的请求，从而确定用户。这种操作持续到登录破坏会话为止。

令人高兴的是，我们使用的web应用服务器通常提供这种基于会话的服务，比如Tomcat的会话机制。换句话说，应用程序开发人员不需要使用cookie来实现会话创建、维护和销毁的全生命周期管理。已经提供了这些内容服务器会话，我们只需要正确使用它们。

当然，为了灵活性和效率，开发者也可以直接使用cookies来实现自己的会话管理。

对于cookies，出于安全原因，它有一个范围问题，这是由属性域和路径决定的。也就是说，如果浏览器发送的请求不在cookie的范围内，请求将不会带来cookie。

此时，解决单个系统会话问题的cookie机制不起作用。多个系统不能共享同一个会话，这就是问题所在！

事实是这样的，但在实际应用中，多域策略具有普遍性，并且存在商业上的考虑，这是我们必须面对的。

换句话说，即使可以共享cookie，服务器如何识别和处理会话？此时，我们不能直接使用服务器提供的会话机制。会话在单个应用程序范围内，共享会话需要特殊处理。

更复杂的是，这些子系统一般都可能是异构的，会话实现机制也不尽相同，比如有的是Java系统，有的是PHP系统。共享会话对原始系统是非常有害的。