哔哩哔哩-API收集整理：接口调用凭证管理与安全存储-优快云博客

哔哩哔哩-API收集整理：接口调用凭证管理与安全存储

【免费下载链接】bilibili-API-collect 哔哩哔哩-API收集整理【不断更新中....】项目地址: https://gitcode.com/GitHub_Trending/bi/bilibili-API-collect

在开发哔哩哔哩（B站）相关应用时，接口调用凭证的正确管理与安全存储是确保应用稳定运行的核心环节。B站API采用多种鉴权机制，包括WBI签名、APP签名等，每种机制都有其特定的使用场景和安全要求。本文将详细介绍这些凭证的获取、生成、使用及安全存储方法，帮助开发者避开常见的鉴权陷阱。

凭证类型与应用场景

B站API的调用凭证主要分为两类：面向Web端的WBI签名和面向客户端的APP签名。两种凭证的适用场景和安全策略存在显著差异，需根据实际开发需求选择合适的鉴权方式。

WBI签名（Web端）

WBI签名（Web Interface签名）是B站Web端接口的主要鉴权方式，自2023年3月起广泛应用于查询类接口。其核心特征是在请求参数中添加w_rid（签名值）和wts（时间戳）字段，用于验证请求的合法性。

适用场景：浏览器环境下的API调用，如视频信息查询、用户动态获取等公开接口。
安全特点：依赖实时更新的img_key和sub_key生成签名，每日自动失效，降低长期凭证泄露风险。
官方文档：WBI签名算法详解

APP签名（客户端）

APP签名是B站移动客户端（如安卓、iOS）使用的鉴权方式，通过固定的appkey和appsec（密钥）对请求参数进行签名。与WBI签名不同，APP签名的密钥长期有效，因此对存储安全性要求更高。

适用场景：原生应用开发，如第三方客户端、数据分析工具等需要高频调用API的场景。
安全特点：appkey与appsec一一对应，一旦泄露可能导致接口滥用，需严格保密。
官方文档：APP签名算法详解

WBI签名：动态凭证生成与使用

WBI签名的核心在于动态生成签名参数，其流程包括获取实时密钥、生成混合密钥、计算签名值三个步骤。以下是详细实现方法及注意事项。

实时密钥获取

WBI签名依赖img_key和sub_key两个实时密钥，这些密钥隐藏在B站导航接口的响应中，以图片URL的形式返回。例如：

{
  "data": {
    "wbi_img": {
      "img_url": "https://i0.hdslb.com/bfs/wbi/7cd084941338484aae1ad9425b84077c.png",
      "sub_url": "https://i0.hdslb.com/bfs/wbi/4932caff0ff746eab6f01bf08b70ac45.png"
    }
  }
}

需提取URL中的文件名作为密钥：

img_key = 7cd084941338484aae1ad9425b84077c
sub_key = 4932caff0ff746eab6f01bf08b70ac45

注意：密钥每日更新，建议缓存并定时刷新（如每12小时更新一次），避免频繁请求导航接口导致IP被风控。

混合密钥生成

将img_key和sub_key拼接后，按照固定的重排表（MIXIN_KEY_ENC_TAB）打乱字符顺序，取前32位作为混合密钥（mixin_key）。重排表定义如下：

const MIXIN_KEY_ENC_TAB: [u8; 64] = [
  46, 47, 18, 2, 53, 8, 23, 32, 15, 50, 10, 31, 58, 3, 45, 35, 
  27, 43, 5, 49, 33, 9, 42, 19, 29, 28, 14, 39, 12, 38, 41, 13, 
  37, 48, 7, 16, 24, 55, 40, 61, 26, 17, 0, 1, 60, 51, 30, 4, 
  22, 25, 54, 21, 56, 59, 6, 63, 57, 62, 11, 36, 20, 34, 44, 52
];

示例代码（Python）：

def get_mixin_key(img_key, sub_key):
    raw_key = img_key + sub_key
    mixin_key = ''.join([raw_key[i] for i in MIXIN_KEY_ENC_TAB])[:32]
    return mixin_key

签名计算与请求构造

添加时间戳：生成当前Unix时间戳（wts），精确到秒。
参数排序：按参数名升序排列所有请求参数（包括wts）。
生成签名：将排序后的参数拼接为URL查询字符串，附加mixin_key后计算MD5值，得到w_rid。
构造请求：将w_rid和wts添加到原始请求参数中。

完整示例（Python）：

import time
import hashlib
import urllib.parse

def sign_wbi(params, img_key, sub_key):
    mixin_key = get_mixin_key(img_key, sub_key)
    params['wts'] = str(int(time.time()))
    sorted_params = sorted(params.items())
    query = urllib.parse.urlencode(sorted_params)
    w_rid = hashlib.md5((query + mixin_key).encode()).hexdigest()
    params['w_rid'] = w_rid
    return params

# 使用示例
params = {'foo': '114', 'bar': '514', 'baz': 1919810}
signed_params = sign_wbi(params, img_key, sub_key)
print(urllib.parse.urlencode(signed_params))

