Authentication (authN)——你是谁?

在机场出示你的护照——证明你真的就是你所声称的那个人。

这就是 Authentication(authN,身份认证) 这个概念,意思是证明身份:一次登录、一把 passkey、一个写着「这确实是 Alice」的令牌。它通常每个会话只发生一次。 做错了,冒名者就能顶着别人的身份进来。但证明你是谁,并没有说明你能做什么——那是另一个完全不同的问题。

Authorization (authZ)——你被允许做什么?

酒店房卡——它不说明你叫什么,但能打开你的房间,打不开别的房间,也打不开经理办公室。

这就是 Authorization(authZ,授权) 这个概念:决定一个身份被允许做什么——读这个、改那个、绝不碰管理后台。和 authN 不同,它必须在每个请求上都检查,因为一个已登录的用户可能碰上百种不同的东西。知道某人是谁,不等于允许他做任何特定的事。

两层——永远别把它们合并

夜店:保镖在门口查一次你的证件,而酒保每次你点酒时仍会确认你成年。两次检查,两个时刻。

经典的错误是把两者融合——证明一次身份就永远信任它,或者把所有权限都塞进登录令牌里再也不复查。authN 发生在大门口;authZ 发生在里面的每一扇门。 把它们分开,并且不停地检查第二个。

Don't Roll Your Own Auth——永远别自己造

你不会在车库里用铁皮焊自己的银行金库——你会买一个由只干这一行的人造好并测试过的。

这就是 Don't Roll Your Own Auth 这条实践。身份是其他一切赖以站立的地基,而且极其容易在细微处出错。用经过验证的标准和库——成熟的协议、久经考验的认证库或服务商——而不是你自己发明的聪明方案。安全史上铺满了自制的认证方案:看着没问题,直到突然就不行了。

地图:六组共 22 个概念

一串钥匙:先看到整串,再学会哪把钥匙开哪扇门。

本课的概念分成六组。每组回答各自的问题:这两个「auth」是什么、如何证明身份、如何保持登录、如何不用密码授予访问、如何决定权限,以及这一切通常怎么崩坏。

下面每个概念都得到同样的待遇:它的英文名称(你查文档时要搜的术语)、一幅生活中的画面、一张图示,以及一张带字段的卡片。末尾是收录所有概念的速查表。

Password Hashing——密码,脆弱的默认选项

和门卫共享的一个暗号——管用,直到有人偷听到、猜中,或者你到处都用同一个。

密码是通用的,也是最常见因素里最弱的:会被复用、会被猜中、会被钓鱼。如果非用不可,不容商量的规则是绝不把它们存成文本。要存一个缓慢的、加盐的哈希(Argon2、bcrypt)——这就是 Password Hashing——这样被盗的数据库也不会交出所有人的密码。(更多内容见「失误」那一章。)

MFA——你知道的、你拥有的、你本身

银行的保管箱需要你的钥匙和银行的钥匙。单独一把什么也打不开。

MFA(Multi-Factor Authentication,多因素认证),即双因素,要求在密码之外再提供第二个证明——你拥有的东西(应用里的验证码、安全密钥)或你本身的特征(指纹)。这样即使密码被盗,单靠它也没用。验证器应用的验证码(TOTP)很可靠;短信验证码较弱(可被拦截),但总比没有强。MFA 是你能加上的、最大也最便宜的一项安全收益。

Passkeys——无密码的未来

一把只在它被配制的那一扇门上有效的钥匙——伪造网站、复印锁的照片,钥匙就是转不动。

Passkeys(基于 WebAuthn 标准)用绑定到你的设备和真实网站的一对加密密钥取代密码,所以没有什么可被钓鱼、复用或泄露的——Apple、Google 和 Microsoft 现在都默认采用。私钥永远不离开你的设备;网站只会看到一个签名。认证正在朝这个方向走:没有什么可偷。

Stateless HTTP——HTTP 没有记忆

一家店,店员你一转身就把你忘了——所以你需要一张票,在下一步证明自己已经付过款。

HTTP 是无状态的:每个请求都是独立的;服务器不记得你一秒前刚登录过。所以认证之后,会发给你一样东西——一个 cookie 或令牌——你随每个请求一起发送,表示「还是我」。下面的一切,都是做到这一点的两种方式。(这就是协议课里讲的无状态。)

