Hello, I have a question regarding the lifecycle of user consent and tokens in "Sign in with Apple." Specifically, I would like to understand the behavior of the auth/revoke API in relation to App Store Connect status changes. Impact of App Status Changes If an app is "Removed from Sale" or "Deleted" from App Store Connect, does Apple automatically revoke all associated user tokens and consent? Or is it still the developer's responsibility to programmatically revoke each user's token via the REST API to ensure the app is removed from the user’s "Apps Using Apple ID" list? API Availability after Removal Once an app is no longer available on the App Store (or its record is deleted in App Store Connect), is the auth/revoke REST API still accessible? I want to ensure that a developer can still perform necessary privacy clean-up tasks (revoking consent) even if the app is not currently distributed. Specific User Impacts of Non-Revocation If we do not call the revocation API, besides the app remaining in the "Sign in with Apple" list, what are the specific consequences for the user? Thank you for your guidance.

Hello. When a user revokes Apple Login authorization, I am expecting a webhook to be delivered to our configured endpoint, but I currently not receiving any at all. So I have some questions: Should the revoke event webhook be delivered in real-time? If it is not real-time, when is the webhook supposed to be sent? If my server fails to respond to the webhook request, does Apple retry the delivery? (Actually I couldn't find how to response in this scenario, but if I can) Thanks in advance.

I want to add the "Sign In with Apple" feature to my iPadOS application. I've already done the following: Include com.apple.developer.applesignin in mobileprovision Include com.apple.developer.applesignin in entitlements However, I'm getting the following errors: `Authorization failed: Error Domain=AKAuthenticationError Code=-7026 "(null)" UserInfo={AKClientBundleID=xxxx} LaunchServices: store (null) or url (null) was nil: Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={_LSLine=72, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler, _LSFile=LSDReadService.mm, NSDebugDescription=process may not map database} Attempt to map database failed: permission was denied. This attempt will not be retried. Failed to initialize client context with error Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={_LSLine=72, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler, _LSFile=LSDReadService.mm, NSDebugDescription=process may not map database} Failed to get application extension record: Error Domain=NSOSStatusErrorDomain Code=-54 "(null)" ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1000 "(null)" ` What is this problem? How can I solve it? Hoping someone can help, thank you!

Hello, I am implementing "Sign in with Apple" on my backend and validating the Identity Token (JWT) received from the client. I noticed that for some users who choose the "Hide My Email" option, the is_private_email claim is missing from the ID Token payload, even though the email address clearly belongs to the private relay domain (@privaterelay.appleid.com). Here is an example of the decoded payload I received: { "iss": "https://appleid.apple.com", "aud": "com.platform.elderberry.new.signinwithapple", "exp": 1764402438, "iat": 1764316038, "sub": "000851.86193ef81ad247feb673746c19424f28.0747", "c_hash": "3FAJNf4TILzUgo_YFe4E0Q", "email": "x8sqp2dgvv@privaterelay.appleid.com", "email_verified": true, "auth_time": 1764316038, "nonce_supported": true // "is_private_email": true <-- This field is missing } My Questions: Is the is_private_email claim considered optional in the ID Token? Is it safe and recommended to rely solely on the email domain suffix (@privaterelay.appleid.com) to identify if a user is using a private email? Any insights or official references would be appreciated. Thanks.

Hello, I am implementing "Sign in with Apple" on my backend and validating the Identity Token (JWT) received from the client. I noticed that for some users who choose the "Hide My Email" option, the is_private_email claim is missing from the ID Token payload, even though the email address clearly belongs to the private relay domain (@privaterelay.appleid.com). Here is an example of the decoded payload I received: { "iss": "https://appleid.apple.com", "aud": "xxx", "exp": 1764402438, "iat": 1764316038, "sub": "xxxxxxxx", "c_hash": "3FAJNf4TILzUgo_YFe4E0Q", "email": "xxx@privaterelay.appleid.com", "email_verified": true, "auth_time": 1764316038, "nonce_supported": true // "is_private_email": true <-- This field is missing } My Questions: Is the is_private_email claim considered optional in the ID Token? Is it safe and recommended to rely solely on the email domain suffix (@privaterelay.appleid.com) to identify if a user is using a private email? Any insights or official references would be appreciated. Thanks.

Hello Apple Developer community! While reading the SSC Full Terms and Conditions, I noticed that "Your app playground requires sign in" is a term for disqualification. If our app idea requires sign in for personalization and security, can we submit a prototype without the sign in feature and add it later before publishing the app? Or should we steer clear of app ideas that require sign in altogether?

Hi everyone, I am currently implementing Server-to-Server Notifications for Sign in with Apple. I’ve encountered a discrepancy between the official documentation and the actual payload I received, and I would like to clarify which one is correct. The Situation: I triggered an account deletion event via privacy.apple.com to test the notification flow. When my server received the notification, the type field in the JSON payload was account-deleted (past tense). The Issue: According to the official Apple documentation, the event type is listed as account-delete (present tense). Here is the discrepancy I am observing: Documentation: account-delete Actual Payload: account-deleted My Question: Is the documentation outdated, or is this a known inconsistency? Should I handle both strings (account-delete and account-deleted) in my backend logic to be safe, or is account-deleted the new standard? Any insights or confirmation from those who have implemented this would be greatly appreciated. Thanks!

I'm implementing Apple Sign-In in my Next.js application with a NestJS backend. After the user authenticates with Apple, instead of redirecting to my configured callback URL, the browser makes a POST request to a mysterious endpoint /appleauth/auth/federate that doesn't exist in my codebase, resulting in a 404 error. Tech Stack Frontend: Next.js 16.0.10, React 19.2.0 Backend: NestJS with Passport (using @arendajaelu/nestjs-passport-apple) Frontend URL: https://myapp.example.com Backend URL: https://api.example.com Apple Developer Configuration Service ID: (configured correctly in Apple Developer Console) Return URL (only one configured): https://api.example.com/api/v1/auth/apple/callback Domains verified in Apple Developer Console: myapp.example.com api.example.com example.com Backend Configuration NestJS Controller (auth.controller.ts): typescript @Public() @Get('apple') @UseGuards(AuthGuard('apple')) async appleAuth() { // Initiates Apple OAuth flow } @Public() @Post('apple/callback') // Changed from @Get to @Post for form_post @UseGuards(AuthGuard('apple')) async appleAuthCallback(@Req() req: any, @Res() res: any) { const result = await this.authService.socialLogin(req.user, ipAddress, userAgent); // Returns HTML with tokens that uses postMessage to send to opener window } Environment Variables: typescript APPLE_CLIENT_ID=<service_id> APPLE_TEAM_ID=<team_id> APPLE_KEY_ID=<key_id> APPLE_PRIVATE_KEY_PATH=./certs/AuthKey_XXX.p8 APPLE_CALLBACK_URL=https://api.example.com/api/v1/auth/apple/callback FRONTEND_URL=https://myapp.example.com The passport-apple strategy uses response_mode: 'form_post', so Apple POSTs the authorization response to the callback URL. Frontend Implementation Next.js API Route (/src/app/api/auth/apple/route.js): javascript export async function GET(request) { const backendUrl = new URL(`${API_URL}/auth/apple`); const response = await fetch(backendUrl.toString(), { method: "GET", headers: { "Content-Type": "application/json", }, }); const responseText = await response.text(); return new NextResponse(responseText, { status: response.status, headers: { "Content-Type": contentType || "text/html" }, }); } Frontend Auth Handler: javascript export const handleAppleLogin = (router, setApiError) => { const frontendUrl = window?.location?.origin; // Opens popup to /api/auth/apple window.open( `${frontendUrl}/api/auth/apple`, "appleLogin", "width=500,height=600" ); }; The Problem Expected Flow: User clicks "Login with Apple" Frontend opens popup → https://myapp.example.com/api/auth/apple Frontend proxies to → https://api.example.com/api/v1/auth/apple Backend redirects to Apple's authentication page User authenticates with Apple ID Apple POSTs back to → https://api.example.com/api/v1/auth/apple/callback Backend processes and returns success HTML Actual Behavior: After step 5 (user authentication with Apple), instead of Apple redirecting to my callback URL, the browser makes this unexpected request: POST https://myapp.example.com/appleauth/auth/federate?isRememberMeEnabled=false Status: 404 Not Found Request Payload: json { "accountName": "user@example.com", "rememberMe": false } Network Tab Analysis From Chrome DevTools, the call stack shows: send @ app.js:234 ajax @ app.js:234 (anonymous) @ app.js:10 Ee.isFederated @ app.js:666 _callAuthFederate @ app.js:666 The Ee.isFederated and _callAuthFederate functions appear to be minified library code, but I cannot identify which library. What I've Verified ✅ The /appleauth/auth/federate endpoint does not exist anywhere in my codebase: bash grep -r "appleauth" src/ # No results grep -r "federate" src/ # No results ✅ Apple Developer Console shows only ONE Return URL configured (verified multiple times) ✅ Changed callback route from @Get to @Post to handle form_post response mode ✅ Rebuilt frontend completely multiple times: bash rm -rf .next npm run build ✅ Tested in: Incognito/Private browsing mode Different browsers (Chrome, Firefox, Safari) Different devices After clearing all cache and cookies ✅ No service workers registered in the application ✅ No external <script> tags or CDN libraries loaded ✅ package.json contains no AWS Amplify, Auth0, Cognito, or similar federated auth libraries ✅ Checked layout.js and all root-level files - no external scripts Additional Context Google Sign-In works perfectly fine using the same approach The mysterious endpoint uses a different path structure (/appleauth/ vs /api/auth/) The call appears to originate from client-side JavaScript (based on the call stack) The app.js file with the mysterious functions is the built Next.js bundle Questions Where could this /appleauth/auth/federate endpoint be coming from? Why is the browser making this POST request instead of following Apple's redirect to my configured callback URL? Could this be related to the response_mode: 'form_post' in the Apple Passport strategy? Is there something in the Apple Developer Primary App ID configuration that could trigger this behavior? Could this be a Next.js build artifact or some hidden dependency? The mysterious call stack references (Ee.isFederated, _callAuthFederate) suggest some library is intercepting the Apple authentication flow, but I cannot identify what library or where it's being loaded from. The minified function names suggest federated authentication, but I have no such libraries in my dependencies. Has anyone encountered similar issues with Apple Sign-In where an unexpected endpoint is being called?

I placed apple.logo symbol image on the top of a view. This view is used to link or unlink Apple ID for user. In the middle is the apple sign in button. I want to use something to describe or represent what the view is, instead of using text description. so I think sign in's company logo is a good choice. Is it allowed by apple official?

Hi Apple Developer Community, We have carefully reviewed the documentation on App Transfer and User Migration, but we still have a few unresolved questions regarding Apple Sign-In token behavior and testing strategies. Would appreciate any guidance! Token Behavior for Pre-Transfer App Versions After the app transfer: If a user logs in via an existing pre-transfer version of the app (published under Team A before transfer), will the Apple Sign-In token’s sub (or private email) switch to new value tie to Team B, or unchanged? This is critical for our user migration plan. Preserving sub Across Transfers (Internal Team Transfer) Since our app-transfer is an internal transfer (no change in app ownership outside our organization), is there a way to retain the original sub value（or private email） for users after the transfer? We are concerned that Apple Sign-In errors during the app transfer process may negatively impact user experience. Testing the Transfer Process Safely We’d like to simulate the app transfer and user migration process in a sandbox/test environment before executing it in production. Is there a way to test app transfers without affecting live users? (e.g., a staging mode for transfers) Thank you for your expertise! Any insights would be invaluable.

Question detail Dear Apple Developer Technical Support, We are currently following the official Apple documentation “TN3159: Migrating Sign in with Apple users for an app transfer” to carry out a Sign in with Apple user migration after successfully transferring several apps to a new developer account. Here is a summary of our situation: Under the original Apple developer account, we had five apps using Sign in with Apple, grouped under a shared primary app using App Grouping. Recently, we transferred three of these apps to our new Apple developer account via App Store Connect. After the transfer, these three apps are no longer associated with the original primary App ID. We reconfigured individual Services IDs for each app in the new account and enabled Sign in with Apple for each. More than 24 hours have passed since the app transfer was completed. Now we are attempting to follow the migration process to restore user access via the user.migration flow. Specifically, we are using the following script to request an Apple access token: url = "https://appleid.apple.com/auth/token" headers = {"Content-Type": "application/x-www-form-urlencoded"} data = { "grant_type": "client_credentials", "scope": "user.migration", "client_id": "com.game.friends.ios.xxxx", # New Primary ID in the new account "client_secret": "<JWT signed with new p8 key>" } response = requests.post(url, headers=headers, data=data) However, the API response consistently returns: { "error": "invalid_client" } We have verified that the following configurations are correct: The client_secret is generated using the p8 key from the new account, signed with ES256 and correct key_id, team_id, and client_id. The client_id corresponds to the Services ID created in the new account and properly associated with the migrated app. The scope is set to user.migration. The JWT payload contains correct iss, sub, and aud values as per Apple documentation. The app has been fully transferred and reconfigured more than 24 hours ago. Problem Summary & Request for Support: According to Apple’s official documentation: “After an app is transferred, Apple updates the Sign in with Apple configuration in the background. This can take up to 24 hours. During this time, attempts to authenticate users or validate tokens may fail.” However, we are still consistently receiving invalid_client errors after the 24-hour waiting period. We suspect one of the following issues: The transferred apps may still be partially associated with the original App Grouping or primary App ID. Some Sign in with Apple configuration in Apple’s backend may not have been fully updated after the transfer. Or the Services ID is not yet fully operational for the transferred apps in the new account. We kindly request your assistance to: Verify whether the transferred apps have been completely detached from the original App Grouping and primary App ID. Confirm whether the new Services IDs under the new account are fully functional and eligible for Sign in with Apple with user.migration scope. Help identify any remaining configuration or migration issues that may cause the invalid_client error. If necessary, assist in manually ungrouping or clearing any residual App Grouping relationships affecting the new environment. We have also generated and retained the original transfer_sub identifiers and are fully prepared to complete the sub mapping once the user.migration flow becomes functional. Thank you very much for your time and support!

Hello, I’m experiencing an issue with email deliverability when sending messages through Apple’s private email relay service. Our app uses “Sign in with Apple” and sends communication emails to users through relay addresses . Messages are successfully delivered but are consistently being placed in users’ spam or junk folders. Configuration summary: Domain: myapp.example Mail server: OVH SMTP SPF and DKIM: Active and validated Domain and sender registered under “Sign in with Apple for Email Communication” Messages pass SPF and DKIM checks successfully, but emails relayed by Apple’s private service are still being marked as spam. Could anyone confirm if there are additional steps or configurations required to improve deliverability (e.g., DMARC alignment or specific header requirements)? Thank you for your help!

Private relay emails are not being delivered, even though we've followed the guidance here, https://developer.apple.com/help/account/capabilities/configure-private-email-relay-service/ iCloud, gmail etc. get delivered fine but as soon as its a private relay email address they get bounced as unauthorized sender. We've tried a couple of domains but here I'll document test.x.domain.com We have registered domains (test.x.domain.com), also the sender communication emails just to be safe (noreply at test.x.domain.com). Passed SPF Authentication, DKIM Authentication. ESP account shows as all green checks in mailgun. Is there any way to track down what the actual rejection reason is? { "@timestamp": "2025-08-20T14:30:59.801Z", "account": { "id": "6425b45fb2fd1e28f4e0110a" }, "delivery-status": { "attempt-no": 1, "bounce-type": "soft", "certificate-verified": true, "code": 550, "enhanced-code": "5.1.1", "first-delivery-attempt-seconds": 0.014, "message": "5.1.1 <bounce+b53c9e.27949-6qj4xaisn4k=privaterelay.appleid.com@test.x.domain.com>: unauthorized sender", "mx-host": "smtp3.privaterelay.appleid.com", "session-seconds": 1.7229999999999999, "tls": true }, "domain": { "name": "test.x.domain.com" }, "envelope": { "sender": "noreply@test.x.domain.com", "sending-ip": "111.22.101.215", "targets": "6qj4xaisn4k@privaterelay.appleid.com", "transport": "smtp" }, "event": "failed", "flags": { "is-authenticated": true, "is-delayed-bounce": false, "is-routed": false, "is-system-test": false, "is-test-mode": false }, "id": "1gtVBeZYQ0yO1SzipVP99Q", "log-level": "error", "message": { "headers": { "from": "\"Test Mail\" <noreply@test.x.domain.com>", "message-id": "20250820143058.7cac292cf03993f2@test.x.domain.com", "subject": "Test Mail", "to": "6qj4xaisn4k@privaterelay.appleid.com" }, "size": 22854 }, "primary-dkim": "s1._domainkey.test.x.domain.com", "reason": "generic", "recipient": "6qj4xaisn4k@privaterelay.appleid.com", "recipient-domain": "privaterelay.appleid.com", "recipient-provider": "Apple", "severity": "permanent", "storage": { "env": "production", "key": "BAABAgFDX5nmZ7fqxxxxxxZNzEVxPmZ8_YQ", "region": "europe-west1", "url": [ "https://storage-europe-west1.api.mailgun.net/v3/domains/test.x.domain.com/messages/BAABAgFDXxxxxxxxxxxxxxNzEVxPmZ8_YQ" ] }, "user-variables": {} }

Hello. Some of my users are signing in using "Sign in with Apple" and choosing the "Hide My Email" option. As expected, Apple generates a private relay email address. However, emails that we send to these addresses are not being delivered — the users report that they are not receiving anything. We’ve configured our email sending domains in the Apple Developer portal, and all domains have been successfully verified with SPF records marked as OK. Our system is sending the emails as usual, and we're not receiving any bounce-back or error messages. Everything looks fine on our end. Is there something specific we need to configure to ensure emails sent to privaterelay.appleid.com addresses are delivered correctly? Are there any known limitations or additional requirements for using Apple's private relay service? Thank you!

Our app (app1) was recently transferred from Team A to Team B. While reviewing the Apple login implementation, we discovered that "Sign in with Apple" had been incorrectly set up to use the Service ID and App ID of another app (app2) — specifically, it was using app2.service as the Service ID and app2 as the App ID. In other words, app1’s users were authenticated through app2’s credentials due to a misconfiguration on our part. Now that app1 has been transferred to Team B, we’re trying to preserve those users. However, app2 is still in Team A, and we cannot maintain Team A anymore — meaning app2 must also be transferred to Team B if we want to retain access to the user data. One idea we considered is submitting app2 for App Review (even though it's non-functional) just to fulfill the transfer requirements, and then transferring it to Team B solely to retain the Apple login setup. Is this approach acceptable? Are there any recommended ways to handle this kind of misconfiguration while preserving existing Sign in with Apple users?

My existing iOS app has a legacy App ID prefix which does not match my Team ID. I am planning on migrating it to my Team ID. I am aware of the potential issues with keychain access groups, however I wanted to double check that there are no issues related to "Sign in with Apple". My app is currently the "Primary App ID" in the "Sign in with Apple" settings. The full App ID is listed there, including the prefix. Can someone from the relevant team at Apple confirm that changing the App ID prefix to Team ID has no effect related to "Sign in with Apple"?

Hi everyone, I have followed all the Apple procedures, read the forums, and looked at various experiences of other users who had my problem, but I haven’t found a solution. On my site, I have added login with all the “big” providers, and Apple is the only one missing. I’ve tried everything, but when the user logs in and is authenticated, I get an error. In order, here’s what I receive: Received Apple code: cfbf091dd6... JWT generated correctly HTTP Error (400): {"error":"invalid_client"} I’ve read all sorts of things, including that you have to wait up to 48 hours for the Key to be enabled. Any ideas? I’ve read that this is a common problem, but I haven’t found a valid solution. Thanks in advance to anyone who can help me.

Hi everyone, We just completed an App Store Connect app transfer between two developer teams and ran into what seems like an inconsistency with TN3159 (Migrating Sign in with Apple users for an app transfer). According to the technote, both the source and destination teams should be able to call /auth/usermigrationinfo for 60 days after the transfer, even if the migration wasn’t run beforehand. However, right after the transfer completed, the source team (Team A) started receiving: {"error":"invalid_client"} on all /auth/usermigrationinfo requests, even though /auth/token with scope=user.migration still works fine. What we verified before transfer: Team A’s Sign in with Apple key (ES256) was linked to the app and Services ID. OAuth flow for com.org.appname.web returned valid tokens, and the decoded ID token showed aud=com.org.appname.web with a valid private relay email, confirming the key was trusted. What happens after transfer: The key now shows “Enabled Services: —” and the App/Services IDs are no longer selectable in the Developer portal. /auth/usermigrationinfo immediately returns invalid_client for Team A, even within the same day of the transfer. This effectively makes Team A unable to generate transfer_sub values, blocking the migration flow TN3159 describes. Questions: Is Team A supposed to retain authorization to call /auth/usermigrationinfo for 60 days post-transfer? If yes, is there any known workaround to re-authorize the key or temporarily re-bind it to the transferred identifiers? If not, does this mean transfer_sub must be generated before transfer acceptance, contrary to how TN3159 reads? Would really appreciate any confirmation or guidance from Apple or anyone who’s gone through this recently. Thanks,

I understand from the recent Apple Developer News that Korean developers are now required to register a URL to receive notifications from the Apple server when creating or modifying a Sign in With Apple Service ID. However, it is not clear whether simply registering the URL is sufficient, or if it is also mandatory to implement the real-time processing of those notifications. I am inquiring whether the processing part is also a mandatory requirement.