2. 核心概念：认证（Authentication）、授权（Authorization）、审计（Auditing）三要素详解
在构建 Go 权限审计网关时，认证（Authentication）、授权（Authorization）、审计（Auditing） 是支撑整个安全体系的三大支柱，通常简称为 3A。三者相互独立又紧密协作，共同保障 API 接口的安全性与可追溯性。理解三者的定义、职责与交互关系，是设计网关契约的基础。
核心记忆口诀：“认证验身份，授权定权限，审计留证据”。三者缺一不可，顺序不可颠倒。
2.1 三要素定义与职责对比
下表从核心问题、输入输出、失败后果三个维度，清晰界定三者的边界：
| 要素 | 核心问题 | 输入 | 输出 | 失败后果 |
|---|---|---|---|---|
| 认证 (Authentication) | 你是谁？ | 凭证（Token、密码、证书） | 身份标识（User ID / Subject） | 拒绝访问（401 Unauthorized） |
| 授权 (Authorization) | 你能做什么？ | 身份标识 + 资源请求 | 允许/拒绝决策（Allow / Deny） | 禁止访问（403 Forbidden） |
| 审计 (Auditing) | 你做了什么？ | 请求上下文 + 决策结果 | 不可篡改的日志记录 | 无法追溯安全事件 |
网关契约中的 HTTP 状态码映射：认证失败返回
401，授权失败返回 403。审计本身不返回状态码，但审计日志的缺失会导致合规性检查失败。
2.2 三要素在网关中的执行流程
在 Go 权限审计网关中，3A 的执行顺序是严格线性的：先认证 → 再授权 → 最后审计。任何一步失败，后续步骤都不会执行。下面通过一个内联 SVG 流程图展示完整的请求处理链路：
2.3 认证（Authentication）深度解析
认证解决的是 “你是谁？” 的问题。在 Go 网关中，常见的认证方式包括：
- JWT（JSON Web Token）：无状态认证，网关验证签名与有效期，提取用户身份。
- OAuth 2.0 / OpenID Connect：委托授权协议，网关作为资源服务器验证 Access Token。
- mTLS（双向 TLS）：基于证书的客户端身份认证，适用于服务间通信。
- API Key：简单的静态令牌，适用于内部服务或合作伙伴。
常见误区：认证通过不代表请求安全。认证只确认了身份，但未判断该身份是否有权限执行操作。授权必须在认证之后独立执行。
2.4 授权（Authorization）深度解析
授权解决的是 “你能做什么？” 的问题。网关根据认证阶段获取的身份信息，结合资源请求，做出允许或拒绝的决策。主流授权模型包括：
| 模型 | 核心概念 | 适用场景 | Go 实现示例 |
|---|---|---|---|
| RBAC | 用户 → 角色 → 权限 | 企业内部管理系统 | casbin 库 |
| ABAC | 基于属性（用户、资源、环境） | 多租户、动态策略 | OPA (Rego) |
| ACL | 用户/组 → 资源操作列表 | 文件系统、简单 API | 自定义 map 结构 |
2.5 审计（Auditing）深度解析
审计解决的是 “你做了什么？” 的问题。它记录所有经过网关的请求与响应，形成不可篡改的日志，用于事后追溯、合规审查和异常检测。审计日志的关键字段包括：
- 时间戳：请求到达网关的精确时间（RFC3339 格式）。
- 请求者身份：认证阶段提取的 User ID / Client ID。
- 请求详情：HTTP 方法、路径、查询参数、请求头（脱敏后）。
- 授权决策：Allow / Deny，以及决策依据的策略 ID。
- 响应状态：HTTP 状态码、响应体大小、处理耗时。
Go 网关审计最佳实践：使用
middleware 模式，在请求处理完成后异步写入审计日志，避免阻塞主流程。推荐使用结构化日志库（如 zerolog 或 slog）输出 JSON 格式，便于后续接入 ELK 或 Loki。
2.6 三要素的依赖关系与契约设计
在网关接口契约中，3A 的依赖关系决定了中间件的注册顺序。下面通过第二个 SVG 图展示三要素之间的数据流与依赖关系：
2.7 本章小结
- 认证是网关的第一道防线，负责验证请求者身份，输出
Subject。 - 授权是第二道防线，基于身份和策略做出访问决策，输出
Allow/Deny。 - 审计是最后一道保障，记录所有操作，输出不可篡改的日志。
- 三者在网关中按 AuthN → AuthZ → Audit 的顺序执行，任何一步失败都会中断流程。
- 接口契约必须明确定义三者的输入输出格式、错误码和日志规范，才能保证网关的可维护性与可审计性。