认证与授权：API安全的第一道门

可视化演示

动态演示认证与授权的核心机制，通过开始/执行/监控/完成四种模式展示关键概念与交互流程。

认证授权基础

你站在大楼门口，保安拦住你：“工牌看一下。”你递过去，他对着照片端详两秒，点点头放你进大堂。这是认证。接着你走进电梯，伸手刷门禁卡，电梯却只亮起 3 楼的按钮——你想去 12 楼的机房，门禁拒绝了。这是授权。认证和授权，一前一后，像两道闸门，把“你是谁”和“你能干什么”分开管控。

在 API 世界里，认证（Authentication）回答的是“请求方是谁”：通过 API Key、密码或令牌证明身份。授权（Authorization）回答的是“请求方能做什么”：比如只读订单、可写用户资料。两者常被合称为“鉴权”，但在工程上必须拆开设计——先做身份验证，再做权限判定，顺序不能颠倒。一旦混为一谈，就会出现“登录了就能访问一切”的危险设计。

一个完整的 API 访问，可以用逻辑表达式写清楚：

就像大楼门禁先查工牌再按楼层放行，API 网关也要先验证身份、再匹配权限。把这两步独立成模块，安全边界清晰，出问题也好排查——你知道该去查“认证模块”还是“授权模块”。

API Key：一把钥匙走天下

还记得刚入职时前台发的那张门禁卡吗？API Key 就是数字世界里的门禁卡。服务端生成一串足够长的随机字符串，交给调用方，调用方每次请求时把它放在请求头里“刷卡进门”。没人问你叫什么、来干什么，卡刷开了就进——这就是它能做到的最简单形态。

在 HTTP 请求中，最常见的做法是放在 X-API-Key 请求头，或 Authorization: Bearer <key> 头里。服务端拿到 Key 后，到数据库里比对：匹配则通过，不匹配则拒绝。生成逻辑本身不复杂——一个高熵随机串，但服务端只保存它的哈希值，不保存明文，这样即使数据库泄露，原始 Key 也不会直接暴露。

校验逻辑用公式表达：

门禁卡最大的好处是简单——但你想想：如果这卡丢了，坏人捡到就能刷开你的门；如果你想收回某个人的门禁权限，只能整栋楼换锁。API Key 的短板也在这：泄露难以定向撤销，只能吊销后重新发放。

OAuth2：前台访客制度

公司来了访客。前台不会给访客发员工工牌，而是核实身份后发一张临时通行证，上面写着“仅限 3 层会议室，14:00-16:00”。这就是 OAuth2 的思想：不把大门的万能钥匙交给别人，而是发一张有期限、有范围、可收回的临时通行证。

OAuth2 是一个授权框架，定义了四个角色：资源所有者（就是用户本人）、客户端（第三方应用）、授权服务器（前台，负责发证）、资源服务器（大楼里的办公室，负责验证放行）。其中最常用也最安全的流程是授权码模式（Authorization Code Flow）：用户到授权服务器登录确认 → 拿到一个授权码 → 客户端拿着授权码加上自己的密钥，去换访问令牌 → 之后每次请求都带着令牌访问资源服务器。

访问令牌的获取，可以看成一次“凭证交换”：

访客通行证制度复杂但灵活：临时、限时、限区域、可收回。这正是“用户授权第三方应用访问自己数据”时需要的安全级别——你的密码永远不会交给第三方。

双方案对比

门禁卡和访客通行证，哪个更好？答案永远是“看场景”。如果整栋楼都是自己人、门禁只分“能进”和“不能进”，发门禁卡最省心；如果经常有外部访客、还需要限时限区域，访客制度更合适。API 安全选型也一样。

API Key 适合机器对机器（M2M）场景：服务之间没有“用户”这个概念，一把钥匙直接进出。OAuth2 适合有真实用户参与的第三方授权场景：用户决定授权给哪个应用、授权到什么范围、有效期多久。前者的关键词是“直接”，后者的关键词是“可控”。

选型判断可以浓缩成一个逻辑式：

安全没有银弹，只有匹配。理解两种方案的底层逻辑，你就能在项目评审会上理直气壮地说：“这里不该用 API Key，因为我们需要按用户维度授权。”

令牌生命周期管理

访客通行证上写着“16:00 前有效”。过期了怎么办？去前台出示预约记录，换一张新证。这对应令牌的刷新机制：访问令牌（Access Token）通常是短命的（几分钟到几小时），刷新令牌（Refresh Token）则可以长期保存，只在授权服务器和客户端之间悄悄流通，用来换取新的访问令牌，避免让用户反复登录。

