API签名Token通过HMAC算法结合密钥与请求参数生成哈希值,用于验证请求完整性,需包含时间戳防重放,密钥应安全存储并定期轮换,服务端比对Token与重计算哈希
API 签名 Token 详解
什么是 API 签名 Token?
API 签名 Token 是一种用于验证 API 请求合法性的安全机制,通过加密算法对请求参数进行签名,服务器可校验签名的正确性,从而确认请求未被篡改且来源可信。
签名 Token 的组成要素
要素 | 说明 |
---|---|
密钥(SecretKey) | 服务器与客户端共享的私密数据,用于生成和验证签名。 |
待签参数 | 请求中的关键参数(如时间戳、随机数、业务参数等),需参与签名计算。 |
加密算法 | 常见算法:HMAC-SHA256、HMAC-SHA1、RSA 等。 |
签名 Token 生成流程
获取签名所需参数
- 时间戳(Timestamp):防止重放攻击(如
1620000000
)。 - 随机数(Nonce):防止重复请求(如
random123
)。 - 业务参数:请求中的动态数据(如
orderId=1001
)。 - 密钥(SecretKey):服务器与客户端约定的私密字符串。
拼接待签字符串
将参数按固定规则拼接(如字典序排序后合并):
timestamp=1620000000&nonce=random123&orderId=1001
计算签名
使用密钥和加密算法生成摘要:
import hmac, hashlib, base64 def generate_signature(secret, message): # 创建 HMAC-SHA256 对象 signature = hmac.new(secret.encode(), message.encode(), hashlib.sha256).digest() # 转为 Base64 编码 return base64.b64encode(signature).decode() # 示例调用 secret = "my_secret_key" message = "timestamp=1620000000&nonce=random123&orderId=1001" token = generate_signature(secret, message)
生成最终 Token
将签名附加到请求参数中:
{ "timestamp": 1620000000, "nonce": "random123", "orderId": 1001, "signature": "Base64EncodedSignature" }
签名验证流程(服务器端)
- 提取客户端传递的参数(如
timestamp
,nonce
,orderId
,signature
)。 - 根据相同规则拼接待签字符串。
- 使用相同密钥和算法计算服务器端的签名。
- 对比客户端签名与服务器签名:
- 一致:请求合法,继续处理。
- 不一致:拒绝请求(可能是篡改或过期)。
常见签名算法对比
算法 | 安全性 | 性能 | 适用场景 |
---|---|---|---|
HMAC-SHA256 | 高 | 高 | 通用 API 签名(推荐) |
HMAC-SHA1 | 中 | 高 | 低安全要求场景 |
RSA | 极高 | 低 | 高安全场景(如金融、支付) |
注意事项
- 时间同步:客户端与服务器时间差需小于允许阈值(如 5 分钟)。
- 参数排序:待签参数需按固定顺序(如字典序)排列,避免签名不一致。
- 空值处理:明确空参数是否参与签名(建议统一处理规则)。
- 密钥管理:密钥需定期更换,且不可硬编码在客户端代码中。
相关问题与解答
问题 1:API 签名 Token 能防止哪些攻击?
解答:
- 篡改攻击:签名校验可检测参数是否被修改。
- 重放攻击:结合时间戳和随机数,拒绝过期或重复的请求。
- 伪造请求:密钥不公开,攻击者无法生成合法签名。
问题 2:签名失败的可能原因有哪些?
解答:
| 原因 | 解决方案 |
|————————-|—————————————|
| 时间戳过期 | 同步客户端与服务器时间,调整允许误差范围 |
| 参数顺序错误 | 严格按照约定规则排序参数 |
| 密钥不匹配 | 检查客户端与服务器是否使用相同密钥 |
| 编码格式不一致 | 统一使用 UTF-8 或 Base6
到此,以上就是小编对于“api 签名 token”的问题就介绍到这了,希望介绍的几点解答对大家有用,有任何问题和不懂的,欢迎各位朋友在评论区讨论,给我留言。
【版权声明】:本站所有内容均来自网络,若无意侵犯到您的权利,请及时与我们联系将尽快删除相关内容!
发表回复