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.

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

Hi, I have implemented Sign in with Apple on Android four months ago, and it work perfectly. We are using React Native with expo, using expo-auth-session and firebase function to get code back to start the token validation process. However, recently we start to receive invalid_grant with no error description while token validation, however the same client secret works on firestore without issue, which confuses us. According to https://developer.apple.com/documentation/technotes/tn3107-resolving-sign-in-with-apple-response-errors, the common reasons that I receive invalid_grant are: The client_id does not match the client for which the code was issued. The code has expired or has been previously consumed by the validation server. Is there any way I could differentiate whether is client_secret wrong or the code was used or any other reasons?

Hello, Following a company split we are planning to transfer one of our apps, which has Sign in With Apple enabled, to another team. We want to provide a smooth migration experience for the users by minimizing downtime and avoiding the duplication of accounts in our database. In our backend we generate a client secret using the transferring team’s ID. We then use this client secret with the “https://appleid.apple.com/auth/token” endpoint which returns the identity token. With the above in mind, I have the following questions: If we don’t update the team ID immediately after the transfer in our backend, will the identity token returned by the endpoint above contain the transferring team user ID in the sub field or, will it contain the recipient team user ID? Is there any possibility that we will ever receive an identity token containing a transferring team user ID in the sub field after we accept the transfer? Thanks, Bruno

Hello everyone, I’m encountering an issue with Sign in with Apple in my watchOS app and would appreciate any guidance. Background: Initially, I did not have the Sign in with Apple capability enabled on my watchOS app. I have since enabled the capability and grouped it with my iOS app. For new user accounts created after this change, everything works perfectly: The credentialState check returns .authorized on both iOS and watchOS. However, for existing user accounts (created before enabling the capability on watchOS): The credentialState check returns not authorized on watchOS. The check still returns .authorized on iOS for these accounts. Error Details: When calling ASAuthorizationAppleIDProvider.credentialState(forUserID:) on watchOS for existing accounts, I receive the following error: Error Domain=AKAuthenticationError Code=-7074 "(null)" My Suspicions: I believe the issue arises because the existing Sign in with Apple tokens are only associated with the iOS app’s bundle identifier and not with the watchOS app’s bundle identifier. Since the capability wasn’t enabled on the watchOS app when these accounts were created, their tokens aren’t valid for the watchOS app. Questions: Is this the correct explanation for why the credentialState check fails on watchOS for existing accounts, resulting in the AKAuthenticationError Code=-7074 error? Can I update or migrate the existing accounts so that their Sign in with Apple tokens are valid for the watchOS app as well? If so, how can this be achieved? Are there any best practices for handling this situation without requiring users to re-authenticate or removing the credentialState check from the watchOS app? Goal: I want to maintain the credentialState check on the watchOS app because it works correctly for new accounts and is important for security. I’m looking for a solution that allows existing users to continue using the app on their Apple Watch without interruption or additional sign-in steps. Any help or suggestions would be greatly appreciated! Thank you!

So I’m (extremely) new to developing for iOS, and I’m looking to implement the “Sign in With Apple“ feature for an application that interacts with a server I’ve built. Following the guide I’m able to get a user’s email and name. When I send that information to my server to create a user account, do I need to do anything else (like validating that the email is actually associated with an Apple account or that the user actually owns it, etc)? I looked at the Sign in With Apple from the web article and it doesn’t seem like it’s relevant to my use case. Is it standard practice to just trust the client in the iOS world?