Session——服务器来记

衣帽间——你手里拿着一张编了号的小票,所有真实信息都在柜台后面、记在那个号码下。

用会话(session)时,服务器保存你是谁,只给你一个 cookie,里面只有一个随机的会话 id。每次请求,它都去查这个 id。服务器是事实的来源,所以注销或封禁某人是即时的——删掉会话就行。代价是服务器必须存储并查询这份状态。大多数网页应用的正确默认选择。

JWT——令牌自己带着真相

音乐节手环,你的访问等级已经印在上面并加了防篡改封条——保安检查的是封条,而不是来宾名单。

JWT(JSON Web Token) 是客户端持有的一个签名令牌,它包含身份及其 claims(声明);服务器只需验证签名,不用查任何东西。这让它无状态,也便于跨服务扩展——但难以撤销: 泄露的令牌在过期之前一直有效。所以要把有效期设短,并搭配一个 refresh token。非常适合 API 和微服务;对简单的网页应用来说是杀鸡用牛刀。

httpOnly Cookie——存在哪里很重要

钥匙锁在抽屉里,与钥匙用胶带粘在前门上——同一把钥匙,安全性天差地别。

浏览器里的令牌应当放在 httpOnly cookie 里(JavaScript 读不到),而不是 localStorage——那里任何被注入的脚本都能偷走它。存放位置本身就是安全的一部分:弄错了,一个 XSS bug 就会把所有会话拱手送给攻击者。你如何传输和存放凭证,与凭证本身同样重要。

OAuth 2.0——不共享密码就授予访问

代客泊车钥匙:能发动汽车、打开车门,但打不开后备箱和手套箱——你交出的是有限的访问权,而不是整串钥匙。

这就是 OAuth 2.0 协议。它让用户可以授予你的应用对其在另一个服务上的账户的有限访问权——你的应用读取他们的 Google 日历——而不必把 Google 密码交给你。 对方服务会给你的应用一个受 scope(范围)限制的 access token(「读日历,别的不行」)。它讲的是委托授权,不是身份。

OIDC——还能告诉你「你是谁」的 OAuth2

代客泊车钥匙上又夹了一张带照片的证件——不只是「这把钥匙能开什么」,还有「它属于这个人」。

单靠 OAuth2,你只知道应用可以访问什么,而不知道用户是谁。OpenID Connect(OIDC) 在其上加了一层很薄的身份层——一个带有已验证 claims 的 ID token(这是 Alice,这是她的邮箱)。「用 Google 登录」和单点登录(SSO) 靠的就是它。当你想要社交登录或 SSO 时,OIDC 就是标准。

API Key——简单的机器凭证

你给一位可信承包商的备用钥匙——上面没有名字,只是「谁拿着它,谁就能进来」。

API key 是一长串秘密字符串,标识的是一个程序,而不是一个人——用于服务之间和程序化的访问。简单有效,但它就是凭证:谁找到它,谁就能进来。所以要限定范围、定期轮换,并且绝不提交到 git,也绝不放进 URL。 适合机器;不能代替真正的用户身份。

Deny by Default / Least Privilege——除非允许,否则禁止

新员工的工牌,在每扇门被明确授权之前什么也打不开——而不是什么都能开,直到有人想起来锁上其中几扇。

授权的基础是两条规则。Deny by default(默认拒绝): 除非明确允许,一切都被禁止。Least privilege(最小权限): 每个身份只获得它所需的最低限度的访问,不多给。默认开放的系统会泄露——总有人忘了限制新的端点。默认关闭的系统则安全地失效。从「不」开始,有意识地授权。

RBAC——按角色授权

剧院里,你的票种——池座、楼座、后台通行证——决定你能去哪里,而不用点你的名。

RBAC(Role-Based Access Control,基于角色的访问控制) 把权限归入角色——管理员、编辑、查看者——再把用户分配给角色。简单、易读,对大多数应用来说也够用:「编辑可以发布,查看者不行」。当规则取决于上下文或具体的那条记录时,它就显得粗糙了,这时就轮到后面的模型出场。

ABAC——按策略授权

是一条规则,而不是一份名单——「经理可以在工作时间、用公司设备批准 1 万以下的报销」——每次都重新计算。

