SaaS API 应该如何验证用户身份，API Key 和 Token 有哪些区别

SaaS平台的API一旦开放给浏览器、移动应用、第三方软件或企业客户，第一道安全防线就是身份认证。服务器必须知道“这个请求是谁发来的”，然后才能继续判断“这个人或者这个应用可以访问什么”。因此，API Key和Token虽然经常被放在一起讨论，但它们解决的并不是完全相同的问题。API Key通常更接近一个长期凭证或调用者标识，而Token可以代表一次授权结果，也可以承载用户、客户端、权限范围和有效期等信息。

很多开发者第一次设计SaaS API时容易把认证和授权混为一谈。认证解决的是身份问题，授权解决的是权限问题。例如，一个请求带着有效Token，并不意味着它可以访问任意客户的数据。服务器还必须确认这个用户属于哪个租户、拥有哪个角色、是否具有访问指定资源的权限，以及当前业务状态是否允许执行操作。对于多租户SaaS，这一点尤其重要，因为“Token有效”与“可以访问这个数据库记录”完全是两个层次。

API Key最简单的工作方式，是由服务器生成一段随机凭证，例如一串不可预测的字符串，客户端在调用API时通过请求头提交。服务器根据这个Key找到对应的调用者、应用、租户或者权限配置，然后决定是否接受请求。它可以非常简单，也可以做得相当完善。API Key本身并不意味着低安全性，安全程度主要取决于密钥长度、随机性、保存方式、传输方式、权限范围、轮换机制、撤销机制以及服务器端的验证逻辑。

API Key特别适合服务器到服务器的集成。例如一家企业购买SaaS服务后，希望自己的后台系统定期调用供应商API同步订单、客户或者库存数据，这种场景往往并不需要模拟一个用户登录过程。为企业应用创建一个具有明确权限范围的API Key，然后通过HTTPS调用接口，往往比完整实现OAuth流程更加直接。

不过，API Key最大的工程问题在于生命周期。如果一个Key长期有效，而且拥有很大的权限，一旦泄露，攻击者就可能在很长时间内冒充原来的调用者。仅仅把Key放在数据库里保存，并不能解决这个问题。生产环境通常应该为Key建立唯一标识、哈希后的密钥值、创建时间、最后使用时间、过期时间、状态、权限范围以及所属租户等属性，同时提供撤销和轮换机制。

服务器甚至没有必要保存完整的API Key。可以将随机生成的高熵密钥只在创建时展示给用户，数据库保存经过安全哈希处理的结果以及一个可用于识别的Key ID。客户端每次请求提交完整Key，服务器根据Key ID定位记录，再验证密钥。这样即使数据库发生泄露，也不会直接暴露所有可用凭证。

Token则是一个更加宽泛的概念。Token只是“用于证明某种授权或身份状态的凭证”，并不规定必须使用JWT，也不规定一定由OAuth 2.0生成。OAuth 2.0解决的是授权框架问题，JWT解决的是一种Token的封装和签名格式，两者不能简单画等号。

例如，一个OAuth 2.0授权服务器可以向客户端签发Access Token。这个Access Token可以是JWT，也可以是不透明字符串。对于不透明Token，API服务器收到Token后可能需要向授权服务器或者共享存储查询其状态；对于JWT，API服务器可以在本地验证签名并读取其中的声明。两种架构各有取舍，并不存在“JWT天然比不透明Token安全”的结论。

JWT本身也不是“加密令牌”的同义词。很多JWT采用数字签名，用于保证Token内容没有被篡改，但签名并不等于加密。如果Token中包含用户ID、租户ID、权限范围等Claims，在普通签名JWT中，这些内容通常可以被读取。因此，不应该把密码、API Secret或者其他不应该暴露给客户端的敏感信息放进普通JWT。

JWT通常包含诸如iss、sub、aud、exp、iat、nbf以及scope等声明。API服务器除了验证签名，还应该检查签发者、受众、有效期以及权限范围。对于不同的Token类型，还可能涉及jti等标识，用于撤销、重放检测或者审计。安全验证不能只做一个“签名正确”判断。

Token的有效期设计也是工程系统的重要部分。Access Token通常设置相对较短的生命周期，客户端在适当情况下使用Refresh Token获得新的Access Token。Refresh Token本身需要受到更加严格的保护，因为它的生命周期通常比Access Token长。对于高安全等级系统，还需要考虑Refresh Token轮换、撤销、客户端绑定以及异常使用检测。

这里有一个经常出现的误解：Token有过期时间，并不意味着它可以自动防止重放攻击。如果攻击者窃取了一个尚未过期的Bearer Token，在服务器没有额外绑定机制的情况下，攻击者通常可以直接使用这个Token。因此，短生命周期只是降低风险窗口的一种手段，并不是完整的防重放方案。对于风险更高的接口，还可以考虑Sender-Constrained Token、DPoP、mTLS等机制，使窃取Token后不能轻易在另一台机器上直接使用。

HTTPS同样不能被Token机制替代。API Key、Bearer Token、JWT以及Session Cookie都可能被窃取，如果它们通过明文HTTP传输，攻击者可以直接获得凭证。TLS负责保护传输过程，Token或者API Key负责提供身份或授权凭证，两者承担不同职责。

