How to revoke tokens during account deletion? [Apple Policy deadline June 30 2022]

[sushrut-desora]

According to apple docs, apps will need to provide an option to delete user account by June 30, 2022.

When signing-in via apple the app also needs to revoke the user tokens as mentioned in the FAQs on the same page and as documented here.

How can we revoke user token using this library? Does v2.2.1 support revoking user token? Is it integrated in the logout flow or it that a different API method ?

Library version - v2.2.1

[mikehardy]

Hi there! The module does not support it currently

I see two paths to implement this:

1. Until / unless this module has an implementation, you will need to implement a server feature somewhere that handles it. This is possible, and is completely under your control, but is not a great implementation path in my opinion

2. implement a PR here follows those docs by using the information we have available within the library (regarding all the app information - client_id / client_secret / current token) to post to the URL in the docs and revoke the refresh and access token

I would love to see a PR implementing option 2 🙏 🙏 and would collaborate on it. I'm not sure if I'll have time prior to then to implement it, or if I do it will be closer to the deadline so may not offer enough time for others to get it in their app version review internally and out the door by June 30.

It's also possible that in review the reviewers may have no way of knowing whether the token deletion requests are happening or not. So you may be able to pass review even without token revocation as long as you call the logout operation here during delete account. I have zero evidence one way or the other how they will enforce this during review, so unless someone else has evidence either way we will have to see if apps are rejected until/unless the token revocation is implemented here

[andrejandre]

A lot of the community is concerned about this upcoming requirement (by community, I mean iOS developers all around - regardless of tech stack).

I would not gamble with the apple review process. The purpose of token revocation is to remove associations to a developer's app from a user's 'Apps using Sign In With Apple' settings.

If the token revocation is successful, you should be able to see that the user's setting no longer holds an association to the app. I suspect that reviewers will be able to do a basic test to verify this. I noticed in App Review that my reviewers were both creating and deleting accounts in my app (even before the requirement has become relevant).

I have tried to implement this natively, but have not had success. Another option, which I have not tried, is to make a call to my backend service (custom function living in Firebase), but that would not be an elegant way of handling this.

Apple has done a poor job at documenting this, other than outlining the requirement itself, and showing some curl HTTP examples.

If you want to be in tune with others struggling with this requirement, including myself, please see my post below. I hope all of us from across different tech stacks can overcome this requirement. I am aware that Firebase is also looking to implement a custom solution to this, but it remains unclear when or how we'll be able to access it, if at all. Fingers crossed.

https://stackoverflow.com/questions/72399534/how-to-make-apple-sign-in-revoke-token-post-request?noredirect=1#comment128385577_72399534

[mikehardy]

I wouldn't want to personally gamble either, my preference is as stated:

2. implement a PR here follows those docs by using the information we have available within the library (regarding all the app information - client_id / client_secret / current token) to post to the URL in the docs and revoke the refresh and access token

I would love to see a PR implementing option 2 pray pray and would collaborate on it.

You state:

I am aware that Firebase is also looking to implement a custom solution to this

Looks like this is what you mean? firebase/firebase-ios-sdk#9906 (comment)

[mikehardy]

This appears to have a working solution for some but requires a fair bit of documentation on how to set up the JWT etc, and an implementation here of the code sketched out in the solution: https://stackoverflow.com/a/72656672/9910298

[algrid]

@mikehardy The missing part in that solution is how to get access_token and refresh_token that we need to supply in order to revoke them. Does Firebase store them, can we get them somehow?

