API鉴权常见方法解析
在开发网站或移动应用时，调用第三方服务几乎都绕不开API。比如你做个天气小程序，得请求气象站的数据；做个登录功能，可能要对接微信或支付宝的开放接口。这些API不是谁都能随便调的，就像银行账户不能让陌生人操作一样。于是就有了“鉴权”这道门，用来确认来者是否合法。
常见的API鉴权方式有好几种，各有各的适用场景，下面挑几个常用的说说。
1. API Key
这是最简单的做法。每个开发者申请后会得到一个唯一的字符串，叫API Key，发请求时把它带上就行。比如你调用某个地图服务，URL可能长这样：
https://api.map.com/v1/location?city=北京&apikey=abc123xyz服务器收到请求后，核对这个key是否有效，有效就返回数据。这种方法实现简单，适合内部系统或对安全性要求不高的场景。但它有个明显缺点：key通常明文传，一旦泄露，别人就能冒用。
2. Basic Auth
这种方式把用户名和密码拼在一起，用Base64编码后放在请求头里。比如用户名是user，密码是pass，组合成user:pass，编码后变成dXNlcjpwYXNz，然后在HTTP头里这么写：
Authorization: Basic dXNlcjpwYXNz虽然看起来加密了，但Base64只是编码不是加密，随便一解就能看到原始信息。所以它必须配合HTTPS使用，否则等于裸奔。这种方案现在用得少了，多见于一些老系统或者测试环境。
3. Token机制（如Bearer Token）
现在很多API用Token，尤其是OAuth 2.0流行之后。用户先登录换取一个临时Token，后续请求都把这个Token放进Authorization头：
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...这个Token通常有过期时间，即使被截获，危害也有限。像微信小程序获取用户信息、GitHub开放API，都是这么干的。开发者不用管用户密码，只凭Token办事，安全又方便。
4. HMAC签名
这种方式更讲究一点。客户端和服务器事先约定一个密钥（Secret），每次发请求时，把参数按规则排序，连同请求路径、时间戳等信息，用HMAC算法算出一个签名，一起发过去。
比如你要查订单状态，除了传order_id，还得加个sign字段：
GET /api/order?order_id=888×tamp=1712345678&sign=a1b2c3d4e5服务器拿到请求后，按同样的规则自己算一遍，看签名对不对。这种方式不怕参数被篡改，也不怕重放攻击（可以靠时间戳限制），常用于支付、金融类接口。
5. OAuth 2.0
如果你做过第三方登录，大概率碰过OAuth 2.0。它不是直接给Token，而是走一套授权流程。比如你点“用微信登录”，跳转到微信页面，同意后才拿到授权码，再换Token。
整个过程用户密码不会交给第三方应用，安全性高。虽然流程复杂点，但适合需要访问用户私有数据的场景，比如网盘同步、社交分享。
实际项目中选哪种方式，得看需求。小项目用API Key省事，涉及用户数据的上Token，对安全要求高的考虑HMAC或OAuth。没有万能方案，合适最重要。