登录鉴权Authentication
数据与账号确认用户是谁，并维持登录状态
登录鉴权通过密码、验证码或第三方账号确认身份，再用 Cookie、Session 或 Token 记住登录状态。密码不能明文保存；登录成功后，还要由权限控制 Authorization判断用户能做什么。
账号证明 → 验证身份 → 登录态
你是谁？Authentication什么时候用
- 优先采用成熟身份服务或框架方案，不自己发明密码系统成熟方案已经处理关键细节密码 / 验证码→身份服务→安全会话
- 为登录 Cookie 设置合适的 HttpOnly、Secure 和 SameSite登录 Cookie 的常见保护HttpOnly脚本不可读Secure只走 HTTPSSameSite限制跨站携带
- 登录失败使用模糊提示，避免泄露账号是否存在失败提示不泄露账号状态不推荐该邮箱不存在 → 推荐账号或密码错误
- 退出登录时让服务端会话或令牌真正失效退出要让凭证真正失效会话有效→服务端撤销→再次请求 401
什么时候不用
- 数据库明文保存密码：数据泄露会直接暴露用户账号密码不能明文入库email: oil@example.compassword: 123456数据库泄露后，所有密码会直接暴露
- 把 JWT 当加密保险箱：内容通常只是编码，仍可能被读到JWT 内容通常可以解码查看header.payload.signaturepayload: { "email": "oil@example.com" }不要在里面放密码、令牌等敏感信息
- 只在前端 localStorage 里写 isLoggedIn=true改本地变量不能证明身份控制台修改isLoggedIn = true → 服务端检查没有有效会话 · 401
- 登录接口没有限速：容易被批量猜密码没有限速的登录接口1 分钟10,000 次尝试结果可持续猜密码
组成结构 · Anatomy
身份凭证→服务端验证→登录状态
1身份凭证Credential密码、一次性验证码或第三方平台返回的身份结果
2验证Verification服务端核对凭证、限速并处理失败，不相信前端自己宣布登录成功
3登录状态Session用安全 Cookie 或受保护 Token 让后续请求能证明是同一位用户
常见变体 · Variants
Cookie SessionCookie Session
Set-Cookie: session=...传统网站常见，浏览器自动携带 Cookie
TokenBearer Token
Authorization: Bearer ...移动端或独立 API 常见
第三方登录OAuth Login
Continue with GitHub
把身份验证交给成熟平台
典型使用场景
邮箱密码登录
邮箱密码验证成功后建立登录状态
登录
Session✓ 已建立
短信或邮箱验证码
一次性验证码验证码只在短时间内有效
剩余时间04:32尝试次数1 / 5
验证使用 GitHub / Google 登录
第三方登录把身份验证交给成熟平台
使用 GitHub 继续使用 Google 继续
平台返回身份结果，本站再建立自己的会话
退出与登录过期
退出与过期会话失效后不能继续访问
点击退出→服务端撤销 Session→再次访问 → 401