常见的API接口鉴权方式有哪些？
在开发系统软件时，API接口成了前后端、微服务之间沟通的桥梁。但桥修好了，怎么防止外人随便上桥乱逛？这就得靠鉴权机制。就像小区门禁卡，不是谁拿着手机模拟一下就能进你家楼。
HTTP Basic Auth：最基础的“用户名+密码”组合
这种方式简单直接，把用户名和密码拼成字符串，用Base64编码后放在请求头里。比如：
Authorization: Basic dXNlcjpwYXNzd29yZA==虽然实现容易，但Base64只是编码不是加密，明文信息在网络上传输风险高，一般得搭配HTTPS使用。适合内部系统或测试环境，公网暴露的接口不建议用。
API Key：给每个调用者发一张“通行证”
很多开放平台都用这招，比如天气API、地图API。开发者申请一个Key，每次请求带上它，服务端验证是否合法、有没有权限。
GET /api/weather?city=beijing&apikey=abc123xyz或者放在Header里：
Authorization: Apikey abc123xyz优点是实现简单，缺点是Key一旦泄露就等于大门敞开。有些公司会结合IP白名单限制，相当于“只允许从你公司网络使用这张卡”。
Token机制：登录后发个临时令牌
用户登录成功后，服务器生成一个Token（比如JWT），返回给客户端。之后每次请求都带上这个Token，服务端校验有效期和签名。
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.xxxxxJWT特别常见，结构分三段：头部、载荷、签名。载荷里可以放用户ID、角色、过期时间等信息，不用查数据库也能知道基本权限。
OAuth 2.0：第三方登录背后的授权逻辑
当你用微信登录某个App时，其实走的就是OAuth流程。它不直接暴露你的账号密码，而是让用户授权“某个应用可以访问我的部分信息”。
整个过程涉及四个角色：资源拥有者（你）、客户端（第三方App）、授权服务器（微信）、资源服务器（用户数据）。最终拿到的是一个短期Access Token，即使泄露影响也有限。
签名机制：每个请求都自带“防伪标签”
电商、支付类系统常用这种。比如你调用下单接口，除了传参数，还得算一个签名（Signature），算法通常是把所有参数按规则排序，加上密钥，用HMAC-SHA256生成。
服务端收到请求后，按同样规则再算一遍，对比签名是否一致。哪怕中间人改了一个字符，签名就对不上。
sign=HMACSHA256(params + secretKey)像阿里云、腾讯云的API基本都这么干，安全性高，但对接起来稍微麻烦点，得两边算法完全一致。
双向TLS：连握手都得验证身份
金融级系统有时会用mTLS（Mutual TLS），不仅客户端验证服务器证书，服务器也要求客户端提供证书。相当于进机房不仅要刷卡，还得刷指纹。
配置复杂，维护成本高，但能有效防止伪造请求，适合银行、核心交易系统这类高安全场景。
如何选择合适的鉴权方式？
没有哪种方式通吃所有场景。如果你做个内部管理系统，用API Key+HTTPS足够；做开放平台，就得考虑OAuth；涉及用户敏感操作，JWT配合刷新机制更合适；要是对接支付或金融通道，签名或mTLS才是标配。
实际项目中，往往是多种方式组合使用。比如先用OAuth获取Token，再用Token调用具体接口，关键操作再加一次签名验证。安全是个层层设防的事，别指望一招解决所有问题。