I've recently learned of the new APNS Authentication Key mechanism which is set to replace the functionality of the existing system of APNS certificates.
From my understanding this key supersedes all existing certificates, and can authenticate requests for all my apps.
I am confused about the transition though. Does this key only work for apps that are newly built/provisioned/released? My Firebase console invites me to upload my new APNS Authentication Key, but upon doing so, warns that my existing certificates which are being used in production will be removed. Does this mean my existing users will stop receiving push notifications?
IMHO, transitioning from certificate-based to authentication token-based only affects how your application server communicates with the APNS provider, thus existing users of your application will not be affected.
Related
if a bundle id is created on a different apple developer account and APNS key on different one will this work
Actually i have moved from my app from one account to the other but old apns auth key doesn't seem to work and the limit to create new key on second account is reached
I have an app in production that's heavily dependent on push notifications, and I'm worrying that revoking the old .p8 key will invalidate the existing FCM tokens. Unfortunately I can't get the old .p8 key from previous developer, so revoking is the only option. I couldn't find the answer in Firebase documentation. Any ideas?
I'm planning to migrate the APNs to the Authentication tokens system from the old (certificate based), but I don't want to invalidate the existing valid tokens. Does anybody have any experience with this? Will the existing token still works after migration?
TIA
Token is device specific and if you create an Auth token (which is new way of using push notifications as they have no expiry date), It would have no effect on device token. I guess the proper question here would have been whether the notifications using the old APNS certificates would still be working or not(considering it has been set up on the server as well) even in that case the answer would be Yes. As long as you do not revoke the certificates it would still be working
The token is generated on the device that will receive the notification and is based on your bundle ID and the device. It is not dependent on the credentials that your server uses to connect to the APNS service (The iOS device has no information on this).
As a result you can change the way you connect and authenticate without any impact to existing tokens. It is no different to using a new certificate when the old one expired with the old system.
I've setup Firebase Cloud Messaging on our system to setup push notifications. Before our APNs certificate expired and we ran into some issues because of this.
Then I was able to generate an APNs Authentication Key and I assumed that this one couldn't expire. Can someone tell me if that assumption is correct?
No. APNs Auth Key will never expire as Apple suggests. It is now a more preferred way to handle Push Notifications than using APNs Certificate.
I have some MDM solution that we've developed through which we want to support managing iOS devices. Even though we'd already been able to successfully enrol and manage iOS devices via the same, I am trying to figure out a way to secure all web service invocations with OAuth, which take place between the native app running on iOS devices, connecting to the Enrolment and other APIs deployed as part of the MDM solution. Apparently, we've got limited control over modifying the native app to embed OAuth access tokens in the form of HTTP headers or some other means to be able to send those access tokens across to the MDM APIs, as the app logic cannot be modified. Do we have any configuration in the Enterprise App that runs on iOS devices to enable OAuth (or any other form of authentication) or some other means, which I can effectively use to get my requirement implemented?
iOS enrollment flow associate with a challenge token in the SCEP payload (mentioned as Challenge). Once you do the authentication from MDM server side there needs to be a unique token generated based on your user identity and embed that in this SCEP payload. For subsequent enrollment calls this token is passed and once the enrollment success this can be fetched and validate the user. Ideally this is just a way to link the device to a specific user which could be a temporary token generated at your MDM server end which link to a user identity or something related. To follow that you could apply OAuth password grant type and get the token once the authentication happens. Then this OAuth token can be then set as this challenge token for future use. But unlike in other OAuth communications iOS will not send this token in header as the bearer rather this will be embedded in the xml payload with proper encryption and signing in place.
Further iOS support protocol extension to validate users with open directory service using an auth token. This will by default have the ability to communicate back and forth using the checkin endpoint.