认证机制攻击：别只盯着登录框，要检查系统究竟在什么时候相信了谁
上一课讲了渗透测试的方法论：先确认边界，再观察系统，提出能够被证伪的假设，用最小动作验证，最后把现象整理成可以复测的结论。认证机制正好能把这套方法练扎实。
为什么？因为登录页看起来很简单，无非是账号、密码和一个“登录”按钮；可系统真正完成的事情远不止校验两段文字。它还要处理注册确认、账号暂停、密码找回、多因素认证、设备记忆、第三方身份、敏感操作前的重新认证，以及认证成功后的会话建立。任何一条支路判断松一点，系统都可能在错误的时间相信错误的人。
这也解释了本课为什么不会教你拿字典反复尝试，或把一串账号丢给工具。那类操作既不能证明你理解了认证边界，还很容易锁住真实用户、打爆短信通道或触发上游身份平台的风控。我们要练的是更专业的能力：用专用靶场账号、很少的请求和清楚的状态断言，判断认证控制是否真的成立。
本课所有请求都只适用于本地靶场、预生产环境，或得到书面授权且明确划定账号、频率、时间窗口与停止条件的系统。只要出现真实用户通知、非测试账号、意外权限、异常成本或无法恢复的锁定，就立即停止，不要为了“把问题证明得更漂亮”继续扩大影响。
先把认证、授权和会话分开
认证回答“当前这个主体是谁”；授权回答“这个主体可以做什么”；会话管理回答“后续请求怎样延续已经确认的身份”。它们连在一起，却是三层不同的判断。
举个最常见的混淆。用户输入正确密码后进入“等待第二因素”状态，此时系统已经对身份有了一部分信心，但还没有完成完整认证。如果某个资料接口在这个阶段就返回用户数据，表面上看像访问控制失败，往根因追却会发现：系统把“第一因素通过”错误地当成了“完全认证”。再往后，完整认证虽然成功了，但如果会话标识没有正确更新，那就是下一课要讨论的会话问题。
因此，测试认证不能只问“能不能登录”，而要连续问下面四个问题：
- 系统此刻掌握了哪一份身份证明？
- 这份证明绑定的是哪个账号、哪次事务和哪个用途？
- 当前状态允许执行哪些动作，明确禁止哪些动作？
- 失败、重试、超时、恢复或切换入口后，服务器保存的状态怎样变化？
你可以把认证机制想成一座有多道闸门的车站。账号标识只是告诉工作人员“我要乘哪趟车”，密码、多因素认证器或通行密钥才是在提供证明；闸门是否真的打开，应由服务器决定。前端把按钮变灰、把菜单藏起来，都不能算安全边界。
认证因素不是“页面有几步”
认证因素通常来自三类：你知道的秘密、你持有的认证器，以及与你身体特征相关的本地验证。连续问两道知识问题，仍然只是同一类因素；密码和安全问题也不会因为分成两个页面，就自动变成可靠的多因素认证。
生物特征也经常被误解。很多现代设备是在本地用指纹或人脸解锁一把密码学私钥，服务端收到的是签名结果，并不直接收到人的指纹或人脸数据。此时真正参与网络认证的是设备中的密码学认证器，生物特征只是本地激活动作。测试报告若把这两层混在一起，修复建议往往会跑偏。
认证强度要看最弱替代路径
主登录页要求多因素认证，并不代表账号已经获得同等强度的保护。如果旧版接口、移动端、客服恢复或“忘记第二因素”流程只核对一条容易获得的信息，攻击者自然会走那条更短的路。
所以我们的对象不是一个表单，而是一组能够改变“谁控制这个账号”的入口：登录、注册确认、密码修改、密码找回、因素绑定与移除、主邮箱或手机号变更、客服恢复、第三方身份回调，以及风险事件后的重新认证。它们都要进入同一张认证地图。
在请求发出前写清授权边界
认证测试最怕含糊的授权。“可以测登录”到底包不包括触发短信？能否锁定账号？企业统一身份平台也在范围内吗？测试账号和员工邮箱是否共用同一身份目录？这些问题不先说清，技术动作很容易越过业务边界。
一张可执行的认证测试卡至少要记录：
“低频”“少量”和“注意影响”都不够具体。更好的写法是：只使用测试账号甲与测试账号乙；每类验证不超过审批记录中的上限；请求之间保持约定间隔；触发限制后等待蓝队确认；不更换来源来规避控制。这样执行人员不需要临场猜测，蓝队也知道应该看到什么。
专用账号也要有角色设计
只准备一个普通账号，很多状态根本测不清。比较实用的最小账号组包括：一个正常账号、一个启用多因素的账号、一个可被锁定的账号，以及在业务确实存在时准备的暂停账号或高权限测试账号。所有账号都应绑定虚构资料，不连接员工个人邮箱、真实手机号、生产支付方式或其他业务资产。
证据里不要出现账号全名。用“测试账号甲”“多因素账号乙”这类标签即可。密码、一次性验证码、恢复码、认证器种子、通行密钥材料和完整令牌都不进入截图、聊天记录或缺陷单。
先定义停止条件，再讨论测试步骤
下面这些现象一旦出现，应先停下来，而不是再补几次请求：
- 非测试用户收到登录、找回或多因素通知；
- 测试账号获得了未批准的真实数据或更高权限；
- 上游身份服务出现高风险告警或影响其他业务；
- 邮件、短信、推送数量或费用异常；
- 延迟与错误率明显上升；
- 账号无法按预案恢复；
- 日志出现未登记账号或无法解释的事件。
停止之后保留时间、关联编号、测试账号标签和最后一个可复现现象，通知负责人判断是否继续。不要擅自增加样本去“确认一下”。
1
团队只有一个测试账号，而且不知道锁定阈值。最合适的处理是什么？
把认证流程画成服务器状态机
很多认证缺陷不是某个输入框“过滤不严”，而是状态转换错了。最直接的分析方法，是先按正常业务走一遍，再把系统的信任状态画出来。
一套常见状态可以写成：匿名、已提交账号标识、第一因素通过、等待第二因素、完整认证、需要重新认证、账号恢复中、账号受限。名称不重要，关键是每个状态都要有明确的进入条件、允许动作、禁止动作和退出条件。
先用专用账号按正常方式走完登录、退出、密码找回和多因素管理，只记录页面与服务器返回的状态变化，不修改请求，也不尝试跳步。
为每个状态写一句服务器必须守住的安全断言。例如，“等待第二因素时不能读取受保护资料”，“恢复中的凭据只能修改发起恢复的那个账号”。
再列出所有能进入同一状态的入口。网页、移动端、旧接口和第三方登录若最终都能建立完整认证，就必须执行同一组不变量。
最后只挑高价值转换做最小验证。只要一个禁止动作被服务器接受，断言已经被打破，应停在这里收集必要证据，不继续浏览数据。
状态机里最值得盯住的绑定关系
认证材料不能只“看起来有效”，它还必须绑定正确的上下文：
- 绑定账号：测试账号甲的挑战不能完成账号乙的事务；
- 绑定事务：一次登录的第二因素结果不能拿去完成另一笔登录；
- 绑定用途：找回凭据不能被当成普通登录凭据或邮箱变更凭据；
- 绑定时间：过期材料应由服务器拒绝，不能只由前端倒计时；
- 绑定次数：一次性材料成功使用后应立即失效；
- 绑定认证强度：只完成第一因素的状态不能被标成完整认证；
- 绑定近期性：很久以前的登录状态不能无限期批准敏感变更。
这套绑定关系比“找一个能绕过的参数”更接近根因。开发可以据此补状态转换测试，蓝队也能据此设计事件类型。
前端状态不能代替服务端状态
在教学靶场里，可以先正常完成一次受保护操作，得到完整认证下的基线；然后分别让账号停在匿名、失败、等待第二因素和需要重新认证的状态，再观察同类操作是否由服务器一致拒绝。这里比较的是服务器结果，不是页面上有没有按钮。
如果等待第二因素时服务器已经返回了测试账号资料，结论已经成立。不要继续尝试更多接口，也不要查看与结论无关的字段。报告应写“等待第二因素的状态被错误地授予完整认证能力”，而不是只写“某页面可以访问”。
用成对观察判断账号枚举差异
账号枚举最显眼的形式，是系统分别提示“账号不存在”和“密码错误”。但实际差异可能更隐蔽：状态码、跳转链、正文模板、响应长度、响应头、额外挑战出现的时机、找回通知副作用，甚至处理时间，都可能泄露账号是否存在。
这里有个很重要的克制原则：验证差异不等于枚举账号。 一个确认存在的专用账号，加上一个由项目方预留且确认不存在的标识，已经足够构造成对观察。我们只需要证明公开结果能否稳定区分两类输入，不需要收集用户名列表。
建立可比较的两组输入
两组请求除了账号标识外应保持一致：同一个入口、同一种无效认证输入、相近时间、相同客户端条件，并严格遵守样本上限。然后记录下面这些公开结果：
时间差尤其容易误判。网络抖动、缓存、冷启动和上游依赖都会制造噪声。若授权只允许很少的请求，就诚实记录“样本不足以判断时间差异”，不要为了追求漂亮曲线不断加请求。文本、状态码或模板已经形成稳定差异时，也没有必要再测时间。
统一文案只是第一层
修复枚举差异不能停在把两句话改成一句话。公开响应的状态码、页面模板、跳转行为和大致处理路径也要一致。后端当然可以保留“账号不存在”“密码不匹配”“账号暂停”等精确原因，但这些原因应进入受保护的日志，而不是返回给未认证客户端。
实现上还要避免明显的快速退出。不存在的账号如果直接返回，而存在账号会执行成本较高的密码验证，两边即使显示同一句话，也可能留下稳定时间差。解决思路是让失败路径经过大致一致的工作，而不是在前端人为加一个固定延迟；固定延迟既可能被绕开，也会无谓拖慢所有用户。
统一响应并不等于故意折磨正常用户。页面仍然可以告诉用户安全的下一步，比如检查输入、稍后重试或联系支持，只是不确认某个具体身份是否已经注册。运营和客服需要的精确信息留在有权限的后台。
注册、登录、找回密码和邀请流程要一起检查。只修登录页，而注册页仍提示“这个邮箱已经存在”，账号状态仍然会从另一条入口泄露。
验证速率限制时，别把防护测成拒绝服务
在线猜测防护的目标，是让持续试错的成本迅速升高，同时不让任何人用少量失败请求长期锁住正常用户。固定次数后永久锁定看起来很严格，却可能反过来成为拒绝服务入口；只按来源地址计数，又会误伤共享网络，并漏掉分散来源的异常。
比较合理的方案通常由多层控制组成：账号维度的失败状态、递增等待、来源和设备风险信号、必要时的额外挑战、常见或已泄露口令拦截、多因素认证，以及可审计的恢复通道。验证码只能增加一部分自动化成本，不能替代服务端限速。
先问配置期望，再碰阈值
测试前让开发或运维说明：计数对象是什么，观察窗口多长，达到不同阶段会发生什么，成功登录是否重置计数，等待期如何恢复，解锁由谁负责，哪些入口共享计数。注意，这里要的是系统的预期行为，不是让测试人员盲猜。
在专用靶场中，可以把验证写成一个受控实验：
- 确认靶场账号可以牺牲，蓝队能够实时查看事件；
- 在批准阈值以内做少量失败尝试，每次记录时间和关联编号；
- 观察递增等待、临时限制或挑战是否按设计出现；
- 不更换来源，不轮换账号，不使用口令字典，也不尝试规避限制；
- 控制出现后停止，由蓝队核对计数和事件；
- 按预案恢复账号，并确认其他入口与关联业务未受影响。
如果授权不允许触发锁定，可以用配置审查、自动化测试结果和预生产演示补证。渗透测试不是只有发请求才算验证；在高影响控制上，组合证据往往更可靠。
三个经常被忽略的副作用
第一，企业身份可能跨应用共享。你以为锁的是一个教学系统账号，实际可能连邮箱、工单和远程接入一起受影响。第二，登录、找回和一次性验证码可能各有计数，也可能错误地共用一个全局计数。第三，成功认证后的重置逻辑会直接影响体验：计数不重置，正常用户可能刚登录就又被限制；无条件全部重置，又可能削弱风险控制。
因此，结论不能只写“能锁住”或“锁不住”。完整评价至少要同时回答：在线猜测阻力是否足够；合法用户是否容易被恶意锁定；等待与解锁是否可理解；蓝队能否看见并处理；多个认证入口是否执行一致策略。
2
账号在很少的失败请求后被永久锁定，所以认证防护一定更强。
把密码找回当成另一条登录路径
“忘记密码”不是登录页旁边的小工具，它能重新分配账号控制权。只要这条路径比正常登录弱，前面的密码策略和多因素认证就可能被绕到一边。
我们先把生命周期画完整：用户提交账号标识，系统决定是否发送带外消息，生成并保存恢复凭据，用户提交凭据，设置新密码，恢复凭据失效，系统通知用户，并按策略处理既有会话。每个节点都有自己的状态和副作用。
请求阶段：不泄露，也不改变账号状态
存在与不存在的账号应得到一致的公开响应和大致一致的处理特征。系统不应因为有人发起找回，就立刻锁住账号、修改密码或改变认证状态，否则找回入口会变成骚扰与拒绝服务工具。
请求端点还要控制频率。计数不能只看来源，也要关注目标账号和消息成本；但公开响应仍不能因为账号存在而明显不同。对邮件和短信通道，测试前必须确认是测试服务或已经批准的专用地址，避免把验证变成真实成本。
恢复凭据：短期、单一用途、一次消费
恢复链接或代码本质上是一份短期认证材料。它应由安全随机源生成，拥有足够的不可预测性，与单一账号和“找回密码”这一用途绑定，在服务端安全保存，并在成功使用或到期后失效。
生成恢复链接时，站点地址应来自可信配置或严格允许列表，不能盲目信任请求中可被影响的主机信息。恢复页面应使用受保护的传输，也要避免敏感值通过浏览器的来源字段、分析脚本或第三方资源意外流出。
在专用靶场里，不需要预测任何凭据。正常申请两份恢复材料，就可以验证这些断言：
- 凭据只能作用于签发时绑定的测试账号；
- 成功使用后再次提交会被拒绝；
- 超过靶场设定的短有效期后会被拒绝；
- 新签发材料是否让旧材料失效，与书面设计一致；
- 无效输入不会泄露账号状态；
- 验证端点在批准的少量失败后执行限速；
- 日志里没有完整恢复链接或代码。
证据只保存签发时间、验证时间、结果、关联编号和脱敏指纹。完整凭据不进入截图、命令历史、工单或聊天。
密码改完以后，流程还没有结束
设置新密码后，应通过已经登记的渠道通知账号主人，但通知中不能包含新密码或完整恢复凭据。系统还要明确处理既有会话：按风险自动失效，或者让用户清楚选择是否退出其他设备。为了减少恢复逻辑与会话创建逻辑纠缠，完成重置后让用户走正常登录流程，通常更容易保持边界清楚。
客服恢复同样是认证流程。若人工通道只问几条容易获得的个人资料，技术上再强的登录也会被旁路。测试人工流程时，优先使用脚本审查、访谈和测试工单演练，不冒充真实用户，也不采集真实个人资料。重点确认高风险变更能否升级审核、操作者是否留痕、账号主人是否收到通知。
多因素恢复不能降级成一个弱问题
丢失第二因素后，用户确实需要恢复通道，但恢复强度不能明显低于原来的认证强度。恢复码、仍然可用的另一个认证器、经过验证的恢复联系人和重新核验身份，各有不同的风险与成本。产品应根据账号价值组合使用，并让恢复事件触发通知、风险标记和必要的重新认证。
“你母亲的姓名是什么”这类知识问题通常不是可靠的独立因素，答案可能公开、可猜或多年不变。它更不应成为停用多因素认证的唯一依据。
多因素认证要检查整条状态链
多因素认证的价值来自因素之间的独立性，以及服务器对顺序和绑定关系的严格执行。页面多一个验证码输入框，不代表多因素认证已经正确实现。
先看独立性。密码和另一段静态口令都属于“知道的东西”；邮件验证码是否算独立因素，要看邮箱是否可能与当前账号共用同一密码、是否在同一受损设备上接收。短信、一次性口令、推送确认和密码学认证器面对的威胁也不同，不能只用“都有第二步”把它们归成同一种强度。
等待第二因素必须是受限状态
第一因素通过后，服务器应进入一个权限很窄的中间状态。这个状态只允许完成第二因素、取消登录或执行批准的恢复动作，不能读取完整用户资料，不能绑定新认证器，也不能修改邮箱、密码或安全设置。只有第二因素成功后，服务器才能建立完整认证。
用两个完全由测试团队控制的账号，就能验证关键绑定：账号甲收到的挑战只能完成账号甲当前的事务；过期挑战不能使用；已经消费的挑战不能重放；重新发送后新旧挑战的关系符合设计；少量失败达到批准边界时触发限制；因素绑定、替换、移除前要求近期重新认证。
一旦发现账号甲的挑战能够推进账号乙的事务，或等待第二因素时已经能读取受保护数据，结论就成立。不要继续尝试真实账号，也不要扩大到更多接口。
一次性口令并不自动抗钓鱼
一次性口令通过短有效期、单次使用和尝试次数限制来减少重放与在线猜测，但用户仍可能把它输入伪造页面。推送确认也可能遭遇认证疲劳：反复弹窗、上下文不清，用户最后误点“同意”。
高风险系统应优先提供密码学认证方式，让认证结果绑定到真实站点和当前挑战。通行密钥就是常见形态：设备保存私钥，服务端保存公钥；每个站点使用独立凭据，认证器对服务器生成的挑战签名。用户的本地生物特征通常不上传，服务端只验证密码学结果。这种机制减少了可以被复制到伪造站点继续使用的共享秘密。
但“支持通行密钥”也不是终点。测试仍要看注册时是否处于足够强的认证状态，凭据是否绑定正确站点和账号，挑战是否新鲜，丢失设备后的撤销是否有效，新增或删除凭据是否通知用户，以及恢复流程有没有重新退回一条过弱的路径。
因素管理比登录挑战更容易被漏掉
启用、重新绑定、替换、停用和生成恢复码，都会改变账号的认证能力。它们应当：
- 要求近期且强度合适的重新认证；
- 清楚展示正在操作的账号与认证器；
- 防止当前会话仅凭一次点击移除最后一道保护；
- 对新增、移除和恢复产生用户通知；
- 让旧认证器、旧挑战和已用恢复码按设计失效；
- 在服务端留下可关联、但不包含秘密的事件。
3
下列哪些现象能说明多因素认证的状态链需要修复？
敏感操作要检查重新认证和状态提升
完整登录不代表后续所有时间、所有操作都拥有同样的保证。修改密码、主邮箱、手机号、多因素认证方式、恢复方式或支付收件信息，会直接影响账号控制权。服务器应根据操作风险和上次认证时间要求重新认证，而不是只看“当前有会话”。
这里可以把普通浏览和敏感变更理解成两条不同高度的门槛。普通浏览可能接受现有完整认证状态；敏感变更则需要更新鲜、强度更高的证明。重新认证完成后，服务器再短暂提升本次操作的许可，并对操作对象与时间做约束。
最小影响地验证服务器守卫
在教学靶场中，先用测试账号按正常流程完成一次敏感变更，记录预期的重新认证步骤。随后让账号分别处于认证过久、刚完成账号恢复、仅第一因素通过等状态，只观察服务器是否拒绝进入真正的提交阶段。不要实际修改真实联系方式，也不要绑定外部资产。
前端弹出密码框不等于服务器实施了重新认证。要确认的是：缺少新鲜证明时，服务器拒绝敏感动作；证明成功后，只允许预期账号和预期操作；状态过期或操作完成后，临时提升消失。
修复时应把认证守卫放到共享的服务器策略层，让网页、接口和移动端复用。若每个页面各写一套判断，很容易出现主站补了、旧接口漏了的情况。自动化测试也应围绕状态不变量编写，而不是只测页面按钮能否点击。
让日志既能调查，又不保存认证秘密
认证事件如果只在浏览器上留下“登录失败”，蓝队很难判断是用户输错、程序异常还是有人在持续试探。反过来，日志若把密码、验证码、恢复链接和会话标识全部记下来，监控系统本身又会变成秘密仓库。
一条可用于调查的认证事件，通常要包含：统一时间、事件类型、认证入口、结果类别、测试或用户身份的脱敏标识、来源与设备的适度特征、风险或限速动作、贯穿网关与应用的关联编号，以及处理该事件的服务。字段要足够稳定，才能把一次用户交互在网关、认证服务、消息服务和风险系统之间串起来。
哪些内容不要直接进日志
下面这些值应删除、遮蔽、不可逆映射或以专门方式保护，而不是原样记录：
- 密码、验证码、恢复码和认证器种子；
- 完整访问令牌、恢复链接与会话标识；
- 私钥、加密密钥和连接秘密；
- 不必要的个人信息与完整联系方式；
- 超出日志系统安全级别的数据。
为了关联同一账号的事件，可以对稳定账号标识做受控的不可逆映射。为了关联同一会话，也可以记录经过处理的会话指纹，而不是原始值。关键是分析人员能对上事件，但不能拿日志里的内容直接完成认证。
日志验收不能只看“有记录”
蓝队应能区分失败认证、限速、临时锁定、恢复请求、恢复成功、第二因素挑战、因素变更、重新认证和敏感操作拒绝。测试窗口也要打上标签，而不是把测试流量整个排除；完全忽略测试人员会掩盖检测盲区。
一次合格的联动验证可以这样做：测试人员发送一个批准的失败请求，记录时间和关联编号；蓝队在日志中找到对应事件，确认字段经过脱敏；达到预定的低风险条件时，检查告警是否真正送达值班渠道；最后由双方对上前端现象、服务器状态和处置动作。
日志不是越多越好。真正有用的是事件类型稳定、时间可信、上下文足够、关联编号贯通，而且不包含能够直接用于认证的秘密。
在专用靶场里完成一次最小验证闭环
下面把前面的知识收成一套可重复的练习。假设教学靶场提供四个虚构账号：正常账号甲、多因素账号乙、可锁定账号丙和暂停账号丁；邮件与推送都进入测试收件箱，蓝队能够查看事件面板。练习目标不是“接管账号”，而是验证六条安全断言。
练习断言
- 存在与不存在的标识不会产生可稳定区分的公开响应；
- 连续失败会按靶场策略增加成本，但不会造成不可恢复的长期锁定；
- 恢复凭据绑定账号与用途，过期或成功使用后失效；
- 等待第二因素时不能读取受保护数据；
- 因素变更和敏感操作要求近期重新认证；
- 每个关键事件都能由关联编号在日志中找到，且日志不含秘密。
执行顺序为什么很重要
先做正常流程基线，再做成对响应观察，然后验证恢复与多因素状态，最后才安排可能触发锁定的实验。锁定放在最后，是为了防止测试账号提前不可用，连带阻塞其他练习。
每条断言都使用同一张记录表：前置状态、账号标签、请求数量、时间窗口、预期结果、实际结果、关联编号、副作用和恢复状态。证据截图只裁出理解结论所需的区域，所有认证秘密与个人信息都遮蔽。
发现问题后什么时候停
如果公开响应已经出现稳定差异，不再增加账号样本；如果等待第二因素已经返回测试资料，不再尝试其他数据接口；如果恢复凭据成功后仍能再次使用，只记录第二次被接受，不再重复消费；如果日志出现完整秘密，立即限制证据传播并通知负责人。
这种“证明断言被打破就停”的做法，有时会让刚入门的人觉得不过瘾。但专业评估追求的是可复核结论，不是动作数量。多做一步若不能改变严重性、根因或修复方案，它通常只是在增加风险。
把发现写成开发能接住的句子
推荐使用“预期不变量—实际现象—最小证据—影响—验收条件”的结构。例如：
等待第二因素的状态不应读取受保护资料；教学账号乙在该状态下收到了资料响应。验证只执行一次，未访问其他字段。修复后，所有入口都应由共享服务器守卫拒绝该状态，并产生可关联的拒绝事件。
这种写法直接指向状态与控制。开发可以据此补测试，蓝队知道要补什么事件，复测人员也清楚成功标准。不要用“认证可绕过，建议加强安全”这种无法验收的句子。
用修复回归把认证问题真正关掉
修复完成后，要使用同一组测试账号、同一频率边界和同一条安全断言复测。先确认原现象消失，再检查修复有没有把问题推到别的入口。
统一响应后，正常用户还能否完成找回？加入锁定后，别人是否能轻易让用户长期无法登录？多因素状态修正后，恢复通道是否仍然过弱？密码重置后，旧会话是否按产品策略处理？通行密钥被移除后，旧凭据是否真的被服务器拒绝？这些问题决定修复是补了一块贴纸，还是重建了完整边界。
一份完整的认证结论应该回答五件事：有哪些认证入口与状态；哪条安全断言被打破；最小验证怎样在授权内完成；蓝队是否能看见并处理；修复后用什么结果验收。做到这里，认证问题才从“某个页面有点奇怪”，落成了具体状态、控制和责任。
从身份确认走向会话管理
认证成功只是服务器第一次确认身份。接下来，系统要用会话把这次确认延续到后续请求。完整认证时是否轮换会话标识，退出后旧状态是否失效，密码恢复与因素变更后其他设备怎样处理，这些问题已经越过认证边界，进入会话管理。
进入下一课前，保留三样成果：认证入口清单、服务器状态图和贯通前后端的关联编号。下一课会沿着它们继续追问：系统用什么记住你，这份记忆如何更新，又在什么时候彻底失效。