场景描述
登录是几乎每个网站都有的一个基本功能，本文介绍几种常用的登录方式和背后的原理：
- Cookie + Session 登录
- Token 登录
- SSO 单点登录
- OAuth 第三方登录
Cookie + Session 登录
HTTP 是一种无状态的协议，客户端每次发送请求时，首先要和服务器端建立一个连接，在请求完成后又会断开这个连接。
这种方式可以节省传输时占用的连接资源，但同时也存在一个问题：每次请求都是独立的，服务器端无法判断本次请求和上一次请求是否来自同一个用户，进而也就无法判断用户的登录状态。
为了解决 HTTP 无状态的问题，就有了 Cookie。
Cookie 是服务器端发送给客户端的一段特殊信息，这些信息以文本的方式存放在客户端，客户端每次向服务器端发送请求时都会带上这些特殊信息。
有了 Cookie 之后，服务器端就能够获取到客户端传递过来的信息了，如果需要对信息进行验证，还需要通过 Session。
客户端请求服务端，服务端会为这次请求开辟一块内存空间，这个便是 Session 对象。
有了 Cookie 和 Session 之后，我们就可以进行登录认证了。
实现流程
Cookie + Session 的登录方式是最传统的一种登录方式，现在仍然有大量的企业在使用。
用户首次登录时：
- 用户访问 a.com/page-a，并输入密码登录。
- 服务器验证密码无误后，会创建 SessionId，并将它保存起来。
- 服务器端响应这个 HTTP 请求，并通过 Set-Cookie 头信息，将 SessionId 写入 Cookie 中。
服务器端的 SessionId 可能存放在很多地方，例如：内存、文件、数据库等。
第一次登录完成之后，后续的访问就可以直接使用 Cookie 进行身份验证了：
- 用户访问 a.com/page-b 页面时，会自动带上第一次登录时写入的 Cookie。
- 服务器端比对 Cookie 中的 SessionId 和保存在服务器端的 SessionId 是否一致。
- 如果一致，则身份验证成功。
存在的问题
虽然使用 Cookie + Session 的方式可以完成登录验证，但仍然存在一些问题：
- 由于服务器端需要对接大量的客户端，也就需要存放大量的 SessionId，这样会导致服务器压力过大。
- 如果服务器端是一个集群，为了同步登录态，需要将 SessionId 同步到每一台机器上，无形中增加了服务器端维护成本。
- 由于 SessionId 存放在 Cookie 中，所以无法避免 CSRF 攻击。
关于跨域问题
若有收获，就点个赞吧
0 人点赞
