115网盘认证风控及其PKCE认证码原理解析

近年来，115网盘的风控措施明显加强，使得许多用户在抓取网盘数据时遭遇困难。本文将探讨115网盘的认证风控机制，并解析PKCE认证码原理。

115网盘的风控主要体现在以下几个方面：

1. 单账号API限流：超过3次请求即触发限流，返回code:0。
2. 单账号第三方APP挂载限制：只允许挂载一个服务，若使用多个服务器挂载，第一个服务的刷新token请求会导致第二个服务的token失效。
3. 禁止个人开发者认证：由于第二点的限制，第三点的限制显得不那么重要。

115网盘的风控主要针对的是批量刮削、黑产扫号以及滥用官方API的行为。传统的第三方网盘工具往往将开发者申请的AppKey和AppSecret硬编码在源码中，一旦代码被开源或逆向，黑产就会利用这些信息进行恶意请求，从而触发官方的风控机制。

为了解决静态密码被盗用的问题，115的开放平台采用了带有PKCE（Proof Key for Code Exchange）扩展的OAuth 2.0设备码模式。PKCE的核心原理是舍弃固定密码，通过以下步骤实现安全认证：

1. 本地造锁：客户端生成一个随机字符串code_verifier，并哈希加密成code_challenge。
2. 提交登记：客户端向115服务器请求二维码，并附上code_challenge。
3. 扫码放行：用户扫码确认后，客户端使用code_verifier换取token。115服务器验证code_verifier的哈希值，若匹配则下发token。

PKCE的安全性在于code_verifier仅存在于客户端内存中，且为一次性使用，即使被截获也无法换出token。

然而，开源挂载工具在使用PKCE时面临挑战，因为它们通常使用同一个高权限的官方client_id。这导致大量用户使用相同的ID向115发送请求，一旦115开始按IP或行为特征限流，这些ID就会出现大面积的token刷新失败。

作者提到，他们逆向了115的PKCE轮换机制，并开发了一个绕过工具，能够稳定地解决单账号多服务器同时挂载的问题。作者询问用户是否需要这样的服务，并考虑将其开放出来。

综上所述，115网盘的风控机制和PKCE认证码原理为用户提供了更安全的认证方式，但同时也给开源挂载工具带来了挑战。未来，如何平衡安全性和便利性将是115网盘和其他类似服务需要考虑的问题。