登录方式：密码、魔法链接与 OAuth 的三条路，和 3.0% 的企业邮箱拦截

登录方式的选择，决定了你以后每个月要回多少张工单。

一、一个月 4,180 次登录

2026 年 8 月，林澈第一次把登录方式拆开统计。他一直以为大多数用户用密码登录，数据给出的答案相反：密码占 45.0%，OAuth 占 40.0%，魔法链接占 15.0%。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

这个比例不是他设计出来的，是用户投票投出来的。产品上线时三种方式都开着，两年后自然形成了这个分布。

登录方式不是技术选型，是用户习惯的观测结果。 你能决定提供哪几种，不能决定用户用哪一种；后者只能靠数据看。

他做这次统计的起因很具体：一个月里收到 19 封「点了登录链接没反应」的邮件，全部来自企业邮箱。这 19 封让他意识到，三种方式各自有一类只属于它的失败。

二、三种方式的成本对照

把三种方式放在同一张表里，看的不是「哪个先进」，而是「哪个在你的规模下总成本最低」。

密码的实现最重，因为它不只是一个输入框：还要有强度规则、找回流程、泄露检测与限流。它的支持成本也最高，一个月 108 张找回工单，占全部账号工单的一半。

魔法链接实现最轻，但把风险转移到了邮件链路上。邮件延迟 12 分钟，用户就会以为没发出去；企业邮箱把链接放进隔离区，用户就会说「点了没反应」。

OAuth 的实现成本按供应商累加：接四家就是 24 小时，之后每家每年约 2 小时维护。它把「验证身份」这件事交给了别人，代价是依赖别人的可用性与回调规则。

三种方式不是互斥的。 它们各自覆盖一类场景：OAuth 覆盖有第三方账号的人，魔法链接覆盖不想记密码的人，密码覆盖前两者都失败的人。

表里的实现工时是净编码时间，不含调试与文档。他后来复算过：OAuth 第一次接入实际花了 11 小时，其中 5 小时耗在回调地址与作用域配置上。按这个比例，四家的真实成本更接近 40 小时，而不是表里的 24 小时。

三、4,180 次怎么分的

OAuth 内部还要再拆一次，因为不同供应商的用户结构完全不同。

GitHub 占比 22.0%，说明产品有一批开发者用户；Microsoft 只有 10.0%，但它的失败成本最高——企业账号通常连着组织策略，改绑定要 IT 配合。

比例决定优先级。 Google 一次回调失败影响 1,070 次登录里的某几次，Microsoft 一次失败可能让整家公司的人当天进不来；后者次数少，但要有单独的排查文档。

密码失败 11.4% 看起来高，其实正常：用户记不住密码是常态。关键不是把失败率降到零，而是让失败之后的路径足够短——他做到 50.5% 的失败者直接走找回，而不是先来一封工单。

魔法链接还有 26 次「未完成」（4.1%）：链接点开了，但没有在同一个浏览器里完成跳转。原因多半是用户在手机邮箱里点链接、产品却开在电脑上，或者网关先打开了链接。这一类不改代码也能改善——在邮件里写一句「请在同一台设备上打开」。

四、19 次拦截与组合建议

19 次企业邮箱拦截不是随机故障，而是有规律的三类：链接被安全网关预取后失效、邮件被放进隔离区、域名策略直接拒收。

第一类最隐蔽：安全网关会先访问一遍链接做扫描，一次性链接因此被消耗掉，用户再点就失效了。处理办法是把「点击即登录」改成「点击后确认一次」，代价是多一步。

第二类没有技术解法，只能给文案：在「没收到邮件」的提示里加一句「企业邮箱可能在隔离区，请联系 IT」。这句话能挡掉一部分工单。

第三类要在登录页给出替代路径：检测到企业域名时，优先推荐 OAuth 与密码，而不是继续让他等邮件。

组合建议是三种都留，但默认值不同：面向开发者默认 GitHub，面向企业默认 Microsoft，其余默认魔法链接，密码作为兜底。默认值不是强制，只是把最可能成功的那条路放在最前面。

