Sign in with Apple

RSS for tag

Discuss how to provide users the ability to sign in to your apps and websites using their Apple ID.

Sign in with Apple Documentation

Posts under Sign in with Apple subtopic

Post

Replies

Boosts

Views

Activity

Questions about Apple login authorization data behavior during App transfer
After the App transfer is initiated, will the replacement of the old and new certificates affect user authorization? (Based on some replies from DTS on the forum [Apple login authorization data is generated in combination with the team ID to which the App currently belongs], it is speculated that after the App transfer, during the period when the certificate configuration of the new team ID is not completed, authorization or authentication may not be performed normally, resulting in users being unable to use the Apple login function normally) During the 60-day migration period, if the user authorizes or cancels authorization and then authorizes again in the old app, will the authorized data be different? If so, will transfer_sub be included in the authorization operation?
0
0
218
Mar ’25
Apple login returns undefined
Issue with passport-apple: req.user Returning Undefined Data & Callback URL Issue I am facing an issue with passport-apple where, after successful authentication, the callback function does not receive the expected user data. Instead, req.user contains undefined values, and there seems to be an issue with the callback URL handling. Steps to Reproduce I have configured passport-apple with the following strategy: passport.use( new AppleStrategy( { clientID: process.env.APPLE_CLIENT_ID, teamID: process.env.APPLE_TEAM_ID, keyID: process.env.APPLE_KEY_ID, privateKeyLocation: path.join(__dirname, 'Auth.p8'), callbackURL: process.env.APPLE_CALLBACK_URL, scope: ['name', 'email'], passReqToCallback: true }, async (req, accessToken, refreshToken, idToken, profile, done) => { try { const decoded = jwt.decode(idToken); const user = { id: decoded?.sub || null, email: decoded?.email || null, name: profile?.name?.firstName || 'Unknown' }; const userApp = await authController.handleAppleAuth(user.email, accessToken, refreshToken); done(null, userApp); } catch (error) { return done(error); } } ) ); Observed Behavior Apple login succeeds, and an existing user is found in the database. However, req.user contains undefined values after authentication. The callback URL does not seem to function correctly, leading to potential misrouting or incomplete authentication flow. Expected Behavior req.user should contain the authenticated user's ID, email, and name. The callback URL should properly handle the authentication response. Actual Behavior req.user contains undefined values instead of valid user data, and the callback URL handling seems to be incorrect. Log Output: { id: '001412.13cccc5062074c35833683f6f0bcf5f6.1212', email: 'xyz@somemail.com', name: 'Unknown' } user checking redirectionn [Function: next] 📍 Processing Apple callback 📍 Authentication successful for user: { id: undefined, email: undefined } { id: undefined, email: undefined, firstName: undefined, lastName: undefined, subscriptionStatus: undefined }
0
0
151
Mar ’25
Handling account deletions and revoking tokens for Sign in with Apple
The revoke tokens endpoint (/auth/revoke) is the only way to programmatically invalidate user tokens associated to your developer account without user interaction. This endpoint requires either a valid refresh token or access token for invalidation, as Sign in with Apple expects all apps to securely transmit and store these tokens for validation and user identity verification while managing user sessions. 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. Respond to the credential revoked notification to revert the client to an unauthenticated state Important: If the manual token revocation isn’t completed, the next time the user authenticates with your client using Sign in with Apple, they won’t be presented with the initial authorization flow to enter their full name, email address, or both. This is because the user credential state managed by Sign in with Apple remains unchanged and returns the.authorizedcredential state, which may also result in the system auth UI displaying the “Continue with Apple” button. Respond to the credential revoked notification Once the user’s credentials are revoked by Apple, your client will receive a notification signaling the revocation event:  For apps using the Authentication Services framework to implement Sign in with Apple, register to observe the notification named credentialRevokedNotification. For web services, if an endpoint is registered for server-to-server notifications, Apple broadcasts a notification to the specified endpoint with the consent-revokedevent type. When receiving either notification, ensure you’ve already performed the following operations to meet the requirements of account deletion: Deleted all user-related account data, including: The token used for token revocation; Any user-related data stored in your app servers; and Any user-related data store in the Keychain or securely on disk in the native app or locally on web client. Reverted the client to an unauthenticated state. Securely store user tokens for account creations 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). For information about verifying an identity token and validating tokens, visit Verifying a user and Generate and validate tokens. If you have questions about implementing these flows, including client authorization, token validation, or token revocation, please submit a Technical Support Incident.
0
0
15k
Sep ’24
Gathering required information for troubleshooting Sign in with Apple user migration
Hi, Please see TN3159: Migrating Sign in with Apple users for an app transfer for more information on the expected end-to-end app transfer and user migration flow. Additionally, if you'd like for the iCloud and App Store engineering teams to confirm if the errors are related to a revoked authorization to previous users accounts, please submit a report via Feedback Assistant and include the following information: Gathering required information for troubleshooting Sign in with Apple user migration To prevent sending sensitive JSON Web Tokens (JWTs) in plain text, you should create a report in Feedback Assistant to share the details requested below. Additionally, if I determine the error is caused by an internal issue in the operating system or Apple ID servers, the appropriate engineering teams have access to the same information and can communicate with you directly for more information, if needed. Please follow the instructions below to submit your feedback. For issues occurring with your user migration, ensure your feedback contains the following information: the primary App ID and Services ID the client secret for the transferring team (Team A) and the recipient team (Team B) the failing request(s), including all parameter values, and error responses (if applicable) the timestamp of when the issue was reproduced (optional) screenshots or videos of errors and unexpected behaviors (optional) Important: If providing a web service request, please ensure the client secret (JWT) has an extended expiration time (exp) of at least ten (10) business days, so I have enough time to diagnose the issue. Additionally, if your request requires access token or refresh tokens, please provide refresh tokens as they do not have a time-based expiration time; most access tokens have a maximum lifetime of one (1) hour, and will expire before I have a chance to look at the issue. Submitting your feedback Before you submit via Feedback Assistant, please confirm the requested information above (for your native app or web service) is included in your feedback. Failure to provide the requested information will only delay my investigation into the reported issue within your Sign in with Apple client. After your submission to Feedback Assistant is complete, please respond in your existing Developer Forums post with the Feedback ID. Once received, I can begin my investigation and determine if this issue is caused by an error within your client, a configuration issue within your developer account, or an underlying system bug. Cheers, Paris X Pinkney |  WWDR | DTS Engineer
0
0
1.6k
Aug ’24
Questions about Apple login authorization data behavior during App transfer
After the App transfer is initiated, will the replacement of the old and new certificates affect user authorization? (Based on some replies from DTS on the forum [Apple login authorization data is generated in combination with the team ID to which the App currently belongs], it is speculated that after the App transfer, during the period when the certificate configuration of the new team ID is not completed, authorization or authentication may not be performed normally, resulting in users being unable to use the Apple login function normally) During the 60-day migration period, if the user authorizes or cancels authorization and then authorizes again in the old app, will the authorized data be different? If so, will transfer_sub be included in the authorization operation?
Replies
0
Boosts
0
Views
218
Activity
Mar ’25
Apple login returns undefined
Issue with passport-apple: req.user Returning Undefined Data & Callback URL Issue I am facing an issue with passport-apple where, after successful authentication, the callback function does not receive the expected user data. Instead, req.user contains undefined values, and there seems to be an issue with the callback URL handling. Steps to Reproduce I have configured passport-apple with the following strategy: passport.use( new AppleStrategy( { clientID: process.env.APPLE_CLIENT_ID, teamID: process.env.APPLE_TEAM_ID, keyID: process.env.APPLE_KEY_ID, privateKeyLocation: path.join(__dirname, 'Auth.p8'), callbackURL: process.env.APPLE_CALLBACK_URL, scope: ['name', 'email'], passReqToCallback: true }, async (req, accessToken, refreshToken, idToken, profile, done) => { try { const decoded = jwt.decode(idToken); const user = { id: decoded?.sub || null, email: decoded?.email || null, name: profile?.name?.firstName || 'Unknown' }; const userApp = await authController.handleAppleAuth(user.email, accessToken, refreshToken); done(null, userApp); } catch (error) { return done(error); } } ) ); Observed Behavior Apple login succeeds, and an existing user is found in the database. However, req.user contains undefined values after authentication. The callback URL does not seem to function correctly, leading to potential misrouting or incomplete authentication flow. Expected Behavior req.user should contain the authenticated user's ID, email, and name. The callback URL should properly handle the authentication response. Actual Behavior req.user contains undefined values instead of valid user data, and the callback URL handling seems to be incorrect. Log Output: { id: '001412.13cccc5062074c35833683f6f0bcf5f6.1212', email: 'xyz@somemail.com', name: 'Unknown' } user checking redirectionn [Function: next] 📍 Processing Apple callback 📍 Authentication successful for user: { id: undefined, email: undefined } { id: undefined, email: undefined, firstName: undefined, lastName: undefined, subscriptionStatus: undefined }
Replies
0
Boosts
0
Views
151
Activity
Mar ’25
Handling account deletions and revoking tokens for Sign in with Apple
The revoke tokens endpoint (/auth/revoke) is the only way to programmatically invalidate user tokens associated to your developer account without user interaction. This endpoint requires either a valid refresh token or access token for invalidation, as Sign in with Apple expects all apps to securely transmit and store these tokens for validation and user identity verification while managing user sessions. 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. Respond to the credential revoked notification to revert the client to an unauthenticated state Important: If the manual token revocation isn’t completed, the next time the user authenticates with your client using Sign in with Apple, they won’t be presented with the initial authorization flow to enter their full name, email address, or both. This is because the user credential state managed by Sign in with Apple remains unchanged and returns the.authorizedcredential state, which may also result in the system auth UI displaying the “Continue with Apple” button. Respond to the credential revoked notification Once the user’s credentials are revoked by Apple, your client will receive a notification signaling the revocation event:  For apps using the Authentication Services framework to implement Sign in with Apple, register to observe the notification named credentialRevokedNotification. For web services, if an endpoint is registered for server-to-server notifications, Apple broadcasts a notification to the specified endpoint with the consent-revokedevent type. When receiving either notification, ensure you’ve already performed the following operations to meet the requirements of account deletion: Deleted all user-related account data, including: The token used for token revocation; Any user-related data stored in your app servers; and Any user-related data store in the Keychain or securely on disk in the native app or locally on web client. Reverted the client to an unauthenticated state. Securely store user tokens for account creations 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). For information about verifying an identity token and validating tokens, visit Verifying a user and Generate and validate tokens. If you have questions about implementing these flows, including client authorization, token validation, or token revocation, please submit a Technical Support Incident.
Replies
0
Boosts
0
Views
15k
Activity
Sep ’24
Gathering required information for troubleshooting Sign in with Apple user migration
Hi, Please see TN3159: Migrating Sign in with Apple users for an app transfer for more information on the expected end-to-end app transfer and user migration flow. Additionally, if you'd like for the iCloud and App Store engineering teams to confirm if the errors are related to a revoked authorization to previous users accounts, please submit a report via Feedback Assistant and include the following information: Gathering required information for troubleshooting Sign in with Apple user migration To prevent sending sensitive JSON Web Tokens (JWTs) in plain text, you should create a report in Feedback Assistant to share the details requested below. Additionally, if I determine the error is caused by an internal issue in the operating system or Apple ID servers, the appropriate engineering teams have access to the same information and can communicate with you directly for more information, if needed. Please follow the instructions below to submit your feedback. For issues occurring with your user migration, ensure your feedback contains the following information: the primary App ID and Services ID the client secret for the transferring team (Team A) and the recipient team (Team B) the failing request(s), including all parameter values, and error responses (if applicable) the timestamp of when the issue was reproduced (optional) screenshots or videos of errors and unexpected behaviors (optional) Important: If providing a web service request, please ensure the client secret (JWT) has an extended expiration time (exp) of at least ten (10) business days, so I have enough time to diagnose the issue. Additionally, if your request requires access token or refresh tokens, please provide refresh tokens as they do not have a time-based expiration time; most access tokens have a maximum lifetime of one (1) hour, and will expire before I have a chance to look at the issue. Submitting your feedback Before you submit via Feedback Assistant, please confirm the requested information above (for your native app or web service) is included in your feedback. Failure to provide the requested information will only delay my investigation into the reported issue within your Sign in with Apple client. After your submission to Feedback Assistant is complete, please respond in your existing Developer Forums post with the Feedback ID. Once received, I can begin my investigation and determine if this issue is caused by an error within your client, a configuration issue within your developer account, or an underlying system bug. Cheers, Paris X Pinkney |  WWDR | DTS Engineer
Replies
0
Boosts
0
Views
1.6k
Activity
Aug ’24