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.
Related
What information is used by APNS to generate device tokens and identify that it's unique to the device and app?
I have gone through apple documentation but it only tells that the token is unique to device and app , but how the token gets generated the process is not diclosed.
It's an opaque token. By design, you're not going to be able to reverse engineer how APNS tokens are generated and make your own.
If it helps, you might think of an APNS token as a hash of a bunch of things, some of which you can't see or control.
I am working on an application and I encountered such a problem: after uninstalling and installing a new application, when authorizing a new user, the token of the previous user is stored, which was authorized on the device before uninstallation. The token for VoIP push remains the same and when I call the previous user, a voip call comes to both users due to the same token. I was looking for this moment in the manual APNS, but could not find anything.
Is it possible that the platform does not perform any necessary actions before requesting a token?
iphone: 5se
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'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.
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.