Post marked as Apple Recommended
Hi AndresLiger,
Please see the following TechNote for more information on resolving Sign in with Apple response errors:
TN3107: Resolving Sign in with Apple response errors
https://developer.apple.com/documentation/technotes/tn3107-resolving-sign-in-with-apple-response-errors
Note: Some invalid requests are due to users' revoking access to the client prior to the app transfer and/or user migration completion.
If you still require guidance after reading the above TechNote, please submit a Technical Support Incident with Developer Technical Support and I'd be delighted to help.
Cheers,
Paris
Post marked as Apple Recommended
Hi fmricky,
Please see the forum post below for the suggested steps for account deletion, as well as the workaround for when clients using the Sign in with Apple REST API or Sign in with Apple JS SDK do not have an existing refresh token, access token, or authorization code:
Handling account deletions and revoking tokens for Sign in with Apple
Regards,
Paris
Post marked as Apple Recommended
Hi zhihao,
Please see the forum post below for the suggested steps for account deletion, as well as the workaround for when clients using the Sign in with Apple REST API or Sign in with Apple JS SDK do not have an existing refresh token, access token, or authorization code:
Handling account deletions and revoking tokens for Sign in with Apple
Regards,
Paris
Post not yet marked as solved
Hi Ben,
You wrote:
What is the user experience if I do not migrate users and simply transfer the app without handling this? Assuming the app handles expired authentication correctly, will they simply be asked to sign in to the app again and all will be well? Or will the user ID be different, meaning that "signing back in" will actually create a new account?
If you do not migrate users within the 60-day transfer period, the newly transferred app will be associated with the new developer team account. Since the user identifier and private relay email address are team-scoped, Sign in with Apple will create a new account of the same user. Performing a user migration prevents this discontinuity, and allow for your clients to receive the migrated user ID without explicit user interaction as described in "Confirm the Transferred Credential State" of Bringing New Apps and Users into Your Team.
Then, you wrote:
In other words, is the user migration process only intended to minimize user inconvenience by maintaining logged-in sessions, or is it essential for user accounts to remain tied to their data?
Both. However, the exact answer depends on what data you have associated with the Sign in with Apple user identifier. If you'd like to explain more, please submit a Technical Support Incident via Requesting Technical Support.
Cheers,
Paris
Hi sreenathtv,
When a user initially authenticates with their Apple ID for your app, this is considered an account creation event for your developer account. The user name is provided directly to the app and is not shared with Apple. However, the email address is included within the identity token:
email
A String value representing the user’s email address. The email address is either the user’s real email address or the proxy address, depending on their status private email relay service.
email_verified
A String or Boolean value that indicates whether the service has verified the email. The value of this claim is always true, because the servers only return verified email addresses. The value can either be a String (”true”) or a Boolean (true).
is_private_email
A String or Boolean value that indicates whether the email shared by the user is the proxy address. The value can either be a String (”true” or “false”) or a Boolean (true or false`).
Please see Authenticating Users with Sign in with Apple for more information about this expected behavior:
While Apple provides the user’s email address in the identity token on all subsequent API responses, it doesn’t include other information about the user, such as their name. When you receive user information from the API response, immediately store it locally so your app can access it again in the event of a process or network failure.
Additionally, a user may revoke access for a developer by following the steps outlined in this Support page:
https://support.apple.com/en-us/HT210426
Once revoked, the next authorization will be considered an account creation event, yet the user ID and proxy email address (if provided), will remain the same for a given developer team.
Cheers,
Paris
Post not yet marked as solved
Hello nizwar,
Based on your questions, we need more information about your Sign in with Apple enabled app or web service.
If this issue occurs for your native app, please perform the following steps:
Install the Accounts/AuthKit profile on your iOS, macOS, tvOS, or watchOS device.
Reproduce the issue and make a note of the timestamp when the event occurred.
Gather a sysdiagnose on the same iOS, macOS, tvOS, or watchOS device.
Provide your App ID, testing user ID or email address, Services ID (if applicable), and screenshots of any errors or undesired behaviors.
If this issue occurs for your web service, please gather the following information:
Client ID or Services ID
Test user email address or user ID (if applicable)
Example of the failing request, including all parameter values, and the error response (if applicable)
Example of the Private Email Relay Service message delivery failure, and SMTP error codes (if applicable)
Important: If the web service request above requires a client secret, please ensure the JWT has an extended expiry of at least three (3) days, so we have enough time to diagnose the issue.
Please understand the underlying cause may be the result of any of the following:
a configuration issue in your Developer Account
a programmer error in your app or web service request
a system bug in the OS or Apple ID servers
To allow us to determine the underlying cause of the reported issue, please submit a bug report the requested details described in Steps 1-4. Once submitted, please reply with the Feedback ID. If a configuration issue or programmer error is identified, I'll work with you to resolve the issue via a Technical Support Incident. Otherwise, if the issue is the result of a system bug, the relevant engineering team will resolve the issue via your bug report.
For more information about how to submit a bug report, see Feedback Assistant for Developers. To learn more about the status of your bug report, see Understanding the Status of Your Feedback.
Cheers,
Paris
Post not yet marked as solved
Hi iskyd,
The authorization grant code has a five (5) minute expiry, and is restricted to single-use. Please ensure this code has not been previously consumed, and is validated within 5 minutes after issuance.
I don't have much information about your app, web service, or configuration, to assist you here. Please submit a Technical Support Incident (TSI) so we can investigate the issue, when doing so, please provide the App ID, Services ID, and Team ID.
However, please be aware that the issue is within your own code and handling of our server responses, not the result of an Apple bug. I strongly suggest debugging this issue yourself before submitting your TSI.
Post not yet marked as solved
Hi edosensei,
The scope query parameter supports the following values for Sign in with Apple:
name
email
Your Drupal-provided request contains scope=openid%20email%20profile, which is invalid.
You can learn more about the required query parameters in the following documentation:
Incorporating Sign in with Apple into Other Platforms
If you have further questions about Sign in with Apple, please submit a Technical Support Incident and I'll be happy to assist.
Cheers,
Paris
Post not yet marked as solved
Hi ibh12,
No. The supported scopes are email and name, which then provides the following user information:
user identity
full name
verified email address
real user status
Please see the following documentation for more information:
Authenticating Users with Sign in with Apple
Cheers,
Paris
Post not yet marked as solved
Hi Jaedotfi,
The client_id value must match the value used in the initial authorization request. If you authorized the App ID, you must validate the code for the same App ID; otherwise, providing the Service ID would fail, and vice versa. The same ID must match the sub claim value provided in the client secret (JWT). The expected values and descriptions of the required query parameters are documented below:
Generate and Validate Tokens
If you have further questions about Sign in with Apple, please submit a Technical Support Incident and I'll be happy to assist.
Cheers,
Paris
Post not yet marked as solved
Hi David5781,
The user's email is provided in the ID token, as well as the following claims:
iss
sub
aud
iat
exp
nonce
nonce_supported
email
email_verified
is_private_email
real_user_status
transfer_sub (if within 60-day app transfer period)
However, the user's full name is not included in the ID Token, as documented on the same page linked above:
If you request the user’s full name, Sign in with Apple collects the information to pass along to your app. The name defaults to the user’s name from their Apple ID, but the user can change their name. The modified name is only shared with your app and not with Apple, and hence isn’t included in the ID token.
If you've already authenticated your test user, you will need to revoke access to your app to invoke the initial authorization flow.
If you have further questions about Sign in with Apple, please submit a Technical Support Incident and I'll be happy to assist.
Cheers,
Paris
Post not yet marked as solved
Hi Bhavin-Jagad,
The user's email is provided in the ID token, as well as the following claims:
iss
sub
aud
iat
exp
nonce
nonce_supported
email
email_verified
is_private_email
real_user_status
transfer_sub (if within 60-day app transfer period)
However, the user's full name is not included in the ID Token, as documented on the same page linked above:
If you request the user’s full name, Sign in with Apple collects the information to pass along to your app. The name defaults to the user’s name from their Apple ID, but the user can change their name. The modified name is only shared with your app and not with Apple, and hence isn’t included in the ID token.
If you've already authenticated your test user, you will need to revoke access to your app to invoke the initial authorization flow.
If you have further questions about Sign in with Apple, please submit a Technical Support Incident and I'll be happy to assist.
Cheers,
Paris
Post not yet marked as solved
Hi Vincenzo,
Please do not repeat questions in your own posts' answers. We have sample code for iOS to show you how to implement Sign in with Apple in your app:
Implementing User Authentication with Sign in with Apple
If you have further questions, please request technical, code-level support.
Cheers,
Paris
Post not yet marked as solved
An invalid client error can be the result of multiple failure points on the client-side implementation. For a quick reference of the potential errors returned from the validation response, please see ErrorResponse.
Additionally, the most common occurrence is a mismatched client identifier between the following scenarios:
the client id provided in the authorization request (or the audience claim contained within the identity token of the authorization response); and
the subject contained within the client secret generated for the validation request.
Please see the Generate and Validate Tokens for additional information about the validation servers.
If you believe these query parameters are valid, then I'd suggest you reach out to Flutter's support channels for further guidance to their tooling.
Post not yet marked as solved
Please request a Technical Support Incident, including your bundle/client ID, an example of a failing message, and the user identifier associated—I'll be happy to troubleshoot.
