登录验证两种方案：token和cookie以及对比

前置知识

对PIN的理解：

在账号登录和身份认证的语境中，“PIN” 通常指 个人识别码（Personal Identification Number），是一种用于验证用户身份的短数字密码（常见为4-6位）。以下是具体说明：

1. 登录认证中的作用

• 用途：代替或补充密码，用于快速验证身份（如手机解锁、银行APP登录、设备访问等）。
• 特点：
  • 比传统密码更简短，但安全性较低（需配合其他措施，如短信验证码或生物识别）。
  • 常用于高频次、低风险场景（如设备本地解锁）。

2. 常见应用场景

• 设备登录：手机/电脑的开机PIN码、智能门锁密码。
• 金融服务：银行卡取款、支付软件（如支付宝的支付密码本质是PIN）。
• 企业系统：部分内部系统要求“密码+PIN”双重验证。
• 临时访问：会议Wi-Fi、共享设备的临时PIN码。

3. 与密码的区别

*注：PIN码若仅存储在本地（如手机），暴力破解可能导致数据泄露；而密码通常经服务器加密验证。

4. 安全建议

• 避免重复使用：不要将银行卡PIN与设备密码设为相同。
• 启用多因素认证：如“PIN+指纹”或“PIN+短信验证码”。
• 定期更换：尤其用于敏感服务时（如网银）。

cookie

HTTP无状态，每次请求都要携带cookie，以帮助识别用户身份；
服务端也可以向客户端set-cookie，cookie大小限制为4kb；
cookie默认有跨域限制，不跨域共享和传递，例如：

现代浏览器开始禁止第三方JS设置cookie

和跨域限制不同，这里是指禁止网页引入的第三方JS设置cookie，例如你有一个手机性能对比的网站，用户可以在你这个网站上来参考手机的性能，只访问你的网页你是没啥收入的，如果你想获得更多的收入，那么你可以植入一些JD的广告，而广告内容可能是一个图片，代码如下：

<img src="jd.com?info='华为手机'" >。

JD广告的js虽然访问不了你的cookie，因为cookie是不跨域共享的，但是可以拿到当前网页中的内容（它一看大概是和手机内容相关的），一旦你曾经登录过JD，那么上面的代码中的请求就会携带上你的cookie信息(jd就会知道你是谁)，并顺路带上当前你访问的内容。

当有一天你访问JD时，你就会发现JD给你智能推荐你想要那款华为手机了。

因此，cookie新增了一个SameSite属性，用来防止CSRF攻击和用户追踪。

SameSite有三个值，其中Strict最为严格，完全禁止第三方 Cookie，跨站点时，任何情况下都不会发送 Cookie。换言之，只有当前网页的 URL 与请求目标一致，才会带上 Cookie。

参考链接：cookie和token的区别

cookie 和 session

cookie在客户端，用于登录验证，存储用户标识 如useId；
session在服务端，存储用户详细信息，和cookie信息一一对应；
cookie+session是常见登录验证解决方案；

为什么要有session：

1. 安全性
2. cookie体积小，存储信息有限；
3. cookie每次都会被携带，http携带信息少的话传输快；

cookie vs token

• cookie是http规范，会自动传递；而token需要开发者手动自己传递；
• cookie会被浏览器默认存储；而token需要自己存储（localstorage或sessionStorage）；
• token没有跨域限制；

cookie是官方的登录验证方案，但虽然互联网的发展，cookie暴露出很多限制，因此有了民间发起的token方式，更加灵活。

实现token的方案jwt(json web token)

1. 前端发起登录，后端验证成功后，返回一个加密的token；
2. 前端自行存储这个token（其中包括用户信息，加密了的，非对称加密）；
3. 以后访问服务端接口，都会携带这个token，作为验证信息；

token vs cookie 优缺点以及使用场景