1. 引言
2. 基于Cookie的身份验证
长期以来，基于 Cookie 的身份验证一直是处理用户身份验证的默认且经过验证的方法。
基于 Cookie 的身份验证是有状态的。这意味着身份验证记录或会话必须同时保存在服务器端和客户端。服务器需要跟踪数据库中的活动会话，而在前端创建一个包含会话标识符的 cookie，因此名称为基于 cookie 的身份验证。我们来看看传统的基于cookie的认证流程：
- 用户输入他们的登录凭据。
- 服务器验证凭据是否正确并创建一个会话，然后将其存储在数据库中。
- 带有会话 ID 的 cookie 放置在用户浏览器中。
- 在后续请求中，会话 ID 会根据数据库进行验证，如果有效，则处理请求。
- 一旦用户退出应用程序，会话在客户端和服务器端都被销毁。
3. 基于Token令牌的身份验证
JSON Web Token 由三部分组成：标头、有效负载和签名。JWT 的格式是
header.payload.signature . 如果我们要使用 HMACSHA256 算法签署 JWT 由于单页应用程序、Web API 和物联网 (IoT) 的兴起，基于令牌的身份验证在过去几年中变得流行起来。当我们谈论使用令牌进行身份验证时，我们通常谈论使用JSON Web 令牌(JWT) 进行身份验证。虽然有不同的方式来实现令牌，但 JWT 已成为事实上的标准。考虑到这种情况，本文的其余部分将交替使用令牌和 JWT。
基于令牌的身份验证是无状态的。服务器不会记录哪些用户已登录或已发出哪些 JWT。相反，对服务器的每个请求都附带一个令牌，服务器使用该令牌来验证请求的真实性。令牌通常作为附加的 Authorization 标头以 的形式
Bearer {JWT}发送，但也可以在 POST 请求的正文中发送，甚至可以作为查询参数发送。让我们看看这个流程是如何工作的：- 用户输入他们的登录凭据。
- 服务器验证凭据是否正确并返回签名令牌。
- 此令牌存储在客户端，最常见的是本地存储 - 但也可以存储在会话存储或 cookie 中。
- 对服务器的后续请求包括此令牌作为附加的授权标头或通过上述其他方法之一。
- 服务器解码 JWT，如果令牌有效，则处理请求。
- 一旦用户注销，令牌就会在客户端被销毁，不需要与服务器交互。
4. Token的优势
1. 无状态、可扩展和解耦
使用令牌而不是 cookie 的最大优势可能是令牌身份验证是无状态的。后端不需要保留令牌记录。每个令牌都是独立的，包含检查其有效性以及通过声明传达用户信息所需的所有数据。
然后，服务器的唯一工作就是在成功的登录请求上签署令牌并验证传入的令牌是否有效。事实上，服务器甚至不需要签署令牌。Auth0 等第三方服务可以处理令牌的发行，然后服务器只需要验证令牌的有效性。
2. 跨域 CORS
Cookies 适用于单个域和子域，但在跨域管理 cookie 时，它会变得很棘手。相比之下，启用 CORS 的基于令牌的方法使得将 API 公开给不同的服务和域变得很简单。由于每次调用后端都需要和检查 JWT，只要有有效的令牌，就可以处理请求。
3. 快捷
使用基于 cookie 的身份验证时，后端必须进行查找，无论是传统的 SQL 数据库还是 NoSQL 替代方案，与解码令牌相比，往返可能需要更长的时间。此外，由于你可以在 JWT 中存储其他数据，例如用户的权限级别，因此你可以节省额外的查找调用来获取和处理请求的数据。
5. Token的缺点
令牌认证的最大缺点是 JWT 的大小。与最小的 JWT 相比，会话 cookie 也相对较小。根据你的用例，如果你向其添加许多声明，令牌的大小可能会出现问题。一般情况下，除过登录以外，对服务器的每个请求都必须包含 JWT。
6. Token的存储
通常，JWT 放置在浏览器的本地存储中，这适用于大多数用例。将 JWT 存储在本地存储中需要注意一些问题。与 cookie 不同，本地存储被沙箱化到特定域，其数据不能被包括子域在内的任何其他域访问。
你可以将令牌存储在 cookie 中，但 cookie 的最大大小仅为 4kb，因此如果令牌附加了许多声明，则可能会出现问题。此外，你可以将令牌存储在与本地存储类似的会话存储中，但会在用户关闭浏览器后立即清除。
Loading Comments...