ABAC(Attribute-Based Access Control,基于属性的访问控制) 根据用户、资源和上下文的属性来决定——角色以及金额以及时间以及设备。比固定角色灵活得多,也复杂得多。该采用它的信号是:你在角色检查之上堆了不止几个自定义的 if 条件。

Ownership Check——你能碰这条记录吗?

你有一张有效的图书证(一个角色),但这并不让你去读别人借走的那本书里潦草写下的笔记。

归属检查(ownership check,对象级授权) 是最常被漏掉的检查:即使是有效的「编辑」,也只应编辑他自己的文档,而不是所有人的。角色说「编辑可以编辑」;你仍然得验证这位编辑拥有这一行。忘了它,是最常见的访问控制 bug——改一下 URL 里的 id,你就进到了别人的数据里。永远检查对象,而不只是角色。

Broken Access Control / IDOR——忘了检查

一栋楼,前门有人把守,但里面每扇门都没锁——一旦进去,你可以去任何地方。

Broken Access Control(失效的访问控制) 是排名第一的网页漏洞:一个端点认证了用户,却忘了检查他是否被授权做他所请求的事。它最常见的形式是 IDOR(Insecure Direct Object Reference,不安全的直接对象引用)——把 /orders/123 改成 /orders/124,就看到别人的订单,因为服务器从没检查过归属。数百万条记录的泄露,追根溯源正是这个。在每个请求上、在服务端、针对实际的对象检查 authZ。

Plaintext / Fast Hash——把密码存错了

把整条街每户人家的备用钥匙,都放在门廊上的一个玻璃罐里。

把密码存成明文——或者用 MD5 这样的快速哈希——意味着一次数据库泄露就暴露所有人,而被复用的密码还会连累他们的其他账户。密码必须缓慢且逐个地做哈希(Argon2、bcrypt),这样即使被偷,破解起来也代价高昂。哈希慢是目的,不是缺陷。

Token Leakage——泄露并轻信令牌

把警报密码写在便利贴上贴在门上——锁没问题;是你自己把秘密发出去了。

令牌泄露(token leakage) 就是令牌和密钥逃逸出去的方式。它们通过 URL(会被记入日志)、浏览器的 localStorage(脚本能读)以及提交进 git 的秘密泄露。而且令牌必须被验证,而不是因为它出现了就信任它——被篡改或已过期的必须拒绝。把每一份凭证都当作总有一天会泄露的东西来对待:短有效期、轮换,绝不放在会被记录或被抓取的地方。

Trusting the Client——相信浏览器说的话

一家店让顾客自己写价签,在收银台也从不核对。

这就是轻信客户端这个反模式。客户端发来的任何东西——表单里的隐藏字段、cookie 里的角色、一个 isAdmin=false 标志——都可以被伪造。 浏览器、应用、请求,全都在用户的控制之下。每一道真正的检查都必须发生在服务器上,那是用户改不了的地方。客户端只是建议;服务器才是权威。

Auth Provider——用库或服务商

你不会自己制造安全带——你会装上经过认证的,由专家设计、经过多年碰撞测试的那种。

对几乎所有人来说,正确的做法是不要自己搭认证: 用你框架自带的认证,或者一个 auth provider(Auth0、Clerk、Supabase、Cognito 之类),它会处理哈希、会话、MFA、OAuth,以及你想都想不到的边界情况。你的工作是把它正确接入,并掌管授权——只有你自己才懂的那部分。

Match the mechanism to the app——让机制匹配应用

家门钥匙、车钥匙和酒店房卡都是「钥匙」——你按门来选,而不是按时髦与否。

普通网页应用用会话(简单、可即时撤销);需要跨服务的无状态扩展时,用短有效期 JWT 加 refresh;社交登录和 SSO 用 OIDC;机器对机器用 API key。凡是重要的地方都加上 MFA,尤其是管理员账户。按你应用的形态来选,而不是按听起来高级与否。

这一切如何串起来

酒店住客的路径:前台出示护照,手里拿着房卡,而每扇门自己决定要不要打开。

登录因素(密码、MFA、passkey、OIDC、API key)通向 authN。它的结果随每个请求一起,放在会话或 JWT 里传递,最好存在 httpOnly cookie 中。在每个请求上,authZ 按角色或策略做决定——并且总是检查对象的归属。