When we transfer app A to app B, if we transfer the app but don't migrate the user to app B, will the user's previous tokens from app A be invalid? Is this failure real-time or will there be a buffer period to transfer users? If it is a live failure, we want to transfer some users during the transferation process to prevent accidents, and then test them. Is there a way to test it?

Hey, According my research and documentation provided by Apple and Outsystems I have made the right configuration in both places but after authentication from apple side it is not redirecting me to my Outsystems page. I have checked many times the redirect URL configuration it is correct but not know the issue why it is happening.

Hello. I recently transferred an app from my dev account to a different one. I'm trying to follow these instructions to generate transfer IDs, and am stuck on Step 1 (creating an access token). I keep getting {'error': 'invalid_client'}. Here's the python script I'm using to generate the access token: TEAM_ID = "..." KEY_ID = "..." KEY_FILE = "key.p8" CLIENT_ID = "com.myapp.bundle" def get_access_token() -> str: client_secret = get_client_secret() print(f"client secret: {client_secret}") url = "https://appleid.apple.com/auth/token" req_headers = {"Content-Type": "application/x-www-form-urlencoded"} data = { "grant_type": "client_credentials", "scope": "user.migration", "client_id": CLIENT_ID, "client_secret": client_secret, } response = requests.post(url, headers=req_headers, data=data) json = response.json() return json["access_token"] def get_client_secret() -> str: payload = { "iss": TEAM_ID, "iat": int(time.time()), "exp": int(time.time() + 86400 * 7), # 7 days "aud": "https://appleid.apple.com", "sub": CLIENT_ID, } key = open(KEY_FILE, "r").read() print(f"Key: {key}") headers = {"alg": "ES256", "kid": KEY_ID} return jwt.encode(payload, key, algorithm="ES256", headers=headers) print(get_access_token()) The app was transferred about 2 weeks ago, so well within the 60 day period. And the script actually briefly got an access token for about 30 minutes yesterday, but is no longer working. Any ideas? Thanks in advance.

Hey all, I'm encountering persistent issues while attempting to migrate users for an app transfer using Sign In with Apple. I hope to get some insights or solutions from those who might have faced similar challenges. Context: We're transferring an app from one developer account to another. The app previously only had Sign In with Apple configured for iOS, not for web. We're now trying to set up the user migration process as part of the transfer. Current Setup: Old App Bundle ID: old.bundle.id24 Old Team ID: 123456789 New Team ID: 234567890 Issue: When attempting to generate transfer identifiers for our users, we're encountering an "invalid_client" error. Here's what we've observed: Using old_client_id = 'old.bundle.id24': Successfully generates an access token but fails at the user migration info step with an "invalid_client" error. Using old_client_id = 'old.bundle.id' (without '24'): Fails to generate an access token with an "invalid_client" error. Simplified script I am using old_client_id = 'old.bundle.id24' old_team_id = '123456789' new_team_id = '234567890' # JWT Payload for client secret jwt_payload = { 'iss': old_team_id, 'iat': int(time.time()), 'exp': int(time.time()) + 15552000, # 180 days 'aud': 'https://appleid.apple.com', 'sub': f'{old_team_id}.{old_client_id}' } # Generate client secret client_secret = jwt.encode(jwt_payload, private_key, algorithm='ES256', headers={'kid': key_id, 'alg': 'ES256'}) # Request access token token_response = requests.post('https://appleid.apple.com/auth/token', data={ 'grant_type': 'client_credentials', 'scope': 'user.migration', 'client_id': old_client_id, 'client_secret': client_secret }, headers={'Content-Type': 'application/x-www-form-urlencoded'} ) # If successful, proceed to user migration info request if token_response.status_code == 200: access_token = token_response.json()['access_token'] migration_response = requests.post('https://appleid.apple.com/auth/usermigrationinfo', data={ 'sub': user_sub, 'target': new_team_id, 'client_id': old_client_id, 'client_secret': client_secret }, headers={ 'Authorization': f'Bearer {access_token}', 'Content-Type': 'application/x-www-form-urlencoded' } ) # This is where we get the "invalid_client" error print(migration_response.status_code, migration_response.text) What we've tried: Verified all IDs (client ID, team ID, key ID) match between our code and the Apple Developer portal. Ensured the JWT is correctly signed with the ES256 algorithm. Checked that the client secret hasn't expired. Verified the content type is set correctly for all requests. Waited 72h+ since the key was first generated. Questions: Could the lack of web configuration in the original app be causing this issue? If so, how can we rectify this post-transfer? Is there a specific way to handle migrations for apps that were only configured for iOS Sign In with Apple? Are there any known issues or additional steps required when the old and new bundle IDs differ slightly (e.g., with/without '24' at the end)? How can we further diagnose the root cause of this "invalid_client" error, given that it occurs at different stages depending on the client ID used? Any insights, suggestions, or solutions would be greatly appreciated - I really don't know what to try at this point... Thank you in advance for your help!