Our e-learning app has been rejected in App Review regarding compliance with guideline 4.8.0: Login Services. The following were Apple Support's feedback: The app uses a third-party login service like Google or Facebook, but does not appear to offer an equivalent login option with Sign in with Apple. Next Steps: Revise the app to offer an equivalent login option that meets all of the above requirements. If the app already includes a login option that meets the above requirements, reply to App Review in App Store Connect, identify which login option meets the requirements, and explain why it meets the requirements. Additionally, it would be appropriate to update the screenshots in the app's metadata to accurately reflect the revised app once another login service has been implemented. Note that Sign in with Apple meets the requirements specified in guideline 4.8. Now, regarding their instructions, the following are our queries: Our mobile app for iOS already has SSO login options for Google and Facebook. Could you clarify what is meant by "an equivalent login option"? Are there any specific third-party login services other than "Sign in with Apple" that already comply with the requirements in Guideline 4.8? We are using “Manual sign up/sign in”, “Continue with Google” and “Continue with Facebook” to let users sign up and sign in to our platform. As per the parameters involved with the third-party login, will using sign in with Apple solve the problem related to Guideline 4.8? So is it mandatory under Apple’s Guidelines to include "Sign in with Apple" now, in addition to other SSO options? If it is mandatory, how is it that many iOS apps do not include the "Sign in with Apple" option? From a technical perspective, what options are available to satisfy Apple’s guidelines in this regard? Could manual sign-in/sign-out features of the app cause any conflicts with compliance in this area? Looking forward to anyone's kind response that can help us resolve this issue. Thanks!

Hi everyone, We’ve been trying to submit our game to the App Store for quite some time now, but we’ve encountered multiple rejections despite addressing all the feedback we’ve received. Initially, we resolved a few issues, such as providing in-game screenshots without UI elements, but there is one recurring problem that continues to block us. Every time, the review team reports an issue with the “Sign in with Apple” feature, specifically stating: “You have canceled the Sign-In With Apple process. You may try to log in again.” This error only occurs when a user actively cancels the login process. However, we’ve tested the feature on multiple devices, including iPads and iPhones, targeting all iOS versions from 17 and above. The login process works flawlessly in all our tests. We’ve ensured that we are following Apple’s best practices and have meticulously reviewed our implementation numerous times and also reviewed with another team which implemented it the same way and did got approved. It’s becoming frustrating as the issue appears to be on the review side. We’ve even uploaded videos demonstrating various scenarios: successful login, canceled login, auto-login, etc., yet we still receive no detailed feedback. Each review cycle takes about 24 hours, which is significantly delaying our iOS launch. (The game has already launched on Android without any issues.) Has anyone experienced a similar situation, where a working feature consistently fails during App Store review? If so, how did you resolve it? We’re quite behind schedule and would appreciate any advice. The "Sign in with Apple" library we use (lupidan): https://github.com/lupidan/apple-signin-unity The Game is made with Unity (6000.0.19f1) Built with Xcode 16. Thank You! ------- This is the reviewer notes ------- Guideline 2.1 - Performance - App Completeness Submissions to App Review, including apps you make available for pre-order, should be final versions with all necessary metadata and fully functional URLs included; placeholder text, empty websites, and other temporary content should be scrubbed before submission. Make sure your app has been tested on-device for bugs and stability before you submit it, and include demo account info (and turn on your back-end service!) if your app includes a login. If you are unable to provide a demo account due to legal or security obligations, you may include a built-in demo mode in lieu of a demo account with prior approval by Apple. Ensure the demo mode exhibits your app’s full features and functionality. We will reject incomplete app bundles and binaries that crash or exhibit obvious technical problems. Issue Description The app exhibited one or more bugs that would negatively impact App Store users. Bug description: we were unable to login via Sign in with Apple Steps to reproduce bug: Tap on Sign in with Apple Sign in with Apple Canceled error Review device details: Device type: iPhone 13 mini and iPad Air (5th generation) OS version: iOS 18.0 Next Steps Test the app on supported devices to identify and resolve bugs and stability issues before submitting for review. If the bug cannot be reproduced, try the following: For new apps, uninstall all previous versions of the app from a device, then install and follow the steps to reproduce. For app updates, install the new version as an update to the previous version, then follow the steps to reproduce.

