Post not yet marked as solved
Hi Rajesh CKR,
Please submit a technical support incident (TSI) via the page below and I'll be happy to help you resolve this issue with your Sign in with Apple token validation request(s):
Requesting Technical Support
Additionally, please review the following TechNote:
TN3107: Resolving Sign in with Apple response errors
Cheers,
Paris
Post not yet marked as solved
Please see On Log Noise to determine your next steps for these console logs.
Post not yet marked as solved
Hi dacosta_rafael,
Please see the following TechNote for guidance on troubleshooting invalid grant errors:
TN3107: Resolving Sign in with Apple response errors
Cheers,
Paris
Post not yet marked as solved
Hi joappdev,
If servers cannot have team B's private key, from the moment "transfer completed" to the moment "Team B find out the transfer completed, generate private key, and update servers", users cannot be verified.
We would like to have no down time to users, is it possible?
Once an app transfer is complete, both teams have a 60-day app transfer period to validate credentials, generate and exchange transfer IDs, and migrate users to the recipient team. You will need to create a new private key associated with the recipient team's app to continue to validate the user credentials and your Services ID after the transfer period. You can learn about that process here:
Create a Sign in with Apple private key
Note: When a Sign in with Apple enabled app is transferred, the Services ID is transferred automatically to the recipient team, yet the private key remains with the transferring team.
If you have any more questions about Sign in with Apple, please submit a Technical Support Incident and I we can continue our discussion in private.
Cheers,
Paris
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
