登录、会话与权限
认证确认访问者是谁，授权判断这个人能做什么。登录成功后，后端仍需对每一次受保护操作检查身份与资源归属。
- 为任务接口画出登录、会话和权限检查流程，并验证用户不能读取或修改他人的任务。
- 密码哈希、会话、Cookie 和令牌
- 检查登录、会话与权限后，应当为任务接口画出登录、会话和权限检查流程，并验证用户不能读取或修改他人的任务，并保留权限响应、测试报告、证书状态、告警和恢复记录作为可重复检查的依据。
- 完成 6.4「Redis 与缓存：什么时候才需要」
FOUNDATION
必须理解
认证确认“你是谁”，会话让后续请求记住身份，授权决定“你能做什么”。登录页只是入口，确实安全边界必须在每一次服务端数据操作中执行。
本课依次讲清密码哈希、会话、Cookie 和令牌、角色、资源所有权和最小权限和登录、退出、过期和找回流程，最后通过“用两个测试账户尝试访问彼此任务并确认被拒绝”检查学习结果。
进入办公楼先用证件确认身份，这是认证；领取临时门卡维持会话；不同楼层门禁决定授权。看到某扇门不代表有权打开。
用户登录后获得安全会话；查询、更新或删除任务时，服务端都用会话中的 userId 限制 ownerId，绝不相信前端传来的“这是我的任务”。
密码哈希、会话、Cookie 和令牌
认证是在确认“你到底是谁”，可以用密码、第三方账号或登录链接完成。密码不能明文保存，也别自己发明加密方法，成熟认证库已经处理了大量容易踩坑的细节。
基础概念
认证确认访问者是谁，会话让后续请求持续关联这个身份。密码应经过专用密码哈希算法处理，Cookie 或令牌只承载会话凭证，不应直接保存明文密码。
进一步理解
注册时保存带盐密码哈希；登录时用同一算法验证。成功后服务端建立会话，浏览器通过安全 Cookie 在后续请求中携带会话标识。
HttpOnly 限制脚本读取 Cookie，Secure 要求 HTTPS 传输，SameSite 降低部分跨站请求风险。它们各防一类问题，不能互相替代。
用户登录任务应用后获得会话 Cookie；每次读取任务，服务端从会话取得 userId，而不是要求前端重复发送密码。
哈希不是可逆加密，会话令牌也不等于用户身份本身；服务器仍需验证令牌有效、未过期且未撤销。
这一小节记住：密码只用于证明身份，会话用受控凭证延续身份。
角色、资源所有权和最小权限
用户登录一次后，网站需要在后续请求中认出他，这就是会话。安全 Cookie 常用来携带会话信息，HttpOnly、Secure 和 SameSite 分别挡住一部分常见风险。
基础概念
授权决定已认证身份可以执行哪些操作。角色描述一类权限，资源所有权限制具体记录，最小权限原则只授予完成当前任务所需能力。
进一步理解
管理员角色可以管理全局配置，普通用户只能操作自己的任务。即使两人调用同一路由，查询条件和业务规则也必须根据身份缩小范围。
权限检查应发生在服务端每个敏感操作上，并尽量靠近数据访问。隐藏按钮只能改善界面，无法阻止自制 HTTP 请求。
更新任务时查询条件同时包含 taskId 与会话 userId；普通用户即使猜到他人 id，也更新不到记录。
认证成功不代表拥有所有权限，角色也不能替代资源归属；“已登录”只解决你是谁，没有回答你能操作哪条数据。
这一小节记住：每次敏感操作都用服务端身份回答：这个人能否对这条资源做这件事？
登录、退出、过期和找回流程
授权回答的是“这个人能不能做这件事”。按钮藏起来只影响页面，实际的判断必须在服务端做，因为别人完全可以绕过页面直接请求 API。
基础概念
完整身份流程包括登录、退出、会话过期和账户找回。每条路径都在改变谁能继续使用账户，因此必须设计安全反馈、撤销和异常状态。
进一步理解
退出应让当前会话失效；过期后引导重新认证并尽量保存未提交工作；找回流程使用短期、一次性令牌并避免泄露账户是否存在。
修改密码、发现异常或管理员封禁时，可能需要撤销其他会话。重要操作可要求近期重新认证，而不是无限信任旧会话。
用户找回密码后，重置链接立即失效，旧会话按策略撤销；返回登录页时不暴露该邮箱是否注册。
“记住我”不是永不过期；延长会话会增加被盗后的风险，需要设备管理、撤销与重新认证配合。
这一小节记住：身份系统要覆盖进入、持续、离开和恢复，而不只是一个登录表单。
AI COLLABORATION
AI 如何参与
在登录、会话与权限这一课，AI 负责根据真实材料解释密码哈希、会话、Cookie 和令牌并指出遗漏，学习者负责控制范围、执行修改和核对权限响应、测试报告、证书状态、告警和恢复记录。
推荐协作顺序
- 1
先让 AI 画出登录、会话和授权三段流程，不生成加密算法。
- 2
选择成熟认证库后，只参考当前版本的官方接入方式。
- 3
用两个测试账户让 AI 帮你设计越权用例，再亲自验证服务端结果。
这是登录方式、任务模型和接口列表。请分别标出认证、会话读取、授权和资源归属检查。不要自创加密方案，不索取密码、令牌或会话秘密。为越权访问设计测试。
服务端从可信会话取得 userId，每次数据查询都带 ownerId；错误区分未登录与无权限，但不泄露其他用户资源是否存在；登录、会话与权限的人工验收必须回到真实页面、请求、终端、测试或数据结果，不能用 AI 的文字说明代替。
人工检查清单
- 确认密码不进入日志或客户端包，Cookie 属性安全，授权不是只在前端执行。
- 要求 AI 为每个读写接口标出身份来源、授权规则和越权测试。
- 用匿名、普通用户、资源所有者和管理员四种身份实际请求，确认服务端结果而非按钮可见性。
COMMON TRAPS
常见误区
下面三类问题会让任务看似完成，却经不起刷新、错误输入或真实环境检查。先看现象，再找原因和修正方法。
只在前端判断权限
- 你会看到
- 直接调用接口即可绕过限制
- 为什么发生
- 前端限制可以被绕过，实际的数据访问发生在服务端接口。
- 怎样纠正
- 每个受保护接口在服务端检查
只检查是否登录
- 你会看到
- 登录用户可以枚举他人任务
- 为什么发生
- 身份只说明用户是谁，不能证明他有权读取当前这条资源。
- 怎样纠正
- 同时检查资源归属
把令牌写进日志
- 你会看到
- 排查输出泄露可用凭据
- 为什么发生
- 日志会被集中保存和多人访问，一条完整令牌可能在有效期内被重放。
- 怎样纠正
- 记录请求标识，不记录完整凭据
HANDS-ON
动手任务
为任务接口画出登录、会话和权限检查流程，并验证用户不能读取或修改他人的任务。
- 完成 6.4「Redis 与缓存：什么时候才需要」
跟着做
- 01
画出认证、会话、授权三者关系。
- 02
选择适配 Next.js 的成熟认证方案并阅读官方指南。
- 03
实现登录和退出，检查 Cookie 的安全属性。
- 04
把任务查询改为按当前 userId 过滤。
- 05
用两个测试账户尝试访问彼此任务并确认被拒绝。
为任务接口画出登录、会话和权限检查流程，并验证用户不能读取或修改他人的任务。
设计“忘记密码”流程，标出令牌有效期、一次性使用和避免暴露账户存在性的要求。
离开本课前，自问四件事
- 认证、会话与授权分别回答什么问题？
- 密码哈希、Cookie 属性和会话撤销各自防什么风险？
- 为什么隐藏管理按钮不能作为权限控制？
- 登录、退出、过期和找回流程分别需要哪些服务端保证？
确认完成后，会同步更新学习中心的课程学习进度。