如何设计安全的 Magic Link 登录？
题目与使用场景
低风险 SaaS 希望用户输入邮箱后收到一次性登录链接。请设计请求、发送、验证、会话建立、撤销和审计流程。回答要明确邮箱账户被控制、链接被转发、邮件预取、重放、频率滥用和高风险操作的边界。
面试官考察什么
- 能否使用不可预测、短时、单次使用的令牌。
- 是否避免账户枚举、日志泄露和验证接口暴力尝试。
- 能否区分登录便利性与认证保证、抗钓鱼能力。
- 是否把会话、撤销、通知、审计和降级纳入完整流程。
作答前的澄清问题
先确认业务风险、邮箱是否已验证、是否支持多设备、链接有效期、邮件供应商、MFA 和高风险操作。若涉及支付、权限提升或敏感数据，应改用抗钓鱼认证或额外验证，不把邮箱链接当作唯一高保证因素。
30 秒回答框架
服务端生成高熵随机令牌，只存哈希、用户、用途、过期时间和使用状态；响应对已存在与不存在邮箱保持一致并限速。链接通过 HTTPS 验证，原子地消费令牌，再建立短期会话并旋转会话标识。令牌只允许一次使用，失败、过期、撤销和异常设备都记录审计。Magic Link 的安全性受邮箱和浏览器信道影响，不能宣称抗钓鱼或满足所有 NIST 高保证要求。
分步骤深入解答
1. 生成与存储
使用密码学安全随机数，令牌放在 URL 的一次性参数中；数据库保存哈希而非明文。记录用途、用户、创建时间、过期时间、已消费时间和请求上下文。验证时对哈希做恒时比较，并限制尝试次数。
2. 请求与验证
请求接口对所有邮箱返回相同提示、响应时间与状态，避免枚举。按 IP、邮箱、设备和全局维度限速，并对邮件发送做配额。验证成功必须在事务或原子条件更新中把令牌标记为已消费，防止并发双击重放。
3. 会话与风险控制
消费令牌后旋转会话标识、设置安全 Cookie，并通知用户登录设备和位置。邮箱预取或安全扫描器可能先访问链接，可使用中间确认页和明确的用户动作。敏感操作要求重新认证、MFA 或 WebAuthn；不要把登录链接直接升级为长期高权限凭据。
高质量示范回答
我会把 Magic Link 定义为低风险、便捷的登录因素，而非通用的抗钓鱼认证。用户请求后，服务端用 CSPRNG 生成高熵随机值，只保存哈希、用途、过期时间和消费状态，并对所有邮箱返回相同结果。验证端通过 HTTPS 查找哈希，在原子条件更新中标记单次消费，再旋转会话 ID、写入安全 Cookie 和审计事件。链接短时有效、可撤销，邮件 URL 不进入日志或分析系统。针对邮件预取，我会先展示确认页并要求用户点击继续；针对转发和多设备，明确是否允许一次消费和如何通知。支付、权限提升等操作改用 MFA 或 WebAuthn。测试覆盖重放、并发点击、枚举、限速、邮件泄露、设备异常和撤销。
常见错误
- 在数据库或日志中保存明文令牌。
- 验证成功后不原子消费，导致并发重放。
- 对不存在邮箱返回不同错误，允许账户枚举。
- 把 Magic Link 说成天然抗钓鱼或等同于硬件密钥。
- 令牌过期后仍可换长期会话，或缺少登录通知与撤销。
追问及应对
邮件客户端预取链接怎么办？
不要在 GET 访问时直接完成登录；先进入确认页，用明确的用户动作消费令牌，并记录预取与真实点击的差异。
令牌应保存多久？
按风险和邮件延迟预算选择短窗口，持续监控重放与未使用比例；过期后只能重新申请，不能延长旧令牌。
为什么不能用于管理员或支付确认？
邮箱信道可能被转发、劫持或钓鱼，且 NIST 将某些邮件确认用途与高保证认证区分。高风险操作应叠加抗钓鱼认证、交易绑定和独立通知。