2. 基础知识

在进入具体的安全配置与代码实践之前，必须先建立一套清晰、统一的术语体系。、交易凭证、权限模型、认证与授权，这些词在日常开发中经常被混用，但在安全设计里它们各自承担不同职责。理解它们的边界，是后续所有防护措施能够落地的前提。

一、核心概念与术语边界

（）是一串由服务方签发的标识字符串，用于识别调用方身份。它通常以明文形式出现在请求头、查询参数或请求体中，例如 X-: sk_live_xxx。的本质是“身份标识 + 简单口令”的合体，优点是接入简单，缺点是一旦泄露，攻击者可直接冒用身份。

交易凭证（Transaction Credential）则更进一步，它不只是标识“你是谁”，还绑定了一次具体交易或一段时效窗口。常见形式包括支付令牌（Payment ）、一次性签名（Nonce + Signature）、临时访问令牌（STS ）。交易凭证通常具有时效性、单次性和范围限制，泄露后的可利用窗口远小于长期。

权限模型（Permission Model）描述的是“谁能对什么资源做什么操作”。常见模型包括：

• ACL（访问控制列表）：直接为每个资源列出可访问主体，简单但难以规模化。
• RBAC（基于角色的访问控制）：用户→角色→权限，适合组织内部系统。
• ABAC（基于属性的访问控制）：根据用户属性、资源属性、环境条件动态判断，灵活但实现复杂。
• OAuth 2.0 Scope：以授权范围字符串限定令牌能力，是开放平台最常用的细粒度模型。

认证（Authentication）回答“你是谁”，授权（Authorization）回答“你能做什么”。认证在前，授权在后；认证失败则授权无从谈起，认证成功但授权不足则返回403而非401。这一顺序在日志排查和接口设计中必须严格区分。

二、典型应用场景与风险概览

不同场景对凭证类型和权限模型的要求差异很大。下表列出四类常见场景及其主要风险：

从风险视角看，凭证类问题集中在三个方向：泄露（硬编码、日志打印、前端暴露）、越权（Scope过宽、角色继承混乱）、重放（缺少Nonce、时间戳、签名校验）。后续章节会逐一展开防护手段。

三、认证与授权的数据流

下面这张图展示了一次典型API调用中，凭证从客户端到服务端、再到权限判定与资源返回的完整路径。请重点观察“认证”和“授权”两个判定点的位置关系：

图中可见，认证服务与授权服务是两条独立判定路径。很多线上事故的根因，就是把两者合并成一个“检查密钥是否存在”的步骤，导致越权请求被放行。

四、常见误区与复盘要点