现代身份验证：密钥、OIDC、会话 - 真正的简短列表

简单来说

在2026年，以“正确”的方式对Web应用进行身份验证取决于两个问题：(1) 您是面向消费者的B2C应用，还是面向企业的SaaS B2B？(2) 您是否准备好运营自己的IdP，还是依赖于提供商？2020年代中期的模式（JWT无状态+刷新令牌在localStorage中）已经过时——这有很好的理由。

事件

HN帖子重新引发了经典讨论，并得出了一个有趣的共识：对于大多数应用程序，2026年的务实技术栈是：

1. 服务器端加密的HttpOnly + SameSite=Lax会话cookie 用于身份验证状态。结束客户端存储的JWT。
2. OIDC（Google/Apple/GitHub） 用于无密码的注册。
3. Passkeys（WebAuthn） 用于第二步或完全替代密码。这终于在所有地方都被采用（iOS 17+，Android 13+，所有浏览器）。
4. 服务器端会话短周期旋转（约1小时）+ 长周期刷新（约14天）通过单独的cookie。
5. 除非您有真正的无状态多租户要处理，否则客户端不使用JWT。

从结构上讲，有三件事发生了变化。一：敏感令牌的localStorage已经结束（XSS = 完全损害，没有争论的余地）。二：passkeys的成熟度——公众采用现在已经超过关键阈值，在主要生态系统中（Google、Apple、Microsoft都已部署），尽管没有人最近发布详细数据。三：托管的IdP（Clerk、WorkOS、Auth0）现在提供SSO/SCIM/passkeys的开箱即用覆盖，任何少于5人的团队都没有兴趣重新实现。

幕后

• 会话cookie：Secure; HttpOnly; SameSite=Lax; __Host- 前缀。在每次特权升级时旋转。
• CSRF：SameSite=Lax覆盖了95%的情况；在敏感的突变上添加CSRF令牌仍然是安全带。
• PKCE在所有公共OAuth流程（SPA、移动）中是强制性的。
• 常见陷阱：过早将passkey设置为“强制”2FA——如果用户只有一个设备，则会丢失账户。
• 流行漏洞：浏览器扩展读取SPA内存——不在localStorage中存储任何内容的另一个理由。

结论

有三个要点。一：如果您在2026年启动，除非有特定的监管原因，否则选择提供商（Clerk、WorkOS、Stack Auth）。节省的工程时间可以用于产品开发。二：如果您有一个遗留的JWT-in-localStorage技术栈，请计划迁移到会话cookie——这是一个优先的安全工作，而不是美容工作。三：passkeys已经准备好使用；现在可以作为选项启用，并在2027年之前在企业中强制执行。需要关注的是跨平台passkeys的标准化（真正的B2B障碍）。