I suppose that Firebase at some point calls auth/token ( https://developer.apple.com/documentation/sign_in_with_apple/generate_and_validate_tokens ) in order to generate those tokens, but maybe I'm wrong.

[mikehardy]

Well, Firebase is actually separate from this module, right? I mean obviously I'm firebase-interested, as maintainer over there at react-native-firebase but you may use this module without it. That implies that we should have a way to get the access_token and refresh_token right?

Perhaps via re-authentication here?

This will be called https://developer.apple.com/documentation/authenticationservices/asauthorization?language=objc

here

react-native-apple-authentication/ios/RNAppleAuthentication/RNAppleAuthASAuthorizationDelegates.m

Line 43 in 9040e0e

- (void)authorizationController:(ASAuthorizationController *)controller didCompleteWithAuthorization:(ASAuthorization *)authorization {

We get an authorization code from that I believe?

Now - with that, I think you can obtain a refresh token if you HTTP POST the authorization code along with app configuration secrets here https://developer.apple.com/documentation/sign_in_with_apple/generate_and_validate_tokens

Now you've got a refresh, which you may invalidate per token revoke docs associated with this issue / that stackoverflow post

Open question: I guess firebase servers have their own refresh token for the firebase / apple sign in integration, so: when you get a new refresh token associated with a specific user, does that invalidate the old one? And then if you invalidate the new refresh token, are we all clear? (it may be necessary to use the new refresh token to obtain an access token first - it appears based on a quick scan of related libraries that old refresh tokens are revoked by identity providers when new refresh tokens are issued, but frequently only after a grace period or a first use in order to give grace to mobile application environments where network connection failure may mean a refresh token request is issued but connection breaks before new refresh token is received)

If so, we're set. If not, we need firebase to allow us to get the existing refresh token / access token they have, somehow ?

[tmoubarak]

This is a possible work around, if we follow the same steps it may work out:
https://stackoverflow.com/a/72498906/321506
Will attempt it on my end and let you guys know!

[mikehardy]

I don't think there needs to be a workaround based on my investigation in comment above.
I think the test is:

• alter this module to, perhaps, store the authorization code in user keychain (so it's available, though it is only valid for 5 minutes per apple docs). Display it in the UI here along with it's expiration so it's visible for testing.
• make a test button here called "get refresh token", enabled if authorization code has not expired, and implement it in javascript as a POST to the apple REST API using the authorization code and your app secrets as documented. Store the refresh token in keychain so it's available, display the refresh token here in the app if it's available (so now you can see it changing as you request new ones by hitting the button?)
• make a test button here called "get access token" and implement it here in javascript as a POST to the apple REST API using the refresh token. Store it in keychain for persistent access. Display the access token so you can see it changing

Now

make a new API in javascript that POSTs to the revoke API with either or both of the access token and refresh token and make a button that invokes it

Then you can test if making new refresh tokens invalidate old refresh tokens, and if revoking the refresh token then removes the app from the accounts token list as visible at "the apple id binding information is deleted under Apps Using Apple ID of Settings" per the stack overflow comment we're all linking to above

If it does, we're literally done here, solution implemented. If not then we know we have a hard block on getting access to whatever the existing refresh / access tokens are for whoever is paired with this library in practice (for example, react-native-firebase / firebase, or flutterfire / firebase etc)

[algrid]

@mikehardy ouch, sorry, I indeed missed that this repo isn't actually related to Firebase. :)

I'm definitely missing something what happens during Apple Sign In + Firebase Authentication.

It looks like with Firebase we don't use authorizationCode (that we get in the didCompleteWithAuthorization call) at all. Or I simply can't find where it happens.
We use identityToken only, passing it over to Firebase.

So can Firebase generate any refresh tokens without authorizationCode?
Should we in general revoke any tokens if we don't generate any? Generating tokens only to revoke them later seems weird...

[algrid]

btw, storing authorizationCode for long time wouldn't probably make sense:

The code is single-use only and valid for five minutes.

as mentioned here https://developer.apple.com/documentation/sign_in_with_apple/generate_and_validate_tokens
If that's about the token we're talking about.

[mikehardy]

I was just talking about storing authorization codes for display / app restart purposes (in case it restarts? like you hot reload the code?) during this type of testing - in other words for near immediate use

I am also a little vague on exactly how firebase-auth gets what it needs. The vaguery is associated with what exactly identityToken is - perhaps it is the refresh token ? or may be used as such?

Generating a token only to revoke it may seem weird but if generating a new refresh token (that you control and may now revoke) has the side effect of revoking all other associated refresh tokens which may not be in your control (because they are off in the firebase cloud or something) then it sure would be a nice side effect, and all the sudden no longer weird, but crucial to get control of the tokens back for full revocation