我发送了推送通知，其中包含一个APNs验证密钥（＆＃34;永不过期＆＃34;），直到我突然得到它才能正常工作
403 Forbidden: {"reason":"InvalidProviderToken"}
作为发送推送通知时的响应。当它工作一次并突然没有失效日期时，这可能是什么原因？与此同时，它再次推动了一些推动，但现在我又得到了错误......还有其他人经历过这个吗？
修改
不确定，但好像这只发生在Ubuntu服务器上，而不是在我的本地（OS X）机器上......
答案 0 :(得分：3)
我在几种情况下都看到了这一点：
重新提交过期的提供商令牌似乎会将令牌列入黑名单，并导致后续的InvalidProviderToken拒绝，而不是ExpiredProviderToken拒绝。检查日志是否有令牌到期消息。检查系统时钟，确保您没有生成时间戳偏斜的令牌。
提交到无效主题将使连接上的所有提供者令牌无效（甚至以前有效的提供者令牌）。仅提交密钥绑定的主题，每个连接仅使用一个密钥。
答案 1 :(得分：1)
服务器确实以InvalidToken和/或ExpiredToken错误响应。您的身份验证令牌不应包含任何'='，'+'，' - '，请仔细检查您的令牌是否包含任何此令牌。签名（令牌的第3部分，应该是Base64URL编码，所以没有前面提到的字符）。
答案 2 :(得分：1)
使用相同的连接向不同的团队ID发送推送时，我们遇到了完全相同的问题。重现的步骤是：
打开与APNS的连接，并使用相同的连接：
将基于令牌的推送发送到团队ID com.companyA.xxx的主题1234：APNS成功接受并推送推送。
io.companyB.xxx的主题5678：APNS回复HTTP 400 BadRequest The device token does not match the specified topic io.companyB.xxx的主题5678：APNS回复HTTP 403 Forbidden: the provider token is not valid or the token signature could not be verified。此后无法发送任何推送，必须关闭并重新打开连接。
我们最终做的解决方法是打开一个连接每个团队ID 。 APNS documentation没有提到类似的内容，所以我认为这是一个错误，我打开了一个错误报告。
答案 3 :(得分：1)
对我来说服务器时间无效，修复服务器时间解决了问题
答案 4 :(得分：0)
对我来说，配置有问题。我使用了错误的团队ID。在研究任何其他解决方案之前，请确保所有配置正确。
答案 5 :(得分：0)
我一直在使用密钥名称而不是密钥ID。在https://developer.apple.com/account/resources/authkeys/review/上进行验证显示了正确的值。
答案 6 :(得分：0)
我的情况是使用JSON漂亮打印格式。与Musickit可以接受jwt漂亮的打印格式不同，APN仅接受原始格式。
详细信息： 我的留言是：
{
"alg": "ES256",
"kid": "SOMEKEYID"
}
{
"iss": "SOMETEAM",
"iat": 1581110460
}
我通过jwt.io验证了结果jwt，但是APN不断告诉我InvalidProviderToken。我已经尝试了以上所有内容。没用。
最后，我将消息更改为：
{"alg":"ES256","kid":"SOMEKEYID"}
{"iss":"SOMETEAM","iat":1581128155}
然后它顺利通过。
结果是APNs不接受json漂亮格式！
答案 7 :(得分：-1)
Apple的APN documentation说：
APN仅支持使用签名的提供程序身份验证令牌 ES256算法。不安全的JWT [JSON Web Tokens]或JWT签名 与其他算法一起被拒绝，您的提供商服务器收到 InvalidProviderToken（403）响应。
所以，似乎问题不在于您的身份验证;它实际上是从您的密钥生成的Web令牌的问题。