Revoke Access Token for Sign In with Apple

[sidan5]

New Feature / Enhancement Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.

Current Limitation

When deleting an account Apple required to revoke Sign-In with Apple access tokens by 30 June 2022 (https://developer.apple.com/support/offering-account-deletion-in-your-app), currently it is not supported using Parse-Server.

Feature / Enhancement Description

Should have the option to revoke a user's Sign-In with Apple access token.

Example Use Case

Should have the option to call a revoke Sign-In with Apple access token for the specific user from cloud code. I guess it should use the client secret (which the developer shall create separately) and the authData from users table.

Alternatives / Workarounds

Could code a dedicated cloud code function for this using REST API, but everyone support this feature would need to duplicate this.
UPDATE: Apparently this cannot be done as it seems that the refresh token (which needed to be revoked) is stored somewhere on parse server and is not easily accessible. So, As I see it there should be internal support within Parse-Server.

3rd Party References

The formal reference: https://developer.apple.com/documentation/sign_in_with_apple/revoke_tokens

[parse-github-assistant]

Thanks for opening this issue!

• 🎉 We are excited about your ideas for improvement!

[sidan5]

@mtrezza Seems to me that this issue is too complex then I initially thought as the tokens are somewhere private in Parse-Server, so as I understand now, to support that we need to access those tokens or have this feature implemented. All this by 30 June 22.

If you think I'm wrong please let me know. Less than 10 days to find a fix.

[mtrezza]

Regarding timeline and urgency: in my understanding the current workaround is to set a beforeSave trigger on _User and if the "Sign-in with Apple" auth data is changed or deleted, the token could be extracted from that auth data and used to make an API call to Apple to invalidate the token.

Could you verify that the required token is stored at all on Parse Server? You can use Parse Dashboard to inspect the authData field, or on a raw DB level you would see the related _... internal auth field for Apple.

[sidan5]

Regarding timeline and urgency: in my understanding the current workaround is to set a beforeSave trigger on _User and if the "Sign-in with Apple" auth data is changed or deleted, the token could be extracted from that auth data and used to make an API call to Apple to invalidate the token.

Could you verify that the required token is stored at all on Parse Server? You can use Parse Dashboard to inspect the authData field, or on a raw DB level you would see the related _... internal auth field for Apple.

From my latest tests the token stored in authData is the id token and not the refresh token.
I don't know how to get the latest refresh token which need to be revoked.

[mtrezza]

It's possible that it's not stored at all; if that is the case, a fix may require a change in the client SDKs as well.

[sidan5]

@mtrezza I think that what's happening now. But I never took a look into the Parse Server code so I cannot confirm that's the case. From what I understand it's not possible to have a simple workaround and we have like a week... 😐

UPDATE: It's not in the raw on the server. we are storing only 'id token'

[mtrezza]

You are correct.

In this article, Apple suggests a workaround for cases like this:

If you don’t have the user’s refresh token, access token, or authorization code, you must still fulfill the user’s account deletion request and meet the account deletion requirement. You'll need to follow this workaround to manually revoke the user credentials:

• Delete the user’s account data from your systems.
• Direct the user to manually revoke access for your client.
• Be sure to clearly communicate that all apps associated with your developer account will be revoked for their user account as well.
• Respond to the credential revoked notification to revert the client to an unauthenticated state.

They also suggest how the account creation process should work:

For all new user account creations, follow the expected authorization flow below:

• Securely transmit the identity token and authorization code to your app server.
• Verify the identity token and validate the authorization code using the /auth/token endpoint.
• Once the authorization code is validated, securely store the token response — including the identity token, refresh token, and access token.
• Validate the refresh token up to once per day with Apple servers (to manage the lifetime of your user session and for future token revocation requests), and obtain access tokens (for future token revocation, app transfer, or user migration requests).