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.
Related
First, sorry for my English.
I'm trying to send a message to my iOS device using Firebase Cloud Messaging.
However, there are several tokens with different names.
What do these tokens do? What is the difference?
Is FCM token the same as registration token and APNs token the same as device token?
And how can FCM token be made with APNs token?
There are two definitives here:
APNS Token is the Apple Push Notification Service token. It is a token (think of it like a password) that authenticates your app and device onto the Apple Push service and allows for communications to be sent.
FCM Token is the Firebase Cloud Messaging token. This is googles version of the APNS Token however works for both iOS and Android (Google do proxying on their end when sending a push notification to iOS devices).
When you refer to a registration token or a device token it really does depend on the context you use the phrases. They are often used interchangeably and neither are really "official" terms. For the most part, both terms refer to your APNS/FCM token, however device token has historically been used for other things like unique device identifiers.
When signing in using Sign in with Apple for the first time, it returns a value realUserStatus as a part of ASAuthorizationAppleIDCredential in the iOS client. This value indicates whether Apple is confident that the user is real, or not (e.g. it's a script)
My question is how can I verify the value of realUserStatus in my backend authentication system?
Because the realUserStatus is returned to iOS client, and the client should tell my server whether it is a bot or not! How can I know if it's not just a script and telling the server that it is real?
Edit (additional clarification):
In Apple’s docs it says “ You can skip any additional fraud verification checks or CAPTCHAs that your app normally uses.” but when we use CAPTCHAs, the provider can verify the response, something either Apple doesn’t do, or I can’t find anywhere how to do it!
I just finished a call with an Apple engineer on WWDC online lab.
So from the iOS 14, the realUserIndicator is included in the identity token, and can be verified with the server.
For iOS 13 they don't have a solution.
This flag serves as a basic first validation, meant to be used by your frontend. The identification servers will return this value only when the user first uses Sign in with Apple in your app.
If you want to verify the user on the backend, you should use the user identity token (JWT). You get it from Apple's servers when the user signs in (read here: https://developer.apple.com/documentation/signinwithapplerestapi/authenticating_users_with_sign_in_with_apple).
If you want to verify the user on the upcoming sessions, as an existing user (without the user having to sign in every time), you should develop a system of your own, for creating, saving, and validating a token. Another option is to use Firebase auth framework, which supports apple sign-in.
if you send the fetched user’s information to app server(your backend) you can verify user by the identity token with a rest service.
Apple document says:
After your app receives the user information, you can verify their associated identity token with the server to confirm that the token is not expired and ensure it has not been tampered with or replayed to your app. For information about retrieving the identity token, see Authenticating Users with Sign in with Apple.
https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_rest_api/verifying_a_user
I saw the description
You may verify the refresh token up to once a day to confirm that the user’s Apple ID on that device is still in good standing with Apple’s servers.
in https://developer.apple.com/documentation/signinwithapplerestapi/verifying_a_user .
I have two question about the description:
Why should we verify the refresh token instead of access token to confirm the user's Apple ID is still in good standing with Apple's server?
The doc said refresh token can only verify once a day. But i can verify refresh token multiple times in practice. Is there some conflict between documentation and implementation?
Update on 10/17/2019：
For apps running on other systems, use the periodic successful verification of the refresh token to determine the lifetime of the user session.
I also saw the description above in in https://developer.apple.com/documentation/signinwithapplerestapi/verifying_a_user . I think periodic is also conflict with once a day.
Right now, I store the access_token and set custom expires time for follow verify request. And get notification from iOS client(getCridentialState) to delete access_token.
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.
Is it Possible to somehow include Device_ID and information about the device in Bearer token Claims, or is this only Possible through a BYOD MDM subscription?
I have read about this for some while now and haven't found anything to make this happen, though there are hints around pointing at for example the refresh_token containing that information (Which i haven't found a way to check just yet).
Device_ID in refresh_token
Also Reading about MDM (Mobile Device Management) this is possible it seems.
About BYOD and MDM Under the topics:
"Terms of Use protocol semantics" and "Management protocol with Azure AD"
i have also asked about "custom" claims before (with no luck, unfortunately) and was asked to repost a more specific question.
Previous post