Hi all, I am in the process of preparing for an app transfer, and have sign-in with apple enabled. I have read the documentation thoroughly and multiple times, yet there are a few things I'd like to have a confirmation about, before taking the leap and risking that some users might experience any issues. If I understand correctly, after the migration if a user performs a sign-in with Apple, they will send an access_token that differs from the one they were sending when the app was assigned to the old team. In case I didn't take any action that means that my system would think this was a new user given the access_token has never been seen before, and therefore it will create a new user. Is that correct? Ok, so if that assumption is correct, I'd like to have a confirmation also of the way I intend to fix this, since we're doing an internal transfer and the database is going to be the same. I would get a TransferID for all users in my database that have used sign-in with Apple (I have already done that for one of my test users, successfully). After that, I will start the transfer, and accept it from the other team. Once that is done, I will call the migrationinfo endpoint from the other team, getting all the new access_tokens related to the transfer ids. With that information, I will update my databse, adding a relation from the new access token from team B that points to the same user as the access token that was given by team A, and I know which one it is because of the TransferID. Does that make sense? Would it work? I'm not a fan of messing with the login logic (having a look at transfer_ids, looking for matches, and so on), especially because there doesn't seem to be a way to test this. I believe the only risk is that a user might login after the app has been transferred but before I can upload the new access token to the database, but we can handle these (few, hopefully even zero cases) via ticketing. These are the resources I have read so far: https://developer.apple.com/documentation/technotes/tn3159-migrating-sign-in-with-apple-users-for-an-app-transfer#Preparing-to-migrate-users-for-an-app-transfer https://developer.apple.com/documentation/sign_in_with_apple/transferring_your_apps_and_users_to_another_team#3546291 https://developer.apple.com/documentation/sign_in_with_apple/bringing_new_apps_and_users_into_your_team My last question is: how can I test this before going live? Do I really have to just implement changes/update the DB and then go live, hoping that it will all work? Can't I do some sandbox transfer or anything like that? Even just creating like a "clone" of my app and transferring this one would be a huge boost for the confidence of this big leap. Thanks in advance.

Hi, I run a midsize business. Apple recommends for company owned devices and for other reasons to use Apple Business managed Apple IDs for the employees. After that, you have to use a MDM System for e.g. deploying apps and licenses. Testflight is an app that can be deployed too. But....Testflight can not more than to say "Hello" on a managed device. The use of Testflight and to test our developed apps is not possible with a managed ID. Can anyone explain to me this thinking or what is recommended than. Setting up a private Apple ID for that purpose...which on the other hand, Apple do not want or does not recommend.

Hi everyone, I am trying to implement 'Sign-in with Apple' to my website using nextauth verion 4.24.5 on next.js version 14.2.7. I set up the Apple ID and generated the Apple secret. The Apple ID is set to the service ID. Whenever I try and sign in on the site using Apple, (after submitting my username and password on the redirected appleid.com page), nextauth returns this error: [next-auth][error][OAUTH_CALLBACK_ERROR] https://next-auth.js.org/errors#oauth_callback_error id_token not present in TokenSet { error: TypeError: id_token not present in TokenSet { name: 'OAuthCallbackError', code: undefined }, providerId: 'apple', message: 'id_token not present in TokenSet' } This occurs even after specifying openid in the scope, setting the checks to pkce, setting the checks to state, setting idToken to true, and other changes to the config. I have used the AppleProvider from nextauth and my own custom provider and got the same result. The nextauth GoogleProvider works just fine so I know nextauth is set up properly. Do you know how I can fix this? my apple nextauth apple provider config: const customAppleProvider = { id: "apple", name: "Apple", type: "oauth", wellKnown: "https://appleid.apple.com/.well-known/openid-configuration", authorization: { params: { scope: "name email openid", response_mode: "form_post" }, }, state: true, checks: ["pkce"], idToken: true, clientId: process.env.APPLE_ID, clientSecret: process.env.APPLE_SECRET, profile(profile) { return { id: profile.sub, name: profile.name, email: profile.email, image: null, } }, };

