【问题标题】：iOS push notifications using TLS certificate vs. using authentication tokens使用 TLS 证书与使用身份验证令牌的 iOS 推送通知
【发布时间】：2017-12-18 06:54:48
【问题描述】：

我正在阅读 push using TLS certificates 和 push using authentication tokens 的文档

但除了解释如何配置每种方法之外，这些文章并没有真正解释两种方法的差异或优缺点。谁能给我解释一下？

【问题讨论】：

标签： ios push-notification token tls1.2

【解决方案1】：

基于令牌的身份验证较新，从本质上简化了 APNS 身份验证。它基于您可以在 Apple 开发者帐户上生成的公钥和私钥对。

以下是它更简单的主要原因：

相同的密钥可用于开发和生产应用程序，而使用基于证书时需要不同的证书验证。
Apple 中引用的所有应用程序都使用相同的密钥开发者账号。基于证书的身份验证需要一个每个应用的证书。
密钥不会过期。证书确实会过期，需要每年左右更新一次。

关于 APNS 的 2016 年 WWDC 视频是一个很好的英特尔来源： https://developer.apple.com/videos/play/wwdc2016/724/

【讨论】：

【解决方案2】：

2020年，你只能现实地使用“令牌”方法。旧的方法是遗留的，他们可能会取消它。

您的私钥将如下所示

let keystring = `-----BEGIN PRIVATE KEY-----
MIGTAgEAMBMGByqGSM49Aas8d76as8das687asd687asd68as8brwUIWA46qcXis
zCu6dbd4s8d7b5s86gf98ugtr28re7089a7d6tbvpiiui524kyfpq9861eFJP7we
eE7rX4182609457ohgyj3lhgp98wfb698bfg69287f2k4htgwpo876grwo7XDklz
9fdg689d
-----END PRIVATE KEY-----`

您的密钥 ID 将如下所示

let keyId = "CTU7XXBPRH"

您的 Apple 团队 ID 是您通常的 Apple 团队 ID，类似于“YWD3UUTEWD”。

现在 - 谢天谢地 - 从 Apple 开发者网站上的公司帐户中获取私钥和密钥 ID 相对容易。

如果你想在 AWS 上的普通 Node 服务器上测试发送推送，我强烈推荐这个优秀的新 npm，APNS2 https://www.npmjs.com/package/apns2

let bn = new BasicNotification(deviceToken, 'Hello')

发送推送就是这么简单。

提示：

不要忘记该死的“开发/沙盒”推送只能在连接到您的 MAC/XCODE 的 IPHONE 上工作！

开发/沙盒推送 - 仅适用于 iPhone连接到您的 Mac 并通过 Xcode 运行构建
生产推送 - 它们在 TestFlight 构建 中完全可以正常工作。

另外：不要忘记所谓的开发/沙盒推送通常是不稳定的。通常，他们几个小时都不会到达，他们根本不会到达，他们根本不在许多地区工作。

不要忘记使用 "production" 是完全可以的，只需使用 TestFlight 应用程序。

所以

进行构建
将其推送到您的 TestFlight 帐户。像往常一样等待几分钟，直到构建完成，
从 TestFlight 安装到您的手机中
您将现在获得所有推送 - 立即！

如果你

进行构建
只需构建/运行到您的tethered iPhone
您确实不会收到任何推送。
您确实可以获得所谓的“开发”推送，但它们通常非常不稳定。

（需要说明的是，在使用 APNS2 时，如果您确实想尝试“开发”推送，订购“开发”推送，只需使用此处底部解释的额外代码行 https://www.npmjs.com/package/apns2）

【讨论】：

“他的旧方法是遗留的，他们可能会取消它。”当Apple正式发布时，您能否提供任何链接？根据 Apple Developer 文档，基于证书的身份验证仍然是一种有效的技术：developer.apple.com/documentation/usernotifications/…

【解决方案3】：

2021 年，Apple 的Setting Up a Remote Notification Server 状态

这两种技术各有优缺点，因此请确定哪种技术最适合您的公司。

Fattie 和 Ika 都表示基于 TLS/证书的身份验证较差。 Project UI in Firebase 也使用了无法解释太多恕我直言的语言：

推荐使用身份验证密钥配置，因为它们是向 iOS 发送通知的最新方法

Certificate Authentication 的好处

有限访问证书。每个证书都与您的开发者帐户和环境（开发/生产）中的一个应用程序相关联。这样可以避免将所有鸡蛋放在一个篮子里，如果您的令牌身份验证密钥被泄露，威胁参与者可以将通知推送到您的所有应用程序。
更简单的 Provider 应用逻辑。 提供者（与 APN 交互的服务）（您自己的服务器或您使用的服务）可以只使用 TLS 证书，并进行身份验证，无需创建 JWT，添加标头到请求或找到要使用的正确应用 ID。

Token Authentication的好处

设置过程更简单：因为您只需下载.p12 并将其用于您的应用程序。进入 developer.apple.com，创建一个推送通知键。但是，您的应用程序必须每小时更新这些令牌。为 TLS 身份验证创建 .p12 有点复杂。
不会过期，因此您可以设置并忘记它。而 TLS 证书默认在 1 年内到期。

问题归结为安全与便利。

方便（使用令牌身份验证）：创建密钥并忘记（令牌身份验证）很方便，并且您可以使用 Firebase（或其他服务）实际上每小时更新一次令牌，因此您无需做太多工作做。
安全性（使用 TLS 身份验证）：您真的希望在所有应用程序之间共享相同的密钥吗？如果您想限制推送通知服务提供者（例如 Firebase、Ably、Pusher）的范围，但不相信让他们访问您的所有应用程序，该怎么办。实际上，您可能只有 1 个应用程序，所以没关系。

这种安全性是否重要，还是使用 Token Auth 更方便？我会说在大多数情况下，使用 Token auth。

【讨论】：