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've been working to build Apple sign in into my application using a low code tool called GeneXus. The instructions seem pretty straight forward however it's not working when I try signing in from the app. See GeneXus instructions here: https://wiki.genexus.com/commwiki/wiki?44478,GAM+-+Apple+Authentication+type The only section that I didn't do was to verify the domain which according to the instructions is required for apple sign in to work. This was backed up by the GeneXus support team. I can't find how to verify the domain though? The support team seem to think Apple will send me the domain association file detailed in the link below and I simply add that to the server: https://developer.apple.com/documentation/xcode/supporting-associated-domains#Add-the-associated-domains-entitlement-to-your-app However I can't find where this file would be generated? I also can't see the button to register the domain in the first place!

Hello everyone, We recently transferred an iOS app but didn’t generate the transfer identifier before initiating the transfer. Is it still possible to generate the transfer identifier after the transfer has been completed? If not, are there any alternative solutions or steps we can take to resolve this issue? Thank you for any guidance!

I once changed my Apple ID. Before changing it, I had set up a passkey for the Apple ID website. After changing my Apple ID, whenever I log in to Apple ID, it still shows my previous Apple ID. Additionally, the passkey for the Apple ID website is not present in my 'Passwords' app, so I am unable to delete it.

Hello, One of the apps my team is developing is using Keycloak for allowing users to authenticate inside the application. We are using Keycloak primarily to act as the backend identity provider and not forcing users to authenticate via social logins (Facebook, Google, etc.). Under point 4.8 (at the time of posting) in the AppReview guidelines, would the app need to also offer another login service?

I am trying to send email from our internal server. We are using gmail as smtp client. Gmail is bound to a domain hosted on squarespace. I have all the required DNS records - DKIM, DMARC, SPF configured in squarespace. In the Apple Developer Portal, I have also added allowed domains and email addresses in the Sign In with Apple settings. SPF verification passed. The problem is that emails sent to @privaterelay.appleid.com are not reaching the final recipient. On our end, the emails are sent and there are no errors. In the email signature the DKIM domain and the domain in the From: address match completely. Domain on tools like mxtoolbox passes all checks. Also, there is no response from the gmail server that the email was not delivered. To all other emails the emails are being sent with no problems. Please help me figure this out, maybe I am missing something.

Hello there, we have implemented the Apple sign in our site, everything is working good except from two edge cases when the JWT returned by Apple sign in does not contain the user email, these cases are: When users choose Hide My Email when creating their account and later manually change their settings and turning off the email forwarding (Tested). For Apple at Work & School users. i.e. younger students may not have an email address. According to Apple docs, email could be empty for Sign in with Apple at Work & School users (Not tested). The problem is that we use the email to confirm the user authentication, but when the email is not present in the JWT, our system won't be able to find the registered user. We're currently working on a workaround for this, but we would like to confirm that these edge cases are known by apple and also ask some questions: Is it correct to say that: Turning off the email forwarding will cause that Apple's identity token (JWT) does not include the user's email address? Apple at Work & School users: is there a way to identify that someone is using this type of account? Is there any other known edge case when the email could be empty in the JWT? Thanks in advance!

Hello, I started looking to implement SSO with Apple on my website using this tutorial : https://developers.appcharge.com/docs/apple-sso-login However, when going to https://developer.apple.com/account/resources/identifiers/list to generate a new Key, i'm getting the error : "Unable to find a team with the given Team ID 'XXXXXXXX' to which you belong. Please contact Apple Developer Program Support". It was a breeze to implement Google SSO, but not for Apple. I can't find much help online, could you guide me ? Regards

I have implemented Sign in with Apple on website one weeks ago, and it work perfectly. However, recently we start to receive invalid_grant with no error description while token validation, however the same client secret works on IOS app without issue.... in ios app site , we used bundle id for client_id. in web site , we used service id for client_id; I try to create a new privateKey for web site and add redirect_uri params to /auth/token, but still error.... I tested it like this, i got authorization code using Service ID i tried authorization code with Service ID using browser : successfully got the code and requested access_token immately 2 and then, i tried validate the authorization grant code to obtain tokens curl like this curl -X POST https://appleid.apple.com/auth/token \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "client_id=my_service_id" \ -d "client_secret=my_client_secret" \ -d "code=sent_from_frontend" \ -d "grant_type=authorization_code" \ -d "redirect_uri=my_redirect_uri" then get fail and no error_description error_code is 400 invalid_grant is not invalid_client error, and client secret is not expired too My decoded token looks like the following : { "alg": "ES256", "typ": "JWT", "kid": "my_kid" } { "aud": "https://appleid.apple.com", "sub": "my_service_id", "iss": "team_id", "exp": 1744012650, "iat": 1728460650 }

When we develop 'Sign in with Apple' function on our app, we visited https://appleid.apple.com to verify the account. However, appleid.apple.com is mapped to an American IP, and it is not suitable for our app which is operated in China. I wonder whether there is a China Mainland IP available for the verification? Thanks very much.

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?