I have implemented basic Sign in with Apple functionality to my app. When the app is launched, the user will be presented with a Continue with Apple view, where they can authenticate. Once signed in, they will return to a view that reads "Hello, [User's Name]". However, I cannot seem to figure out why the email and name return nil after authentication. For example, when authentication is successful, the HelloView simply reads "Hello, " with no name. I have it setup so that the users name and email are saved to AppStorage variables, and then inserted into a Profile class with SwiftData. import AuthenticationServices import SwiftData import SwiftUI struct ContentView: View { @Environment(\.colorScheme) var colorScheme @Environment(\.modelContext) var modelContext @AppStorage("email") var email: String = "" @AppStorage("firstName") var firstName: String = "" @AppStorage("lastName") var lastName: String = "" @AppStorage("userID") var userID: String = "" @Query var userProfile: [Profile] private var isSignedIn: Bool { !userID.isEmpty } var body: some View { VStack { if !isSignedIn { SignInView() } else { HomeView() } } } } struct SignInView: View { @Environment(\.colorScheme) var colorScheme @Environment(\.modelContext) var modelContext @AppStorage("email") var email: String = "" @AppStorage("firstName") var firstName: String = "" @AppStorage("lastName") var lastName: String = "" @AppStorage("userID") var userID: String = "" @Query var userProfile: [Profile] var body: some View { NavigationStack { Spacer() SignInWithAppleButton(.continue) { request in request.requestedScopes = [.email, .fullName] } onCompletion: { result in switch result { case .success(let auth): switch auth.credential { case let credential as ASAuthorizationAppleIDCredential: // User ID let userID = credential.user // User Info let email = credential.email print(email!) let firstName = credential.fullName?.givenName print(firstName!) let lastName = credential.fullName?.familyName print(lastName!) self.email = email ?? "" self.userID = userID self.firstName = firstName ?? "" self.lastName = lastName ?? "" createProfile() default: break } case .failure(let error): print("Error signing in with Apple: \(error.localizedDescription)") } } .signInWithAppleButtonStyle(colorScheme == .dark ? .white : .black) .frame(height: 50) .padding() .cornerRadius(12) .navigationTitle("[App Name]") } } func createProfile() { let newProfile = Profile(firstName: firstName, lastName: lastName, email: email, userID: userID) modelContext.insert(newProfile) } } This is how I have my HomeView setup: import SwiftData import SwiftUI struct HomeView: View { @Environment(\.modelContext) var modelContext @Query var user: [Profile] var body: some View { ForEach(user) { user in Text("Hello, \(user.firstName)") } } } #Preview { HomeView() } And here's the Profile class: import Foundation import SwiftData @Model class Profile { var firstName: String var lastName: String var email: String var userID: String init(firstName: String, lastName: String, email: String, userID: String) { self.firstName = firstName self.lastName = lastName self.email = email self.userID = userID } }

Hi Apple Developers, I'm facing an issue that call to https://appleid.apple.com/auth/token and it raised an error: invalid_client There is my URL that i'm getting a code: "https://www.facebook.com/v20.0/dialog/oauth?client_id=526484129769843&redirect_uri=https://abc.example-api.ss-ss.com/api/v1/accounts/facebook/callback&response_type=code&scope=email I'm using Key Id and Private Key in the file AuthKey_K5HK3H23KZ.p8 to generate to a Client Secret, Client ID is abc.example-api.ss-ss.com (It is the service id) and the code that i give at the above request. When i'm call to exchange access token, the error is showed My project is writing by dotnet core. I dont know why the client should be invalid. Can anyone help me please?

We have integrated Login with the Apple ID feature in our iOS App. Whenever a user tries to sign in with Apple ID from within our app, after authorizing the login process we get this error "Something went wrong". This happens with some iPhones whereas some users work fine without such an issue. At the same time the login with Apple ID in the same app works with some iPhone users without any issue. This is quite a strange problem and we cannot trace the root cause, if anyone has faced the same issue. Please do let me know.

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!