一个令牌的生命周期分为四个阶段：签发、使用、过期、刷新（或重新签发）。签发时授权服务器设置过期时间；使用期间资源服务器每次都要校验；过期后访问令牌作废；刷新令牌出面兑换新的访问令牌。整个流程设计得好，用户几乎感觉不到“过期”这件事。

当前请求携带的令牌是否有效，由两个条件同时决定：

好的令牌管理就像前台制度：短时通行证降低丢失风险，刷新机制只换新证不给旧证续命，作废清单让丢失的证立即失效。这套机制让“泄露”不再是灾难，只是一次普通的挂失。

权限校验实战

通行证写了“3 层会议室”，你拿它去开 5 层的机房，门禁依然响警报。这就是授权的最后一道防线：范围（scope）与权限校验。认证解决了“你是谁”，授权在每一扇具体的门前回答“你能进吗”。

生产环境中最常用的是 RBAC（基于角色的访问控制）：用户绑定角色，角色绑定一组权限。比如“客服专员”角色拥有“读订单”权限，但不拥有“改价格”权限。在 OAuth2 体系中，令牌里会带一个 scope 字段，比如 read:orders write:users，资源服务器拿到令牌后，先检查 scope 是否覆盖本次操作所需的权限。

RBAC 模型可以用一条链路表示：

把认证与授权当两道独立的门来设计，把权限给到最小、令牌有效期压到最短，是 API 安全的第一课。门禁不是为了防自己人，而是为了让每个人都只拥有完成任务所需的那一扇门。

AI 应用场景

Python 演示

import base64import hashlibimport hmacimport jsonimport time  def b64url(data: bytes) -> str:    return base64.urlsafe_b64encode(data).rstrip(b"=").decode("ascii")  def b64url_decode(text: str) -> bytes:    padding = "=" * (4 - len(text) % 4)    return base64.urlsafe_b64decode(text + padding)  def make_token(payload: dict, secret: str) -> str:    header = {"alg": "HS256", "typ": "JWT"}    header_b64 = b64url(json.dumps(header, separators=(",", ":")).encode())    payload_b64 = b64url(json.dumps(payload, separators=(",", ":")).encode())    signing_input = f"{header_b64}.{payload_b64}".encode()    signature = b64url(hmac.new(secret.encode(), signing_input, hashlib.sha256).digest())    return f"{header_b64}.{payload_b64}.{signature}"  def verify_token(token: str, secret: str, now: float) -> dict:    header_b64, payload_b64, signature_b64 = token.split(".")    signing_input = f"{header_b64}.{payload_b64}".encode()    expected = hmac.new(secret.encode(), signing_input, hashlib.sha256).digest()    actual = b64url_decode(signature_b64)    if not hmac.compare_digest(expected, actual):        raise PermissionError("signature mismatch")    payload = json.loads(b64url_decode(payload_b64))    if now > payload["exp"]:        raise PermissionError("token expired")    return payload  def check_scope(token_scope: str, required: str) -> None:    if required not in token_scope.split():        raise PermissionError(f"missing scope: {required}")  API_KEY_STORE = {    "svc-recommend": hashlib.sha256("sk_live_2024".encode()).hexdigest(),    "svc-search": hashlib.sha256("sk_live_9831".encode()).hexdigest(),}  def verify_api_key(presented: str) -> bool:    digest = hashlib.sha256(presented.encode()).hexdigest()    return digest in API_KEY_STORE.values()  def main():    secret = "gate-secret"    now = time.time()    payload = {"sub": "user-42", "scope": "read:orders read:users", "exp": int(now) + 300}    token = make_token(payload, secret)    print("issued token:", token[:40] + "...")     parsed = verify_token(token, secret, now)    print("token ok, subject:", parsed["sub"])     check_scope(parsed["scope"], "read:orders")    print("scope allowed: read:orders")     try:        check_scope(parsed["scope"], "write:orders")    except PermissionError as exc:        print("denied:", exc)     print("api key valid:", verify_api_key("sk_live_2024"))    print("api key stolen:", verify_api_key("sk_leaked"))  if __name__ == "__main__":    main()

1. signature = b64url(hmac.new(secret.encode(), signing_input, hashlib.sha256).digest())用密钥对令牌头和数据做 HMAC-SHA256 签名，防止令牌被篡改。
2. hmac.compare_digest(expected, actual)常量时间比较签名，避免时序攻击泄露信息。
3. if now > payload["exp"]: raise PermissionError("token expired")校验令牌是否过期，对应“短时效降低风险”原则。
4. if required not in token_scope.split(): raise PermissionError(...)scope 权限校验，令牌范围不够就直接拒绝。
5. API_KEY_STORE只存 Key 的 SHA-256 哈希，不存明文，数据库泄露也不怕。
6. verify_api_key(presented)把提交的 Key 哈希后与存储比对，这就是 API Key 门禁的校验逻辑。

常见误区

面试题