iOS push notifications using TLS certificate vs. using authentication tokens

Question

I am reading the documentation for both push using TLS certificates and push using authentication tokens

But besides explaining how to configure each, the articles don't really explain the differences or pros/cons of both approaches. Can somebody explain them to me?

Dihedral

Answer 1

Token-based authentication is newer and essentially simplifies APNS authentication. It is based on a public and private key pair that you can generate on your Apple developer account.

Here are the main reasons why it is simpler:

• The same key can be used for development and production apps whereas different certificates are needed when using certificate-based authentication.
• The same key is used for all your apps referenced in your Apple developer account. Certificate-based authentication needs one certificate per app.
• The key does not expire. Certificates do expire and need to be renewed every year or so.

A good source of intel is the 2016 WWDC video regarding APNS: https://developer.apple.com/videos/play/wwdc2016/724/

Bugs

Am I crazy or does the new token based approach seem way less secure. Being unable to separate out your production and development environments seems like a problem. – Harber

@Harber I can't see any lack of security between dev/prod you mention. (It would be like saying "shouldn't we have different passwords for Xcode, when doing dev versus production" or "on github, would it be better to have different passwords for each branch?") I can't see an issue there – Fishback

@Harber hwoever, as Butterworth points out, it might be that you prefer different keys for different apps if your company publishes more than one. I, really, can't see much advantage in that, but, some people might think so. – Fishback

Answer 2

For 2024, you use the "token" method which is dead easy.

For your server you need to make a private key. You do that instantly with one click on Apple's web site here .. https://developer.apple.com/account/resources/authkeys/add ie click "keys" on the left menu on the Apple "certs/ids/profiles" screen.

That's on DEVELOPER apple, not the weird-ass "appstoreconnect" site.

Note you don't have to use "keychain access" or anything. You just tap a button on that page and it gives you an ID and a private key. (Make as many as you want, perhaps for different servers, or if you just feel like it, tap all day.)

It just downloads it as a .p8 file, which is simply the plain text of the key, open in any text editor. (Not to be confused with, say, a .p12 file which is totally different and binary.)

Again, that is you making a key for your server to use. Not to be confused with the similar process of "adding a capability" to an app id when you click "identifiers" on that left menu.

wrong!

Your private key will look like this

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

your key id will look like this

let keyId = "CTU7XXBPRH"

Note that it used to be a PITA to find the keyId, it's now literally in the filename! of the .p8 file, or indeed it openly tells you the keyId on the apple web page, forever, once you have created the key, no stress.

Finally your Apple team id "Y3DEXAMPLE" is AT LAST listed plainly by Apple at https://developer.apple.com/account

Note that you ONLY NEED ONE KEY, it works for both normal push and "development aka sandbox" push.

To repeat there ARE NOT two different keys for production/sandbox, it's "just a key" so that Apple servers know your server.

To send push on an ordinary Node server on AWS, use the outstanding new long established APNS2 https://www.npmjs.com/package/apns2

ubuntu@your-server:~$] npm install apns2 -g

Send a push:

const { ApnsClient } = require('apns2')
const client = new ApnsClient({ ...

import { Notification } = require('apns2')
const bn = new Notification(deviceToken, {alert: 'Sup'})

It's that easy.

Tips:

Don't forget the damned "development/sandbox" pushes only work ON AN IPHONE TETHERED TO YOUR MAC/XCODE - !!!!!

• development/sandbox pushes - only for an iPhone tethered to your Mac with a build running from Xcode

• production pushes - they do work completely fine with TestFlight builds.

Note that the so-called development/sandbox pushes are often flakey. They don't arrive for hours, they don't arrive at all, they simply do not work in certain regions.

Don't forget that it is TOTALLY OK to use the so-called "production" ones, simply, with a TestFlight app.

So

1. Make a build
2. Push to TestFlight. Wait a couple minutes as usual until the build comes through,
3. You must install it from TestFlight to your physical phone
4. You will now get all the pushes - instantly!

Whereas if you

1. Make a build
2. Just build/run to your tethered iPhone
3. You do NOT get any pushes.
4. It's true that you can get the so-called "development/sandbox" pushes, but they are often flakey.

(With APNS2, if you do want to try "development aka sandbox" pushes, see the last line of the doco page: https://www.npmjs.com/package/apns2 )

Fishback

"he older approach is legacy and they will probably axe it." Can you please provide any link when this is made official by Apple? According the Apple Developer documentation, certificate based authentication is still a valid technique: developer.apple.com/documentation/usernotifications/… – Deepen

Answer 3

In 2021, Apple's Setting Up a Remote Notification Server state

Both techniques have advantages and disadvantages, so decide which technique is best for your company.

Both Fattie and Ika have said that TLS/ Certificate based authentication is inferior. The Project UI in Firebase also uses language which doesn't explain much IMHO:

Configuration with auth keys is recommended as they are the more current method for sending notifications to iOS

Benefits of Certificate Authentication

• Limited access certificates. Each certificate is tied to one application in your developer account and environment (development/ production). This avoids putting all your eggs in one basket, if your token auth key is compromised, a threat actor can push notifications to all your applications.
• Simpler Provider application logic. The provider (service which interacts with APNs) (either your own server or a service you use) can just use the TLS certificate, and authenticate, without needing to create JWTs, add headers to the request or find the correct App ID to use.

Benefits of Token Authentication

• Simpler setup process: because you only have to download a .p12 and use it your application. Go into developer.apple.com, create a Push Notification Key. However, your application has to renew these tokens every hour. Creating a .p12 for TLS authentication is a little bit more involved.
• Does not expire, so you can set it and forget it. Whereas TLS certificates expire in 1 year by default.

---

The question boils down to security vs. convenience.

• Convenience (use token auth): It's convenient to create a key and forget (token auth), and you might use Firebase (or another service) to actually renew the tokens every hour, so you don't have much work to do.
• Security (use TLS auth): Do you really want to share the same key between all your applications? What if you want to limit the scope of a Push Notification Service Provider (e.g. Firebase, Ably, Pusher), but don't trust giving them access to all your applications. In reality, you might just have 1 application, so it does not matter.

Does this kind of even security matter, or is it just more convenient to use Token Auth? I would say in most cases, go with Token auth.

Puto