输出：

bar=514&baz=1919810&foo=114&wts=1702204169&w_rid=d3cbd2a2316089117134038bf4caf442

APP签名：静态密钥管理与安全实践

APP签名依赖固定的appkey和appsec，其流程相对简单，但密钥的安全存储至关重要。以下是签名生成方法及密钥保护策略。

签名生成流程

添加appkey：将appkey添加到请求参数中。
参数排序：按参数名升序排列所有参数。
计算签名：拼接排序后的参数为URL查询字符串，附加appsec后计算MD5值，得到sign。
构造请求：将sign添加到参数中并发送请求。

示例代码（Java）：

public String signApp(Map<String, String> params, String appkey, String appsec) {
    params.put("appkey", appkey);
    List<String> sortedKeys = new ArrayList<>(params.keySet());
    Collections.sort(sortedKeys);
    StringBuilder query = new StringBuilder();
    for (String key : sortedKeys) {
        query.append(key).append("=").append(URLEncoder.encode(params.get(key), "UTF-8")).append("&");
    }
    query.setLength(query.length() - 1); // 移除末尾&
    String sign = md5(query.toString() + appsec);
    params.put("sign", sign);
    return URLEncoder.encode(query.toString() + "&sign=" + sign, "UTF-8");
}

密钥安全存储

appsec是APP签名的核心密钥，一旦泄露可能导致接口被恶意调用。建议采用以下存储策略：

客户端加密存储：在移动应用中，可使用系统安全硬件（如Android Keystore、iOS Keychain）存储appsec，避免明文写入代码或配置文件。
服务端代理：将签名逻辑放在后端服务中，客户端通过调用后端API间接访问B站接口，避免appsec暴露在客户端。
动态密钥分发：通过安全通道（如HTTPS）动态下发appkey和appsec，定期轮换密钥。

风险提示：避免将appsec硬编码在前端代码中，反编译工具可轻易提取明文密钥。

风控处理与错误排查

在使用B站API时，常见的鉴权错误包括签名失效、风控拦截等。以下是典型错误码及解决方法。

常见错误码解析

错误码	含义	解决方案
-101	账号未登录	检查Cookie中的`SESSDATA`是否有效，重新登录获取新Cookie
-352	风控校验失败	验证WBI签名是否正确，检查`User-Agent`、`Referer`等请求头是否模拟浏览器环境
-412	IP被风控	更换IP或降低请求频率，必要时通过v_voucher进行验证

风控应对策略

当接口返回-352错误时，需通过以下步骤解除风控：

获取v_voucher：从错误响应中提取v_voucher字段或响应头x-bili-gaia-vvoucher。
申请验证：调用/x/gaia-vgate/v1/register接口，传入v_voucher获取验证参数。
验证信息：引导用户完成验证，获取grisk_id。
恢复请求：在原请求中添加gaia_vtoken=grisk_id参数，并在Cookie中设置x-bili-gaia-vtoken。

示例流程：

# 1. 获取v_voucher（假设从错误响应中得到）
V_VOUCHER="voucher_84a8c3ce-33f5-4551-9552-9c6b13aa7938"

# 2. 申请验证
curl -X POST "https://api.bilibili.com/x/gaia-vgate/v1/register" \
  -d "v_voucher=$V_VOUCHER"

# 3. 验证信息（需用户交互，此处省略）

# 4. 恢复请求
curl "https://api.bilibili.com/x/web-interface/nav?gaia_vtoken=$GRISK_ID" \
  -H "Cookie: x-bili-gaia-vtoken=$GRISK_ID"

凭证管理最佳实践

为确保API调用的稳定性和安全性，建议采用以下凭证管理策略：

缓存与刷新机制

WBI密钥：缓存img_key和sub_key，每12小时从导航接口刷新一次，避免频繁请求。
签名结果：对相同参数的请求，可缓存w_rid和wts，有效期为5分钟（避免时间戳过期）。

请求限流与模拟

控制频率：单个IP的API请求频率不超过10次/秒，避免触发B站反爬虫机制。
模拟浏览器：设置合理的User-Agent（如Chrome、Firefox）和Referer（如https://www.bilibili.com/）。

监控与告警

日志记录：记录所有API请求的状态码、响应时间，重点监控-352、-412等错误。
自动重试：对瞬时错误（如-503服务不可用）实现指数退避重试，最大重试次数不超过3次。

总结

B站API的凭证管理涉及WBI签名和APP签名两种机制，开发者需根据应用场景选择合适的鉴权方式。WBI签名适合Web端应用，动态密钥降低了泄露风险；APP签名适合客户端应用，但需重点保护appsec密钥。通过合理的缓存策略、风控应对和密钥管理，可有效提升API调用的稳定性和安全性。

扩展资源：

【免费下载链接】bilibili-API-collect 哔哩哔哩-API收集整理【不断更新中....】项目地址: https://gitcode.com/GitHub_Trending/bi/bilibili-API-collect

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考