在浏览器应用中尤其需要谨慎。把长期API Key硬编码到JavaScript、网页源代码或者公开移动应用中，并不能称为安全的秘密管理。浏览器中的任何客户端秘密都应该假设可能被最终用户或者攻击者获得。如果前端需要代表用户调用SaaS API，更合理的架构通常是采用用户认证机制和短生命周期访问凭证，并由后端承担需要保护的秘密，而不是把长期服务端密钥直接塞进浏览器。

多租户SaaS还有一个比Token格式更加重要的问题，那就是租户隔离。假设Token中包含tenant_id=100，那么API服务器不能因为这个字段存在于Token里，就直接把它当作访问权限的唯一依据。服务器还应该从认证结果确定当前身份，再根据服务端保存的用户与租户关系确认访问范围。资源查询也必须带有租户边界。例如查询订单时，不能只执行“根据订单ID查询”，而应该确保这个订单属于当前授权范围。

同样的原则适用于RBAC和Scope。角色可以决定用户具有什么能力，例如读取订单、修改订单或者管理用户；Scope则可以进一步限制Token可以调用哪些API。对于复杂SaaS，还需要结合资源所有权、部门范围、项目范围以及业务状态进行判断。前端隐藏一个按钮不属于权限控制，真正的权限检查必须发生在API服务器端。

API Key同样可以拥有Scope，因此“API Key不能进行细粒度授权”也是错误的。完全可以为不同Key分配不同权限，例如一个Key只允许读取订单，另一个Key允许创建订单，而第三个Key只能访问报表接口。区别在于，开发者需要自己设计和维护这套权限体系，而OAuth 2.0等标准协议可以提供更加完整的授权流程和生态支持。

在实际SaaS系统中，API Key和Token甚至可以同时存在。例如企业后台通过API Key识别一个长期存在的机器客户端，而用户登录后获得Access Token访问用户级接口。也可以在API Gateway层先识别客户端，再由业务服务根据用户Token完成用户身份和权限判断。两种凭证承担不同角色，并不一定意味着所谓“双因素认证”。

性能方面，原稿把JWT验证描述成需要GPU或者“AES-NI加速”是不准确的。JWT签名验证通常属于CPU上的密码学操作，具体算法可能涉及RSA、ECDSA或者EdDSA等；AES-NI主要用于AES对称加密和相关操作，并不是JWT签名验证的通用加速器。对于大多数SaaS API，JWT验证本身通常并不是系统最主要的性能瓶颈，数据库查询、网络通信、业务逻辑、日志以及下游服务调用往往更值得优化。

API Key验证也并不一定只是简单的字符串比对。如果系统规模较大，可以使用Key ID进行快速定位，再对密钥执行安全验证，并结合缓存减少数据库访问。Token验证同样可以缓存公钥、减少重复密钥获取或者采用本地签名验证。真正需要关注的是整体请求路径，而不是简单地比较“API Key快还是JWT快”。

速率限制应该独立于身份认证设计。无论请求使用API Key、Access Token还是其他认证方式，都应该根据实际业务设置Rate Limit。限制维度可以包括IP、用户、API Key、租户、客户端应用以及具体Endpoint。对于登录、Token签发、密码重置等接口，还需要特别防止凭证枚举和暴力尝试。

但Rate Limit也不能被描述成DDoS防护。应用层限流主要解决的是服务资源被单个调用者或者大量合法请求耗尽的问题，而大规模DDoS通常需要网络层、CDN、WAF、负载均衡器以及上游基础设施共同处理。两者属于不同的防护层次。

日志和审计同样不能缺失。生产环境至少应该能够追踪认证失败、Token签发和撤销、API Key创建与轮换、权限拒绝、异常访问以及高频调用等事件。日志中不要直接记录完整API Key、完整Bearer Token或者其他长期凭证，否则一旦日志系统泄露，攻击者可能从另一个入口获得同样的访问能力。

如果从SaaS工程实践出发，可以把整个API安全体系拆成几个层次。第一层是传输安全，所有认证凭证通过HTTPS传输。第二层是身份认证，确认请求来自哪个用户、应用或者服务。第三层是授权，确认这个身份能够执行什么操作。第四层是数据范围，确认它能够访问哪个租户、项目、资源或者记录。第五层是业务规则，确认当前订单、账户、订阅或者交易状态是否允许执行该操作。第六层是审计、限流、异常检测和撤销机制。

因此，API Key和Token并不存在一个简单的“谁更安全”的答案。一个设计良好的API Key系统可以拥有强随机性、明确权限、过期时间、轮换、撤销、审计和租户隔离；一个设计糟糕的JWT系统也可能因为Token泄露、签名算法配置错误、错误信任Claims或者权限检查缺失而产生严重漏洞。

对于服务器到服务器的长期集成，API Key往往仍然是非常实用的方案。对于用户登录、第三方授权、跨系统委托以及需要标准授权流程的场景，OAuth 2.0和短生命周期Access Token通常更加合适。对于大型SaaS平台，最终采用的往往不是二选一，而是根据客户端类型和业务边界同时使用API Key、OAuth 2.0、Access Token以及内部服务身份机制。

设计API认证系统时，最重要的指标并不是Token长什么样，而是服务器能否始终准确回答四个问题：请求是谁发起的，这个身份属于哪个租户，它拥有访问什么资源的权限，以及当前业务状态是否允许执行这个操作。只要这四个层次没有被清楚分开，即使使用最新的Token格式，也无法弥补权限模型本身的缺陷。