不要为了简化维护而砍掉一种方式。 砍掉密码，找回工单会变成「我进不去」；砍掉魔法链接，不想授权第三方的人会流失；砍掉 OAuth，企业客户的 IT 会第一个反对。

默认值也有代价：它会让一种方式的占比慢慢变大，最后你在报表上看到的分布，已经不是你最初设计的那一个。他每季度会关掉默认值一周，看真实分布有没有变化；这一步很笨，但能防止默认值悄悄变成唯一路径。

组合方案还要写在帮助文档里。用户遇到「我该用哪种」时，一张三行对照表比一整页说明有用：有公司账号用 Microsoft，有 GitHub 用 GitHub，都不想用时用魔法链接。

复算：
登录合计：1,880 + 1,672 + 628 = 4,180
占比：1,880 ÷ 4,180 = 45.0%
      1,672 ÷ 4,180 = 40.0%
      628 ÷ 4,180 = 15.0%
密码失败：214 ÷ 1,880 = 11.4%
转找回：108 ÷ 214 = 50.5%
OAuth 拆分：1,070 + 368 + 168 + 66 = 1,672
占比：1,070 ÷ 1,672 = 64.0%；368 ÷ 1,672 = 22.0%
      168 ÷ 1,672 = 10.0%；66 ÷ 1,672 = 3.9%
魔法链接：拦截 19 ÷ 628 = 3.0%；未完成 26 ÷ 628 = 4.1%
OAuth 回调失败：9 ÷ 1,672 = 0.5%

复算里最值得看的是 50.5%：一半的密码失败者直接走了找回，而不是发工单。这个比例不是天生的，是登录页把「忘记密码」放在失败提示旁边换来的。

五、行动清单与复算验收

• 统计一个月三种登录方式的次数与占比。
• 给每种方式算一次实现工时与每年维护工时。
• 统计每种方式的失败次数与转人工比例。
• 把 OAuth 按供应商拆开，找出失败成本最高的那家。
• 检查企业邮箱拦截的三类原因，各写一条处理。
• 在登录失败提示旁放「忘记密码」与「换一种方式」入口。
• 给不同来源的用户设不同默认方式，但不隐藏其他方式。
• 每季度看一次比例变化，别让默认值悄悄变成唯一路径。

验收标准：任取一种登录方式，都能说出它每月多少次、失败多少、失败之后用户走哪条路。

前四条是「把三种方式分开记账」，后四条是「让失败有出口」。如果只有一小时，先做第六条：失败之后的路径比失败率更影响工单量。

使用边界与实操验收

4,180 次是一个产品的分布。 开发者工具与面向大众的产品，OAuth 与密码的比例会完全反过来。

OAuth 不等于省事。 它省掉了密码管理，但带来了供应商配置、回调调试与账号绑定问题；接四家的维护量不比维护密码少。

魔法链接依赖邮件。 邮件送达率、延迟与企业策略都会直接变成登录失败，这部分成本要算进消息系统那一组。

不要在登录页做实验。 登录是高频路径，任何改动都会同时影响所有用户；要测就测文案与默认值，不要测流程本身。

失败率不是越低越好。 把失败率压到零的常见做法是放宽校验，代价是账号安全；这里只算成本，安全边界在另一组。

关键参考与核验范围

• OWASP 认证速查表 ：用于核对密码、限流与账号锁定的最低要求。
• NIST SP 800-63B ：用于核对认证保证等级与多因素认证的分级。
• Google Identity：OAuth 2.0 ：用于核对 OAuth 回调、作用域与令牌生命周期的官方说明。

以上链接于 2026-10-27 实测可公开访问；未核验版本、功能范围与政策更新。核验日期：2026-10-27。

范围上只讨论登录方式的成本与失败路径，不讨论密码学实现、令牌存储细节与第三方身份提供商的商务条款。

系列导航

• 上一篇：注册表单：六个字段砍到三个，与 2.8 个百分点的提交率
• 下一篇：邮箱验证与首登：十二分钟、4.2% 未完成与四十九个人的去向
• 回到目录：一个人的账号体系：一百零八张找回工单、三十天冷静期与 4.2% 的验证流失
• 相关阅读：一个人的安全基线：十四个入口、十七个密钥与一次 72 小时响应