为什么还要服务器验证登录？

这是一个非常好的问题！它触及了现代应用安全的核心。服务器验证是确保“你是谁”这个问题的唯一可信来源，是安全防线的基石。

即使前端（App、网页）已经做了各种验证，最终的登录验证也必须在服务器端完成，下面我从几个关键角度来详细解释为什么。

客户端的一切都“不可信”

这是最根本的原则，任何运行在用户设备上的代码（JavaScript、App代码）都是透明的、可被篡改和绕过的。

前端验证可以被绕过你在网页上看到的“密码强度提示”、“邮箱格式验证”等，都是用JavaScript实现的，一个懂技术的用户可以通过浏览器开发者工具禁用JavaScript，或者直接修改前端代码，轻松绕过这些检查，他甚至可以伪造一个根本不发送密码的登录请求。

客户端逻辑是公开的App可以被反编译，网页代码是公开的，如果你把核心的验证逻辑（比如对比密码）放在客户端，攻击者就能轻易分析出你的验证机制，从而找到漏洞。

敏感数据会暴露如果验证在客户端完成，意味着正确的用户名和密码（或其哈希值）很可能需要存储在或传递到客户端，这无异于将保险箱的钥匙放在大门外。

服务器是唯一可以存放和保护核心秘密（如用户密码的哈希值、加密密钥）的地方。

防止数据篡改和伪造

假设登录过程是这样的：

1、 用户在客户端输入用户名 和密码。

2、 客户端直接判断是否正确，如果正确，就生成一个“已登录”的状态。

一个攻击者可以：

直接修改本地存储将isLoggedIn: false 改为isLoggedIn: true。

伪造网络请求不经过你的登录页面，直接用工具伪造一个“登录成功”的数据包发给自己的客户端。

服务器验证是如何解决这个问题的？

1、 客户端将用户名和密码安全地（通过HTTPS）发送给服务器。

2、 服务器在自己安全的数据库中比对密码哈希值。

3、 如果正确，服务器会生成一个唯一的、有时效性的令牌（Token），例如JWT（JSON Web Token）或Session ID，并将其返回给客户端。

4、 客户端后续的每一次请求，都必须带上这个Token。

这样一来，客户端的登录状态完全由服务器颁发的Token决定，客户端无法自己制造一个有效的Token，因为它没有服务器的密钥，服务器在收到每个带Token的请求时，都会验证其真实性和有效性。

实现集中式的安全和权限控制

服务器是所有用户请求的汇聚点，是实施统一安全策略的最佳位置。

防止暴力破解服务器可以轻松监控某个IP地址或账号在短时间内的登录失败次数，并触发验证码、锁定账户等防护措施，如果在客户端做，攻击者可以轻易重置客户端状态来绕过限制。

权限管理用户能看哪些数据？能执行哪些操作？这些权限（Role & Permission）信息必须由服务器来校验，即使你把一个“删除用户”的按钮隐藏了，懂技术的用户还是可以直接发一个“删除用户”的API请求，只有服务器端的权限验证才能最终阻止他。

实时吊销如果用户修改了密码，或者管理员封禁了一个用户，服务器可以立即让该用户的所有Token失效，如果验证在客户端，你将无法强制一个已经“登录”的设备退出。

状态管理和一致性

HTTP协议本身是无状态的，服务器需要一种方式来识别连续请求来自同一个已登录的用户。

Session（会话）服务器在内存或数据库中创建一个Session，存储用户的登录信息，并将唯一的Session ID通过Cookie返回给浏览器，浏览器后续请求会自动带上这个Cookie，服务器通过查找Session ID来识别用户。

Token（令牌）服务器生成一个包含用户信息和签名的Token（如JWT），客户端将其存储在本地，并在请求头中携带，服务器只需验证Token的签名即可识别用户。

这两种方式的核心都是：登录状态的“真伪”由服务器说了算。

一个生动的比喻

可以把登录过程比作进入一个高级俱乐部：

客户端验证就像门口的服务生看一眼你的穿着是否得体（格式检查），这很重要，能提升体验，但无法证明你的身份。

服务器验证就像前台用你的身份证（用户名）在会员数据库（服务器数据库）里进行核对，确认你是会员后，给你一个独一无二、有时效的手环（Token）。

进入俱乐部后的每个区域（访问每个API），保安（服务器中间件）都会检查你的手环（验证Token）是否有效，并确认你的手环权限是否能进入该区域（权限校验）。

你可以自己画一个假手环（客户端篡改），但绝对骗不过保安的系统（服务器验证）。

前端验证主要用于提升用户体验（即时反馈、减少无效请求），而后端验证则用于保障安全、数据和业务逻辑的真实可靠。 两者是互补关系，但服务器验证是绝对不可省略的最后一道，也是最关键的一道防线。

文章摘自：https://idc.huochengrm.cn/js/19611.html