前端常见登录实现方案 + 单点登录方案
几种常用的登录方案
- Cookie + Session 登录
- Token 登录
- SSO 单点登录
- OAuth 第三方登录
一、Cookie + Session 登录
在 B/S 系统中，登录功能通常都是基于 Cookie 来实现的。当用户登录成功后，一般会将登录状态记录到 Session 中。要实现服务端对客户端的登录信息进行验证都，需要在客户端保存一些信息（SessionId），并要求客户端在之后的每次请求中携带它们。一般都会将 Session 的 Id 保存到 Cookie 中，当服务端收到请求后，通过验证 Cookie 中的信息来判断用户是否登录 。
用户初次登录时：
- 用户访问
a.com/pageA，并输入密码登录。 - 服务器验证密码无误后，会创建
SessionId，并将它保存起来。 - 服务器端响应这个 HTTP 请求，并通过
Set-Cookie头信息，将SessionId写入Cookie中。
服务器端的
SessionId可能存放在很多地方，例如：内存、文件、数据库等。
第一次登录完成之后，后续的访问就可以直接使用 Cookie 进行身份验证了：
- 用户访问
a.com/pageB页面时，会自动带上第一次登录时写入的Cookie。 - 服务器端比对
Cookie中的SessionId和保存在服务器端的SessionId是否一致。 - 如果一致，则身份验证成功，访问页面；如果无效，则需要用户重新登录。
问题
虽然我们可以使用 Cookie + Session 的方式完成了登录验证，但仍然存在一些问题：
- 由于服务器端需要对接大量的客户端，也就需要存放大量的
SessionId，这样会导致服务器压力过大。 - 如果服务器端是一个集群，为了同步登录态，需要将
SessionId同步到每一台机器上，无形中增加了服务器端维护成本。 - 由于
SessionId存放在Cookie中，所以无法避免CSRF攻击。
二、Token 登录
为了解决 Cookie + Session 机制暴露出的诸多问题，我们可以使用 Token 的登录方式。
Token 是通过服务端生成的一串字符串，以作为客户端请求的一个令牌。当第一次登录后，服务器会生成一个 Token 并返回给客户端，客户端后续访问时，只需带上这个 Token 即可完成身份认证。
小结
Token 的特点：
- 服务器端不需要存放
Token，所以不会对服务器端造成压力，即使是服务器集群，也不需要增加维护成本。 Token可以存放在前端任何地方，可以不用保存在Cookie中，提升了页面的安全性。Token下发之后，只要在生效时间之内，就一直有效，但是如果服务器端想收回此Token的权限，并不容易。
有了 Token 之后，登录方式已经变得非常高效。
三、SSO 单点登录
单点登录是指在同一帐号平台下的多个应用系统中，用户只需登录一次，即可访问所有相互信任的应用系统。本质就是在多个应用系统中共享登录状态。
四、OAuth 第三方登录
总结
Cookie + Session 历史悠久，适合于简单的后端架构，需开发人员自己处理好安全问题。
Token 方案对后端压力小，适合大型分布式的后端架构，但已分发出去的 token ，如果想收回权限，就不是很方便了。
SSO 单点登录，适用于中大型企业，想要统一内部所有产品的登录方式的情况。
OAuth 第三方登录，简单易用，对用户和开发者都友好，但第三方平台很多，需要选择合适自己的第三方登录平台。
\
