密钥权限模型概述
密钥权限模型，说白了就是一套规则——谁，用哪个密钥，能对哪些资源干什么事。
你可能觉得这有什么好讲的？直接给每个用户发个密钥不就完事了？
嗯，我早年也这么想。结果第一个项目上线没两周，测试同学跑过来说：「A 用户拿到 B 用户的数据库连接串了。」我翻了一圈日志才发现，密钥发放和权限校验完全脱钩，等于把保险柜钥匙直接贴墙上。
所以，我们得认真聊聊这个模型。
什么是密钥权限模型
密钥权限模型，是一个结构化方案。它把「谁拥有密钥」、「密钥能做什么」、「能操作什么资源」这三件事拆开，再通过一套规则把它们绑定在一起。
我习惯把它理解成三件套：
- 身份层（Identity）：确定调用方是谁，比如用户 ID、服务账号、IoT 设备。
- 凭证层（Credential）：身份的具体钥匙，比如 、JWT、客户端证书。
- 权限层（Permission）：钥匙能开的锁，比如「只读」「写入」「管理」。
这三层不是平铺的。凭证绑定身份，身份关联权限，权限作用在资源上。你想想看，如果只发钥匙不管权限，那钥匙和万能钥匙没区别。如果只定权限不管钥匙，系统连谁来操作都认不出。
为什么需要把模型单独拎出来？因为实际场景里，这三个维度的变化频率完全不一样——
| 维度 | 变化频率 | 典型例子 |
|---|---|---|
| 身份 | 低（按月/季度） | 员工入职离职、服务拆分 |
| 凭证 | 高（按天/周） | 密钥轮换、泄露吊销 |
| 权限 | 中（按迭代/版本） | 新增接口、调整数据范围 |
我见过最坑的项目，把凭证和权限塞在同一个 JSON 结构里。结果每次改权限都要重新发密钥，线上服务的密钥轮换成本直接翻三倍。
为什么需要密钥权限模型
抛开理论，说三个我踩过的坑。
- 密钥泄露后灾难范围失控。一个前端 Key 因为被硬编码在 Git 仓库里，攻击者用这个 Key 直接调了后台管理 API。如果当时有这个模型，我们至少能把该 Key 的权限范围限定在「读取公开资源」，不至于连用户数据都被人拖走。
- 权限升级靠复制粘贴。新服务上线，开发同学说「给我一个跟支付服务一样的 Key」。结果复制过去，新服务有了支付划账权限。如果当时有一个权限模型，新服务会默认继承最小权限集，而不是拷贝历史包袱。
- 密钥轮换没法灰度。我前面提到那个三合一结构，换 Key 必须停服全量更新。每次轮换都要拉群、发公告、凌晨上线，大家叫它「密钥祭」。后来我们重构了权限模型，密钥只负责认证，权限靠策略中心动态下发，轮换时新老 Key 同时生效，灰度切流，再也不用人肉熬夜了。
总结一句话：这个模型的价值在于解耦——身份、凭证、权限各自独立演化，互不影响。系统扩展能力才真的释放出来。
核心应用场景
我从实际项目里提炼了四个最常用的场景。你会发现在每一个场景里，模型都在回答同一个问题：「这个密钥能被信任到什么程度？」
| 场景 | 典型需求 | 模型如何解决 |
|---|---|---|
| API 网关鉴权 | 不同客户端（Web、App、小程序）使用不同密钥，但都走同一组接入层 | 密钥绑定租户 ID + 租户内角色，网关只验证密钥有效性，权限由策略中心动态匹配 |
| 微服务间调用 | Service A 只能读用户信息，Service B 可写 | 每个微服务有独立服务账号，服务账号关联密钥，策略表约束目标资源与方法 |
| 第三方开放平台 | 开发者通过 AppKey + Secret 调用平台 API，且每个 App 的权限不同 | AppKey 映射到应用实体，实体关联 API 权限列表；Secret 仅作签名凭证，不携带权限 |
| IoT 设备认证 | 设备数量大、网络不可靠、密钥需要定期更换 | 设备证书作为凭证，证书里含有设备 ID；云端策略表定义设备可操作的物模型和数据范围 |
我特别想说一下第三个场景——开放平台。曾经有个客户的第三方应用调用我们的订单接口，明明只传了「读取最近30天订单」的权限，结果因为平台没做权限校验，这个应用直接删了别人的订单。问题出在哪？AppKey 本身没有绑「可写」还是「只读」——说白了就是少了权限模型。
那之后我们重新设计了体系：AppKey 只是身份标识，真正的权限写在策略里，每次调用都要过一遍策略引擎。虽然多了一次查询，但再也没出过越权事故。
模型的核心逻辑
我画了一张图帮助你理解这三个要素之间的关系。画布左上角是身份层，右下角是资源层，中间是策略绑定层——
图中你应该注意到了，我故意把凭证层放在中间。因为在实际设计里，凭证是唯一穿越网络的东西——外部永远不会直接拿到身份 ID 或权限列表，它们只看到凭证。而模型要保证，即使凭证泄露，攻击者也只能拿到凭证所关联的那部分权限，不会波及整个系统。
模型的两个经典设计误区
讲到这里，我提两个我反复看到团队掉进去的坑。
- 误区一：给每个用户单独生成一个「全能密钥」。 结果用户多了以后，吊销密钥变成噩梦——你不知道哪个用户还在用哪个密钥，也不敢随便删。
- 误区二：权限写死在密钥 payload 里。 比如 JWT 里直接放一个 permissions 数组。这样换权限就必须重新签发 JWT，而且很难做到「立即生效」——未过期的 JWT 还带着旧权限。我曾经重构过一个项目，把 payload 里的权限全部移到远端策略中心，上线后权限生效延迟从 24 小时降到 30 秒。
好了，第一章节的核心概念先到这里。你大概能感觉到，密钥权限模型不是什么高深理论，它就是在回答一个朴素的问题：谁，用什么，能碰什么。后面我们会一步步把这个模型落地成接口、策略引擎、风险控制——到时候你会发现，今天画的这张三层图，就是整条设计线的骨架。