Hey all, I'm encountering persistent issues while attempting to migrate users for an app transfer using Sign In with Apple. I hope to get some insights or solutions from those who might have faced similar challenges. Context: We're transferring an app from one developer account to another. The app previously only had Sign In with Apple configured for iOS, not for web. We're now trying to set up the user migration process as part of the transfer. Current Setup: Old App Bundle ID: old.bundle.id24 Old Team ID: 123456789 New Team ID: 234567890 Issue: When attempting to generate transfer identifiers for our users, we're encountering an "invalid_client" error. Here's what we've observed: Using old_client_id = 'old.bundle.id24': Successfully generates an access token but fails at the user migration info step with an "invalid_client" error. Using old_client_id = 'old.bundle.id' (without '24'): Fails to generate an access token with an "invalid_client" error. Simplified script I am using old_client_id = 'old.bundle.id24' old_team_id = '123456789' new_team_id = '234567890' # JWT Payload for client secret jwt_payload = { 'iss': old_team_id, 'iat': int(time.time()), 'exp': int(time.time()) + 15552000, # 180 days 'aud': 'https://appleid.apple.com', 'sub': f'{old_team_id}.{old_client_id}' } # Generate client secret client_secret = jwt.encode(jwt_payload, private_key, algorithm='ES256', headers={'kid': key_id, 'alg': 'ES256'}) # Request access token token_response = requests.post('https://appleid.apple.com/auth/token', data={ 'grant_type': 'client_credentials', 'scope': 'user.migration', 'client_id': old_client_id, 'client_secret': client_secret }, headers={'Content-Type': 'application/x-www-form-urlencoded'} ) # If successful, proceed to user migration info request if token_response.status_code == 200: access_token = token_response.json()['access_token'] migration_response = requests.post('https://appleid.apple.com/auth/usermigrationinfo', data={ 'sub': user_sub, 'target': new_team_id, 'client_id': old_client_id, 'client_secret': client_secret }, headers={ 'Authorization': f'Bearer {access_token}', 'Content-Type': 'application/x-www-form-urlencoded' } ) # This is where we get the "invalid_client" error print(migration_response.status_code, migration_response.text) What we've tried: Verified all IDs (client ID, team ID, key ID) match between our code and the Apple Developer portal. Ensured the JWT is correctly signed with the ES256 algorithm. Checked that the client secret hasn't expired. Verified the content type is set correctly for all requests. Waited 72h+ since the key was first generated. Questions: Could the lack of web configuration in the original app be causing this issue? If so, how can we rectify this post-transfer? Is there a specific way to handle migrations for apps that were only configured for iOS Sign In with Apple? Are there any known issues or additional steps required when the old and new bundle IDs differ slightly (e.g., with/without '24' at the end)? How can we further diagnose the root cause of this "invalid_client" error, given that it occurs at different stages depending on the client ID used? Any insights, suggestions, or solutions would be greatly appreciated - I really don't know what to try at this point... Thank you in advance for your help!

