IAP 收据服务器端验证的最小配置：JWS 时代

2026/9/17

背景与问题

IAP 被伪造购买（越狱/抓包重放）是付费产品的真实风险。solo 的最小防御：客户端收据只当提示，服务器端验证才是授权依据。整理 2026 年的 JWS 验证最小路径（Play 侧见 opc-ci-fastlane-pipeline 的 API 基础）。

（来源访问日期均为 2026-09-17）

事实（Apple WWDC23「Meet the App Store Server Library」）：现代流程=App Store Server API + JWS 签名的事务验证 + App Store Server Notifications（JWS 签名）——官方服务器库（Python/Node/Java/Go/Swift）可用。
事实（Adapty 实务指南 2025-08）：旧 /verifyReceipt 端点已废弃——社区报错 21002 的混乱多源于仍在打旧端点；迁移方向是 Server API v1/v2 + JWS。
事实（最小路径，多来源一致）：StoreKit 2 端取 transaction.jwsRepresentation → 服务器验证 JWS 证书链（Apple Root CA）→ 授权权益；或者干脆以 Server Notifications V2 为唯一事实源（推送到达再授权，少一个主动查询路径）。
推测：solo 的最小安全姿势是「Notifications V2 为主 + 客户端 JWS 校验为辅」——不维护主动查询逻辑，靠 Apple 推送驱动授权；通知丢失的场景用「打开 app 时对可疑权益补一次查询」兜底。

立刻检查：还在调 /verifyReceipt 的代码 = 迁移清单第一项（Apple 官方 app-store-server-library 直接换，半天级）。
最小配置三件套：①StoreKit 2 交易直传服务器 ②服务器验 JWS 链 ③Server Notifications V2 作为权益事实源（c-store-server-notifications 的事件体系直接复用）。
验证后的授权模型：服务器维护 entitlement 表（user_id → 有效交易 ID），app 启动时只问服务器「我有什么权限」——永远不信客户端缓存。
Play 侧对应：Play Developer API 的 RTDN + purchases.products.get 校验，同一张 entitlement 表两端共用（双端产品的统一收口）。