We’re looking to make changes to comply with apple’s delete account requirements due to go in to effect at the end of June. We are able to successfully link an apple account with sign in with apple. When we unlink the apple account - it seems to remove the apple link id from the nakama account, but our app continues to be associated with apple sign in, and the user credentials continue to be authorized. Is it expected that when we unlink an apple account, the user authorization token is revoked? If not, how do we do that?
We are using nakama 3.10. Unity SDK 3.4.1, and testing with an ios 14.6 device.
The AppleSignInUnity asset we are using that generates the token, doesn’t seem to have any logout or revoke functionality. The apple revoke authentication REST api seems to be server to server so we’re not sure how to accomplish this.
as you mentioned, the unlink action will only remove the Apple link ID from the Nakama account. In order to revoke the token, you could create an RPC function with the revoking logic as a before/after hook to the unlink action.
Thanks for you response. Does the unlinkAppleAsync clear the email field for the account too?
We have gone down the rabbit hole of using apple’s REST api to revoke the token but it seems to have no effect. We get a 200 OK response from the api, but when we start up our mobile app, according to our appleSignInManager, the stored credentials are still authorized. The only thing that seems to revoke the credentials is signing out of apple using the iOS settings menu for Apps Using Apple ID.
We’re expecting that once we hit the api with the correct values and get a 200 response, the credential status would be revoked, and we should also get a CredentialsRevoked callback.
This sounds like it’s out of the purview of Nakama, but if anyone else on the forum has had success with revoking apple authentication, we would greatly appreciate any information you have.
I know it’s been awhile but I was just working on the same thing so hopefully this helps someone.
We have gone down the rabbit hole of using apple’s REST api to revoke the token but it seems to have no effect. We get a 200 OK response from the api, but when we start up our mobile app, according to our appleSignInManager, the stored credentials are still authorized.
A fun quirk of the API Apple has supplied is that if your params like client_id/client_secret are correct, you get a 200 regardless of the token. I sent it pure gibberish refresh_tokens and it gave 200s.
When you finally guess the right parameters, the revoke token API does remove the app from the iOS settings menu for Apps Using Apple ID. Don’t lose faith on that
For me the final missing piece was that I was providing my app’s bundle ID to the revoke endpoint and I had to provide the “service ID” as configured on the Apple Developer site when setting up Sign in with Apple. But that was just another field where you can send in something wrong and get a 200 back.
Some debugging I did to convince myself I was on the right track was making use of Apple’s /auth/token/ endpoint, it’s a bit pickier on validating the params and can help find what’s wrong between the ids/secrets/tokens.
Thanks for your response. We were finally successful to implement this but not without an additional apple sign in, even if the user is already signed in, due to the fact that the authorization code received back from the apple sign in manager expires after 5 minutes. The only way we found to get around this was for a user to sign-in again to get an updated code - we then can call applieid.apple.com/auth/token to get an authtoken, and then call api.apple.com/auth/revoke using that authtoken and we successfully revoke. It just seems like a bizarre user experience to have to resign in when you are trying to delete your account but we found no other way around it. We have yet to submit these changes, so we’ll see what apple says for approval.