"Sign in with Apple" logo - how to make personalized for MacOS using my customized logo for the specific application?

Hi! Like a bunch of people on the forums I'm having issues transferring my users from my previous Team to my new Team. When the app was still on the old team, I successfully generated transfer_subs for every one of my apple login users. Now, when trying to migrate them over, it ONLY works on users that have already signed in since the transfer, which is not good, I need to transfer the rest and get the new private relay emails. Here’s a curl of how I get my access token : I’m first generating the secret key using my team key that has apple sign in configured for it. curl --location 'https://appleid.apple.com/auth/token' --header 'Content-Type: application/x-www-form-urlencoded' --data-urlencode 'grant_type=client_credentials' --data-urlencode 'scope=user.migration' --data-urlencode 'client_id=my.app.id' --data-urlencode 'client_secret=*** This works and I’m getting my access token, then I try to exchange the sub token curl --location 'https://appleid.apple.com/auth/usermigrationinfo' --header 'Content-Type: application/x-www-form-urlencoded' --header 'Authorization: Bearer *** ' --data-urlencode 'transfer_sub=xx.xxxx' --data-urlencode 'client_id=my.app.id' --data-urlencode 'client_secret=***’ This is when I receive : {"error":"invalid_request","email_verified":false} I’ve tried a lot of stuff, even got on the phone with an ex apple engineer and tried a bunch of stuff with him, but to no avail. I've submitted a report on feedback assistant on the 23rd August, but no answer yet. ID: 14898085

This is a continuation of https://developer.apple.com/forums/thread/760861 Still a mixed Qt/C++/ObjC app, developed with Qt Creator. The gist ist that I can call Sign in With Apple and authorise, but once the Authorisation Window/Panel goes away, the app is blocked. PBSigninWithApple:: PBSigninWithApple() { myImpl = [[PBSigninWithApple alloc] initWithOwner:this]; } - (id)initWithOwner:(PBSigninWithApple *) owner { self = [super init]; myOwnerSIWA = owner; ASAuthorizationAppleIDProvider *appleIDProvider = [ASAuthorizationAppleIDProvider new]; ASAuthorizationAppleIDRequest *request = appleIDProvider.createRequest; request.requestedScopes = @[ASAuthorizationScopeFullName, ASAuthorizationScopeEmail]; ASAuthorizationController *controller = [[ASAuthorizationController alloc] initWithAuthorizationRequests:@[request]]; controller.presentationContextProvider = self; controller.delegate = self; [controller performRequests]; return self; } The code example above is obviously reduced, but the real things works. I get the Sign in With Apple window and can authorise by TouchId. The didCompleteWithAuthorization and didCompleteWithError methods also work, emitting the the idendityToken to the calling superclass works, the authorisation window goes away - but not really. The calling QT app is semi-blocked. I can close windows ny using the Escape key, but any clicking just gives the dreaded beep and nothing happens. So I assume that we didn‘t tear down everything and that the anchor or whatever still has to focus. - (void)authorizationController:(ASAuthorizationController *)controller didCompleteWithAuthorization:(ASAuthorization *)authorization API_AVAILABLE(macos(10.15)) { if ([authorization.credential isKindOfClass:[ASAuthorizationAppleIDCredential class]]) { ASAuthorizationAppleIDCredential *appleIDCredential = authorization.credential; NSString *user = appleIDCredential.user; NSData *identityToken = appleIDCredential.identityToken; NSData *authorizationCode = appleIDCredential.authorizationCode; emit myOwnerSIWA->accessCodeReceived(identityToken); } [[NSNotificationCenter defaultCenter] removeObserver:self name:ASAuthorizationAppleIDProviderCredentialRevokedNotification object:nil]; [myAnker close]; [self release]; } - (void)authorizationController:(ASAuthorizationController *)controller didCompleteWithError:(ASAuthorization *)authorization API_AVAILABLE(macos(10.15)) { emit myOwnerSIWA->accessCodeReceived(QString("")); [[NSNotificationCenter defaultCenter] removeObserver:self name:ASAuthorizationAppleIDProviderCredentialRevokedNotification object:nil]; } -(ASPresentationAnchor)presentationAnchorForAuthorizationController:(ASAuthorizationController *)controller API_AVAILABLE(macos(10.15)) { NSRect frame = NSMakeRect(30, 30, 230, 230); NSUInteger windowStyle = NSWindowStyleMaskTitled | NSWindowStyleMaskClosable | NSWindowStyleMaskResizable | NSWindowStyleMaskFullSizeContentView; NSWindow* window = [[[NSWindow alloc] initWithContentRect:frame styleMask:windowStyle backing:NSBackingStoreBuffered defer:NO] autorelease]; window.minSize = CGSizeMake(200, 100); window.releasedWhenClosed = TRUE; myAnker = window; return window; }

