系统登录方式汇总

大家好，欢迎来到IT知识分享网。

登录是每个网站中都经常用到的一个功能，在页面上我们输入账号密码，敲一下回车键，就登录了，但这背后的登录原理你是否清楚呢？今天我们就来介绍几种常用的登录方式。

• Cookie + Session 登录
• Token 登录
• SSO 单点登录
• OAuth 第三方登录

Cookie + Session 登录
HTTP 是一种无状态的协议，客户端每次发送请求时，首先要和服务器端建立一个连接，在请求完成后又会断开这个连接。这种方式可以节省传输时占用的连接资源，但同时也存在一个问题：每次请求都是独立的，服务器端无法判断本次请求和上一次请求是否来自同一个用户，进而也就无法判断用户的登录状态。
为了解决 HTTP 无状态的问题，Lou Montulli 在 1994 年的时候，推出了 Cookie。

Cookie 是服务器端发送给客户端的一段特殊信息，这些信息以文本的方式存放在客户端，客户端每次向服务器端发送请求时都会带上这些特殊信息。

有了 Cookie 之后，服务器端就能够获取到客户端传递过来的信息了，如果需要对信息进行验证，还需要通过 Session。

客户端请求服务端，服务端会为这次请求开辟一块内存空间，这个便是 Session 对象。

有了 Cookie 和 Session 之后，我们就可以进行登录认证了。

用户访问 a.com/pageA，并输入密码登录。服务器验证密码无误后，会创建 SessionId，并将它保存起来。服务器端响应这个 HTTP 请求，并通过 Set-Cookie 头信息，将 SessionId 写入 Cookie 中。

服务器端的 SessionId 可能存放在很多地方，例如：内存、文件、数据库等。

由于服务器端需要对接大量的客户端，也就需要存放大量的 SessionId，这样会导致服务器压力过大。如果服务器端是一个集群，为了同步登录态，需要将 SessionId 同步到每一台机器上，无形中增加了服务器端维护成本。由于 SessionId 存放在 Cookie 中，所以无法避免 CSRF 攻击。

Token 登录

为了解决 Session + Cookie 机制暴露出的诸多问题，我们可以使用 Token 的登录方式。

Token 是服务端生成的一串字符串，以作为客户端请求的一个令牌。当第一次登录后，服务器会生成一个 Token 并返回给客户端，客户端后续访问时，只需带上这个 Token 即可完成身份认证。

用户输入账号密码，并点击登录。服务器端验证账号密码无误，创建 Token。服务器端将 Token 返回给客户端，由客户端自由保存。
后续页面访问时：

用户访问 a.com/pageB 时，带上第一次登录时获取的 Token。服务器端验证 Token ，有效则身份验证成功。

服务器端不需要存放 Token，所以不会对服务器端造成压力，即使是服务器集群，也不需要增加维护成本。Token 可以存放在前端任何地方，可以不用保存在 Cookie 中，提升了页面的安全性。Token 下发之后，只要在生效时间之内，就一直有效，如果服务器端想收回此 Token 的权限，并不容易。

signature 部分为 JWT 的签名，主要为了让 JWT 不能被随意篡改，签名的方法分为两个步骤：

signature = HMAC(key, unsignedToken)

token = ${base64Header}.${base64Payload}.${base64Signature}

用户访问网站 a.com 下的 pageA 页面。由于没有登录，则会重定向到认证中心，并带上回调地址 www.sso.com?return_uri=a.com/pageA，以便登录后直接进入对应页面。用户在认证中心输入账号密码，提交登录。认证中心验证账号密码有效，然后重定向 a.com?ticket=123 带上授权码 ticket，并将认证中心 sso.com 的登录态写入 Cookie。在 a.com 服务器中，拿着 ticket 向认证中心确认，授权码 ticket 真实有效。验证成功后，服务器将登录信息写入 Cookie（此时客户端有 2 个 Cookie 分别存有 a.com 和 sso.com 的登录态）。

这个时候，由于 a.com 存在已登录的 Cookie 信息，所以服务器端直接认证成功。

清空 c.com 中的登录态 Cookie。请求认证中心 sso.com 中的退出 api。认证中心遍历下发过 ticket 的所有产品，并调用对应的退出 api，完成退出。

OAuth 第三方登录
在上文中，我们使用单点登录完成了多产品的登录态共享，但都是建立在一套统一的认证中心下，对于一些小型企业，未免太麻烦，有没有一种登录能够做到开箱即用？
其实是有的，很多大厂都会提供自己的第三方登录服务，我们一起来分析一下。

Cookie + Session 历史悠久，适合于简单的后端架构，需开发人员自己处理好安全问题。Token 方案对后端压力小，适合大型分布式的后端架构，但已分发出去的 token ，如果想收回权限，就不是很方便了。SSO 单点登录，适用于中大型企业，想要统一内部所有产品的登录方式。OAuth 第三方登录，简单易用，对用户和开发者都友好，但第三方平台很多，需要选择合适自己的第三方登录平台。