iOS删号场景下如何校验Apple登录撤销Token接口的真实执行结果

核心原因 #

苹果/auth/revoke接口本身就是按OAuth2.0令牌撤销的标准规范（RFC7009）设计的，返回200空响应的语义本来就是「当前令牌已经处于失效状态，撤销操作完成」，从接口设计上就不会告诉你是这次调用刚把它撤了，还是它之前就已经失效了。
你测出来乱填client_secret、乱传token也返回200，这不是接口出问题了，是苹果故意做的防枚举安全机制：不管参数对不对，只要请求格式没问题就统一返回200，防止攻击者靠不同响应撞库猜合法的客户端密钥、用户令牌。

实际落地的校验方法 #

别想着从revoke接口的响应里抠信息区分场景，按下面的流程走，既过审核又能保证逻辑真的生效：

• 先在本地把参数校验做严，别把瞎填的参数往苹果发
  生成client_secret的时候，本地先核对JWT的算法、kid、团队ID、包名、有效期这些字段，和你开发者后台配置的对不上就直接打日志报错，不要发请求；要撤销的token必须是你自己数据库里存的、对应当前要删号的那个用户的苹果授权令牌，随机生成的字符串、别的用户的token直接在业务层拦住。
• 调完revoke接口后二次验token有效性
  拿到200响应别直接算成功，紧接着调苹果的令牌校验接口查你刚才撤的那个token的状态：如果查回来报token无效，就说明撤销确实生效了；如果查回来token还是有效的，那肯定是你之前传的参数有问题（比如client_id和token不匹配、私钥签名错了），赶紧排查配置重试。
• 合规层面不用纠结两种200场景的区别
  苹果的审核要求只看你在用户删号的时候有没有调用撤销接口、最终用户的令牌是不是失效，不管这个令牌是你这次调用撤的，还是之前就过期/被用户手动撤了。只要你参数传对、调完接口token确实失效，就完全满足要求。

测试踩坑提醒 #

你用curl传乱写的参数拿到200是正常的，这种请求苹果后端根本不会处理，就是返回个统一响应骗攻击者的。测试的时候用你自己账号下真实生成的有效client_secret、真实拿到的用户授权token测，调完再查token状态，就能看到明确的失效结果，不会有问题。

内容的提问来源于stack exchange，提问作者zangw