We did an app transfer in mid-August as part of our process to incorporate the business. We have approximately 100,000 users who have logged in with their Apple IDs, and as part of the transfer process, we followed the documentation below to transfer the account information. https://developer.apple.com/documentation/sign_in_with_apple/bringing_new_apps_and_users_into_your_team During the identifier exchange process, an invalid_request error occurred for approximately 10,000 users. https://developer.apple.com/documentation/sign_in_with_apple/bringing_new_apps_and_users_into_your_team#3559300 We successfully transferred the remaining users using the same script and procedure. Even when repeated multiple times, the error consistently occurs with the same users. Based on this situation, we believe that the error may be caused by user-related factor. Specifically, we would like to understand the potential causes of request errors other than the reasons listed below. The only user-related cause, ‘The user has revoked authorization for the client,’ is not relevant to this case, as it pertains to an error when issuing the transfer identifier. (not exchanging) https://developer.apple.com/documentation/technotes/tn3107-resolving-sign-in-with-apple-response-errors#Possible-reasons-for-invalid-request-errors Details of the request content are documented in FB14898615. Although we submitted feedback from the account after the transfer, we have not received a response for over a week, so we are reaching out here as well. [Similar problem] https://developer.apple.com/forums/thread/761968

The user migration API (https://appleid.apple.com/auth/usermigrationinfo) is inconsistent when we call it with the correct parameters and tokens to retrieve new user subs/emails for users made under a previous Entity before completing an Entity Transfer: 65% of our requests return with no new sub or email and we receive an {'error': 'invalid_request', 'email_verified': False} response back from the API when sending it our transfer subs. 34% of our requests succeed in getting a sub but no new private relay email from the same API with the same parameters- isn't it always supposed to return an email? 1% of our requests successfully responded with a new sub and private relay email. We know it is not from anything in the request expiring because we regenerate the secrets, access_tokens, and transfer subs before making each request. All the other parameters are exactly the same as the successful API calls. I can respond over email with more app/team-specific details or our request code. Thanks!

We've encountered an issue with implementing "Sign in with Apple." We've set up an authorization mechanism that returns a JWT, which includes the following fields in the IdTokenPayload: iss, aud, exp, iat, sub, at_hash, email, email_verified, auth_time, and nonce_supported. We tested this using an Apple ID that had not previously been used with our app. At this stage, we expected to receive the user's name, but instead, the relevant fields are returning null values, and all we receive is the email address. Here’s an example of the JWT payload we're receiving: { "iss": "https://appleid.apple.com", "aud": "com.octocrm.webapp", "exp": 1724833875, "iat": 1724747475, "sub": "000335.ad7cef1b0a3c474b842531f95444f2ad.1205", "at_hash": "perz_dvgtpe4cglpuzzj-a", "email": "firma.pl", "email_verified": true, "auth_time": 1724747463, "nonce_supported": true } We were expecting the user's name fields (e.g., name, given_name, family_name) to be populated in the JWT, but instead, they are returning as null. Is there something we're missing in our implementation, or is there a specific condition that needs to be met for these fields to be included? Any guidance on how to resolve this issue would be greatly appreciated.

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

now there is a way for apple id to get into the code without a password

Recently our Sign In with Apple integration has been affected by an inconsistency in Apple token response, where the email_verified attributed has a false value in the response but inside the id_token payload the email_verifiedattribute is set to true (the correct value), our integration has been working as expected until recently and haven't found an official announcement on this change. When making a call to https://appleid.apple.com/auth/token to exchange a code for a token using curl -v POST "https://appleid.apple.com/auth/token" \ -H 'content-type: application/x-www-form-urlencoded' \ -d 'client_id=CLIENT_ID' \ -d 'client_secret=CLIENT_SECRET' \ -d 'code=CODE' \ -d 'grant_type=authorization_code' \ -d 'redirect_uri=REDIRECT_URI' We're getting the following response where email_verified is set to false { "access_token": "XXXXXXX", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "XXXXXXX", "id_token": "XXXXXX", "email_verified": false } But by inspecting the id_token payload the email_verified attribute has the correct value: true { "iss": "https://appleid.apple.com", "aud": "xxxxx", "exp": 1724433090, "iat": 1724346690, "sub": "xxxxxxxxx", "at_hash": "xxxxxxxxxxx", "email": "my-apple-id@gmail.com", "email_verified": true, "auth_time": 1724346672, "nonce_supported": true } I'd like to know the reason for this inconsistency, or if it is an issue and is under the Apple team's radar.

When developing an app that requires to sign up or login, I heard somewhere that I won't get an approval for the app if I don't implement the ability to login with apple account. Is that correct?

Hi, In our application, apple users have option to hide their email and continue with proxy email that apple provides to use our application feature. But we noticed that apple account created with gmail is having an issue where the email that we send from our apps is going to spam folder in gmail. All the other email domains used is working fine. Is anyone facing/faced this issue, please suggest a possible solution Thanks JM

After an app transfer, I'm reached this point in this article, and I need to check if the Sign In with Apple ID users I've migrated have the "transferred" status. This articles provides you with Swift code to check this status; does anyone know if there's a way to access this info using the Apple ID REST API, preferably with a curl command? Or do I specifically need to check this info on my app? Here's the swift code I'm talking about: let request = ASAuthorizationAppleIDProvider().createRequest() // Specify the current user identifier here. request.user = "User Identifier" let controller = ASAuthorizationController(authorizationRequests: [request]) controller.delegate = self controller.presentationContextProvider = self controller.performRequests()

Hello, I have a JS website that uses "Sign in with Apple" with AppleID.auth.signIn : It redirects to appleid.apple.com It redirects to my backend with a form POST Then I redirect the user to my frontend I bundled my website as a webview in an app for iOS. When using the functionality on iOS : A faceId popup appears over my app The user is redirected to appleid.apple.com A second faceId popup appears It redirects to my backend with a form POST it gets redirected to my frontend in an embeded Safari. When closing the embeded browser, the user is not connected on my app I would like my user to be redirected to my app instead of staying in the embeded browser. I would like to eliminate the double faceId popups The functionality works in the web (Safari desktop and mobile), as a PWA, and on Android. So I think I have properly configured the Domains and Redirect URLs in my Sign in with Apple service. When I click on a link that points to my website from Safari, it opens my iOS app. So I think I have properly configured the associated domains. When testing the functionality from an iPhone emulator in XCode, it works (but uses a simple appleId/password form instead of faceId) I could not find an answer on the forums that solved my problem. I can provide code and screen captures. Thank you

We're preparing to migrate our Apple Sign-In users for an upcoming app transfer. Following this guide, we're currently stuck on the first curl command: curl -v POST "https://appleid.apple.com/auth/token" \ -H 'Content-Type: application/x-www-form-urlencoded' \ -d 'grant_type=client_credentials' \ -d 'scope=user.migration' \ -d 'client_id=CLIENT_ID' \ -d 'client_secret=CLIENT_SECRET_ISSUED_BY_TEAM_A' Specifically, we're having issues generating the client secret, specified here. We're using a Node.js script to generate the script; initially I realized that the private key I was signing the JWT with was wrong (I was using the App Store Connect API team key instead of a private key for use with Account & Organization Data Sharing). Every time we try entering this curl command: curl -v POST "https://appleid.apple.com/auth/token" \ -H 'Content-Type: application/x-www-form-urlencoded' \ -d 'grant_type=client_credentials' \ -d 'scope=user.migration' \ -d 'client_id=com.jumbofungames.platMaker' \ -d 'client_secret=$(node clientsecret_jwt2.js)' Where $(node clientsecret_jwt2.js) is the command to generate the client secret; we get this error: < HTTP/1.1 400 Bad Request < Server: Apple < Date: Mon, 19 Aug 2024 15:41:31 GMT < Content-Type: application/json;charset=UTF-8 < Content-Length: 49 < Connection: keep-alive < Pragma: no-cache < Cache-Control: no-store < * Connection #1 to host appleid.apple.com left intact {"error":"invalid_client","email_verified":false}% Here is the script we are using to generate the Client Secret (JWT), with some variables using placeholders for privacy: const fs = require('fs'); const jwt = require('jsonwebtoken'); // npm i jsonwebtoken // You get privateKey, keyId, and teamId from your Apple Developer account const privateKey = fs.readFileSync("./AuthKey_ABCDEFG123.p8") // ENTER THE PATH TO THE TEAM KEY HERE (private key file) const keyId = "API_KEY"; // ENTER YOUR API KEY ID HERE const teamId = "TEAM_ID"; // ENTER YOUR TEAM ID HERE const clientId = "com.companyname.appname"; // ENTER YOUR APP ID OR SERVICES ID HERE (This is the client_id) // Time settings (in seconds) let now = Math.round((new Date()).getTime() / 1000); // Current time (seconds since epoch) let nowPlus6Months = now + 15776999; // 6 months from now (maximum expiration time) let payload = { "iss": teamId, // The Team ID associated with your developer account "iat": now, // Issued at time "exp": nowPlus6Months, // Expiration time (up to 6 months) "aud": "https://appleid.apple.com", // Audience "sub": clientId // The App ID or Services ID } let signOptions = { "algorithm": "ES256", // Algorithm for signing (ECDSA with P-256 curve and SHA-256 hash algorithm) header : { "alg": "ES256", // Algorithm in the header "kid": keyId, // Key ID in the header "typ": "JWT" // JWT type } }; // Generate the JWT (client_secret) let clientSecret = jwt.sign(payload, privateKey, signOptions); console.log(clientSecret); module.exports = clientSecret; If anyone has run into similar issues using this API or could shed some light on what could be going wrong, please let us know — we're at a bit of a loss here.

Hello, I’m transferring an app from my individual account to my corporate developer account. I’m the primary owner of both accounts. I’m trying to transfer the users that used Sign In with Apple and this is what I did: I generated the transfer identifier for all the users that used Sign In with Apple from the database (50.000 users → 100% success rate) I’m using the transfer identifier previously generated to create the new Apple ID and private email address of the user. (40% success rate) I successfully generated new Apple ID and private email address for 20.000 users but for the other 30.000 users I cannot generate it because I get { error: 'invalid_request’ } on the migration endpoint (/auth/usermigrationinfo), even though I'm using the same request parameters as the ones that are working. I couldn’t find any difference between users that could be migrated and the users that couldn’t. It doesn’t matter if they are old users or new users. What I found is that I can generate the new Apple ID and private email address if the user signs in with Apple for the first time after the app transfer. Then I can use the “transfer_sub” that I have stored for the user to generate the new user details. The same process worked fine for another app that I transferred. Something seems to be broken only for this app on 60% of the users that used Sign In with Apple. Please let me know if you need further information Best, Cosmin