Hi everyone! We recently integrated "Sign in with Apple" into our application using standard social login flows. For the vast majority of our users, the integration works perfectly—we receive the user's email during sign-in and sign-up. However, we are noticing an edge case where a small subset of users are returning an ID token that is completely missing the email. We can't seem to reproduce this error ourselves during testing. Every time we test a sign-up or sign-in, the email payload is included exactly as expected. My Questions: Is there a specific reason why Apple would omit the email claim from the ID token? Any insights or guidance would be greatly appreciated. Thank you!

We’re trying to determine whether an iOS authentication flow is safe for production when ASWebAuthenticationSession ultimately returns a reusable backend bearer token because the authentication provider does not support a native authorization-code/PKCE exchange. We have an iOS app built with React + Capacitor that uses @capgo/capacitor-inappbrowser for Apple/Google social login. The iOS flow uses ASWebAuthenticationSession. Our backend/auth provider is Base44. Base44 supports web OAuth, but they have confirmed they do not provide a supported native authorization-code / PKCE session exchange for externally wrapped Capacitor apps. Current flow: The app starts Base44 OAuth in ASWebAuthenticationSession. Base44 completes Apple or Google authentication. Base44 redirects to an HTTPS bridge page hosted on our Base44 app domain. The bridge receives the Base44 access token. The bridge redirects to our app callback URL scheme and includes that Base44 bearer token in the callback. The active ASWebAuthenticationSession receives the callback. The app validates the callback URL, verifies a one-time random state, sets the Base44 token and immediately calls auth.me() to confirm the authenticated account. We have already hardened the flow by: using a 256-bit random one-time state expiring pending login attempts after 10 minutes binding the state to the provider and locally stored return path validating callback scheme/host/path removing unsolicited/global deep-link authentication listeners using prefersEphemeralWebBrowserSession = true scrubbing token artifacts from the hosted bridge URL/local storage not trusting callback-supplied return paths verifying the Base44 account before marking native login complete We understand that the preferred native OAuth model is authorization code + PKCE, but the backend provider does not expose that capability for this integration. My question is: Given that ASWebAuthenticationSession delivers the authentication callback to the initiating session, is passing a reusable backend bearer token through that callback still considered unsuitable for a production iOS app? If it is unsuitable, is there any secure pattern available when the authentication provider does not support a native one-time code / PKCE exchange? We also need to preserve existing Apple/Google-linked Base44 accounts, user data and subscription entitlements, so replacing the authentication backend is not a simple migration. I would particularly appreciate guidance on whether: ASWebAuthenticationSession materially mitigates custom-scheme interception in this scenario changing to a Universal Link callback would materially improve the design if the bearer token still has to be transferred this architecture would be considered acceptable for an App Store production release

We have an iOS app built with React + Capacitor that uses @capgo/capacitor-inappbrowser for Apple/Google social login. The iOS flow uses ASWebAuthenticationSession. Our backend/auth provider is Base44. Base44 supports web OAuth, but they have confirmed they do not provide a supported native authorization-code / PKCE session exchange for externally wrapped Capacitor apps. Current flow: The app starts Base44 OAuth in ASWebAuthenticationSession. Base44 completes Apple or Google authentication. Base44 redirects to an HTTPS bridge page hosted on our Base44 app domain. The bridge receives the Base44 access token. The bridge redirects to our app callback URL scheme and includes that Base44 bearer token in the callback. The active ASWebAuthenticationSession receives the callback. The app validates the callback URL, verifies a one-time random state, sets the Base44 token and immediately calls auth.me() to confirm the authenticated account. We have already hardened the flow by: using a 256-bit random one-time state expiring pending login attempts after 10 minutes binding the state to the provider and locally stored return path validating callback scheme/host/path removing unsolicited/global deep-link authentication listeners using prefersEphemeralWebBrowserSession = true scrubbing token artifacts from the hosted bridge URL/local storage not trusting callback-supplied return paths verifying the Base44 account before marking native login complete We understand that the preferred native OAuth model is authorization code + PKCE, but the backend provider does not expose that capability for this integration. My question is: Given that ASWebAuthenticationSession delivers the authentication callback to the initiating session, is passing a reusable backend bearer token through that callback still considered unsuitable for a production iOS app? If it is unsuitable, is there any secure pattern available when the authentication provider does not support a native one-time code / PKCE exchange? We also need to preserve existing Apple/Google-linked Base44 accounts, user data and subscription entitlements, so replacing the authentication backend is not a simple migration. I would particularly appreciate guidance on whether: ASWebAuthenticationSession materially mitigates custom-scheme interception in this scenario changing to a Universal Link callback would materially improve the design if the bearer token still has to be transferred this architecture would be considered acceptable for an App Store production release

The issue below affects every partner app embedding our SDK, so we'd appreciate DTS taking a deeper look. We're happy to open a code-level support request and provide screen recordings and a sysdiagnose. Details are in FB25326312. We ship an SMS filtering SDK (a Message Filter app extension) that partner apps embed. Password AutoFill is treating the SDK's messagefilter: associated domain as a credential domain for the host app, so unrelated saved logins appear on the partner app's sign-in screen. Configuration Apple validates Message Filter network deferral against the containing app (an unauthorized containing app gets ILMessageFilterError.Code.networkURLUnauthorized), so the entitlement must be declared on each host app, not the extension: messagefilter:messagefilter.example.comThe AASA file at messagefilter.example.com lists the host app IDs under messagefilter only. It has no webcredentials key. Network deferral works as expected. (The real domain is in FB25326312.) Observed behavior On the host app's sign-in screen, saved logins for the SDK provider's domain (example.com) are suggested in the QuickType bar and the QuickType suggestions list: No webcredentials: domain: only example.com logins are suggested. App's own webcredentials: domain added (valid AASA entry): the app's logins appear, but example.com logins are still suggested alongside them. Password managers Reproduces with Apple Passwords and third-party password managers (tested with 1Password, Dashlane, and Norton Password Manager): Credential providers appear to receive the messagefilter domain in the serviceIdentifiers array passed to prepareCredentialList(for:). Some use only the first identifier, others use all of them. QuickType suggestions come from iOS itself, so the unrelated credentials appear regardless of which password manager is used. Seen on iOS 26 and iOS 27 in a production partner app. Questions Is it intended that a messagefilter: domain contributes to Password AutoFill credential matching? Is there a supported way to exclude it from AutoFill without breaking Message Filter network deferral?

Sign in with Apple fails for every App ID in our team (K9UFUZF2XW), on every device and every Apple ID we have tried. The system sheet appears, the user authenticates successfully, the sheet then shows "Sign Up Not Completed", and no credential is returned. The failure happens after authentication — this is not a client-side rejection. I have spent several days isolating this and have ruled out everything on my side. Posting the full evidence in case an Apple engineer can look at the server-side state for our team, and in case it helps others hitting the same wall. WHAT THE FRAMEWORK ACTUALLY RETURNS The client library we use (expo-apple-authentication) discards the original NSError, so I patched its native layer to surface the raw error verbatim. This is what ASAuthorizationController hands back to didCompleteWithError, immediately after the user authenticated and the sheet displayed "Sign Up Not Completed": ASAuthorizationError .canceled (rawValue = 1001) domain = com.apple.AuthenticationServices.AuthorizationError code = 1001 desc = The operation couldn't be completed. (com.apple.AuthenticationServices.AuthorizationError, error 1001) userInfo: NSUnderlyingError: So the framework reports a user cancellation that never happened, with a completely empty userInfo and no underlying error. There is no diagnostic information on the client at all — I cannot debug this any further from my side, because the information does not exist there. Note: the same failure surfaces as a different error code depending on the client library version — .unknown (1000) with the older version, .canceled (1001) with the current one. The user-visible behaviour ("Sign Up Not Completed") is identical in both. So the error code is not a reliable signal here. WHAT I RULED OUT Not the App ID. I created a brand-new App ID (kz.auraai.ios) with Sign in with Apple enabled as a primary App ID, built a fresh binary, tested on the same device with the same Apple ID — identical failure. Two independent App IDs in the same team fail the same way. Not the entitlement. Verified inside the signed binary, not just in the portal: application-identifier = K9UFUZF2XW.kz.auraai.ios com.apple.developer.applesignin = ["Default"] I also tried the workaround suggested elsewhere on these forums (removing the entitlement while keeping the capability in the portal). That made it strictly worse: iOS then rejects the request instantly, without showing the sheet at all. Which confirms iOS reads the entitlement correctly, the sheet works, and the user authenticates — the failure is downstream of all of that. No stray or wildcard App IDs. A commonly cited cause is other App IDs in the team lacking the entitlement. I enumerated the whole team via the App Store Connect API: it contains exactly two App IDs, both with APPLE_ID_AUTH = PRIMARY_APP_CONSENT. No wildcard identifiers exist. Not the Apple ID, the device, or the iOS version. The same Apple ID, on the same device, with the same iOS, signs in successfully through another app belonging to a different team (Expo Go, host.exp.Exponent) — a valid identity token is returned. A second, unrelated Apple ID on another device fails in my app in exactly the same way. So this is not scoped to one account: it affects every user of the app. Agreements and membership are in good standing. Program License Agreement accepted 30 June 2026; Developer Agreement accepted 26 June 2026; membership active. Both distribution types fail. TestFlight and ad-hoc. WHAT IS LEFT After all of the above, the only variable that differs between the working case (a different team's app, same device, same Apple ID) and the failing case (my app) is the Apple Developer team itself. This exact signature — sheet renders fully, final server submit fails, "Sign Up Not Completed", delegate reports canceled with no userInfo, not reproducible in other apps on the same device — is documented in thread 122458 ("Error: Sign-Up Not Completed"). In that case it affected multiple developers, including Apple's own sample app, and was ultimately resolved by Apple on the server side, with a recurrence reported in June 2025. THE ASK Could someone from Apple check the server-side Sign in with Apple registration for team K9UFUZF2XW (App IDs kz.auraai.app and kz.auraai.ios)? I am not looking for configuration advice — I have exhausted the client side and there is nothing left to configure. This looks like the same server-side state that was fixed in the referenced cases. Feedback Assistant: FB23716661 (includes sysdiagnose with the Accounts/AuthKit profile, timestamp, and video of the failure). This is currently blocking us: because Sign in with Apple works for none of our users, guideline 4.8 prevents us from offering Google Sign-In, so we are shipping with email-only login. Happy to provide the binary, entitlements dump, or a fresh sysdiagnose on request.

Hi, When I used Rork to sign in Apple Developer Account to test my App, I got this message below "Apple rejected the sign-in request before checking the credentials (Apple app-token request, HTTP 503). The client identity this app sends is probably out of date." Screenshot below Does anyone knows why? What should I do? Thanks!

Hello, I am developing an application that integrates with Apple Music to provide a personalized music video experience for Apple Music subscribers. We are working on support for many devices like Android TV / Google TV / WebOS / etc. and would like to implement an authorization experience suitable for a television, where entering account credentials with a remote control is cumbersome. Intended authorization flow We would like to implement the following experience: The application on the TV displays a QR code or short activation code. The user scans the QR code with their phone and opens an Apple-hosted authentication and authorization page. The user signs in to their Apple Account if necessary and approves Apple Music access for the application on the TV. The TV application receives or retrieves the resulting authorization and can use it for the supported Apple Music functionality. The objective is for the TV application itself to be authorized following approval on the phone, with no need to enter the Apple Account credentials on the television. Relevant implementation evidence found on Apple’s website While researching this integration, we examined JavaScript publicly served by link.apple.com. In the following OAuth view bundle, we observed these identifiers: PartnerAuthorizationRequest isOffDeviceOAuth2Flow DEVICE_CODE Source: Apple-hosted OAuth view bundle — oauth-views-OAuth-vue.4db9105e.js In the associated OAuth initializer bundle, we observed properties including: client_id scope response_type Source: Apple-hosted OAuth initializer bundle — oauth-views-OAuthInitializer-vue.23605d03.js These elements suggest that Apple’s authorization interface includes an off-device authorization path associated with partner clients. We understand that these implementation details are not public API documentation and do not establish whether this flow is available to third-party developers. We are looking for the officially supported integration and enrollment process, if one is available. Clarification requested 1. Availability for third-party TV applications Does Apple offer a supported Apple Music authorization flow of this kind for third-party applications running on non-Apple devices? If the observed flow is limited to certain integrations or partners, what are the eligibility requirements for obtaining access? 2. Client registration and account configuration What is the official process for registering or obtaining a client_id authorized to use this flow? We have reviewed the standard MusicKit configuration involving Media IDs, Media Services keys, App Services and Capability Requests, but have not identified the configuration or application process for off-device authorization. Could you clarify whether this requires: A standard MusicKit Media ID and Media Services key; An additional service configuration or managed capability request in the Apple Developer account; A separate OAuth client registration; Or approval through an Apple Music partner program? 3. Supported integration documentation If this integration is available, where can we obtain the documentation or SDK covering: The required client configuration, request parameters and permitted scopes; Creation of the authorization request and the QR code or activation link; The mechanism by which the TV checks for completion or receives the result; The resulting token type, its intended use, and its expiration or reauthorization requirements? In particular, we would appreciate clarification on whether the resulting authorization provides a Music User Token usable by the TV application, or another token that requires a documented exchange. 4. Apple Music access on the authorized TV Which Apple Music APIs or SDKs can consume the resulting authorization? We would like to confirm its supported use with Apple Music API and MusicKit for Android, including any separate requirements for playback on the TV. Our intended design is for authorization to be issued for the TV application, rather than transferring a Music User Token issued for the phone. If this access is handled outside the standard MusicKit developer workflow, could you please identify the applicable program and enrollment process, or who to route this request to the Apple Music team responsible for partner authorization and connected-device integrations? Thank you for helping us identify the supported path for this integration. Louis

Hello, I’m working on a security agent plugin for Mac. The plugin provides a mechanism with custom UI via SFAuthorizationPluginView and a privileged mechanism with the business logic. The plugin needs to support unlocking the device, so I changed the authorize right to invoke my agent: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>class</key> <string>evaluate-mechanisms</string> <key>created</key> <real>731355374.33196402</real> <key>mechanisms</key> <array> <string>FooBar:loginUI</string> <string>builtin:reset-password,privileged</string> <string>FooBar:authenticate,privileged</string> <string>builtin:authenticate,privileged</string> </array> <key>modified</key> <real>795624943.31730103</real> <key>shared</key> <true/> <key>tries</key> <integer>10000</integer> <key>version</key> <integer>1</integer> </dict> </plist> I also changed the system.login.screensaver right to use authorize-session-owner: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>class</key> <string>rule</string> <key>comment</key> <string>The owner or any administrator can unlock the screensaver, set rule to "authenticate-session-owner-or-admin" to enable SecurityAgent.</string> <key>created</key> <real>731355374.33196402</real> <key>modified</key> <real>795624943.32567298</real> <key>rule</key> <array> <string>authenticate-session-owner</string> </array> <key>version</key> <integer>1</integer> </dict> </plist> I also set screenUnlockMode to 2, as was suggested in this thread: macOS Sonoma Lock Screen with SFAutorizationPluginView is not hiding the macOS desktop. In the Display Authorization plugin at screensaver unlock thread, Quinn said that authorization plugins are not able to use Touch ID. However, on a MacBook with at touch bar, when I lock the screen, close the lid, and then open it, the touch bar invites me to unlock with Touch ID. If I choose to do so, the screen unlocks and I can interact with the computer, but the plugin UI stays on screen and never goes away, and after about 30 seconds the screen locks back. I can reliably reproduce it on a MacBook Pro with M1 chip running Tahoe 26.1. Is this a known macOS bug? What can I do about it? Ideally, I would like to be able to integrate Touch ID into my plugin, but since that seems to be impossible, the next best thing would be to reliably turn it off completely. Thanks in advance.

We develop an authorization plugin that replaces password entry at the login window and at screen unlock with a phone-based sign-in. The user scans a QR code with their phone, or the Mac reaches the phone over Bluetooth. Either way the plugin ends up with the user's password, which it hands to the authorization engine as if it had been typed. All networking runs in a LaunchDaemon that the plugin calls over XPC. Setup system.login.console: loginwindow:login → OurPlugin:login system.login.screensaver: rule use-login-window-ui → authenticate-session-owner-or-admin, with screenUnlockMode set to 2 authenticate: builtin:authenticate → OurPlugin:authenticate The UI is an SFAuthorizationPluginView subclass. On success we set username and password in the context (plus home at login) and call SetResult with kAuthorizationResultAllow. What we see on macOS 27 Since moving to macOS 27 on a MacBook Pro (M3 Pro), we hit these more often: Touch ID unlocks the Mac but leaves our view on screen. Open the lid and unlock with Touch ID. The desktop becomes usable, but our plugin view stays on top, and shortly after the screen locks again. Same symptom as thread 819454, where it was filed as FB22289735. Saved passwords disappear from apps after an unlock through our plugin. They come back only after the user logs out and in again. This looks like FB13128730 (thread 796487). The lock screen stays on the desktop after sign-in. The clock, the user picture and our view, with its filled-in password field, stay on screen while the menu bar and Dock are drawn on top of them. Similar to FB12074874. We also saw this once: the password field in our view would not take keyboard input at the lock screen. Every key press just played the system alert sound, and nothing was typed. Questions Is there any workaround for these on macOS 27? Or a supported way to stop macOS offering Touch ID while our plugin handles unlock? Is an SFAuthorizationPluginView plugin still a supported way to replace the login and unlock UI? If not, what should we move to? Is Platform SSO with the new web-based authentication in macOS 27 (login window, Lock Screen and FileVault unlock) the path you would recommend? If so, is there a supported option for offline sign-in, which we do over Bluetooth today?

I'm testing PRF evaluation with a YubiKey Bio through AuthenticationServices on iOS. Registration succeeds, but during later authentication with the enrolled fingerprint, I don't receive a PRF result. Using the key’s FIDO2 PIN works. Environment iPhone 12 iOS 27.0.1 YubiKey Bio connected through USB Firmware: 5.7.0 Steps to reproduce Configure a FIDO2 PIN and enroll a fingerprint on the YubiKey Bio. Connect the key to the iPhone. Register a credential using ASAuthorizationSecurityKeyPublicKeyCredentialProvider with PRF support requested. Request authentication for the registered credential with PRF input and userVerificationPreference = .required. Authenticate using the enrolled fingerprint. Check the returned PRF result. Compare this with authentication using the FIDO2 PIN. Expected result Successful authentication with PRF evaluation returns a 32-byte PRF output. Actual result No PRF result is returned when using fingerprint verification. The PIN flow works. Related report I found WebKit bug #314934, which reports missing PRF results with a YubiKey C Bio in Safari. The reporter observed successful authentication but a null PRF output. Could AuthenticationServices be affected by a similar issue? Is there a known limitation or workaround for PRF evaluation with YubiKey Bio fingerprint verification?

Our app signs users up through ASWebAuthenticationSession (not ephemeral). The sign-up page is a normal HTML form that posts to our server. When sign-up succeeds, the server redirects to our custom-scheme redirect_uri, which closes the session, as expected. When the user types a password and submits, iOS shows the "Save Password?" modal inside the session. From there, iOS 26 and iOS 27 behave differently: iOS 26.5: iOS waits. The form isn't sent until the user answers the modal. Then the request goes out, the redirect closes the session, and the password has been saved. iOS 27.0 and 27.2 beta 2: iOS doesn't wait. The form is sent right away, the redirect closes the session in under a second, and the modal disappears with it. The user never gets to tap Save. Things we checked: Same server, same page, same device, same app build. Only the iOS version changes the result. prefersEphemeralWebBrowserSession is off. Safari itself never waited on neither versions. The waiting only happened inside ASWebAuthenticationSession. Saving passwords still works on the device otherwise, and every test used a new account and password. Questions: Is the iOS 27 behaviour intended? If so, is there any supported way to let the user answer the sheet before the redirect closes the session? If it's a bug, is it tracked somewhere? The only fix we've found is to show an extra page after sign-up and only redirect from there, which adds a step for every user. We'd rather not ship that if the iOS 26 behaviour is coming back.

Our app's Sign in with Apple never completes. Apple's create-account sheet renders fully (name + share/hide-my-email step), then the final server submit fails and shows the "Sign Up Not Completed" sheet. The authorization callback returns ASAuthorizationError.canceled (1001) with no userInfo — even though the user did not cancel. Reproduced on multiple physical devices and multiple Apple IDs (all with 2FA), on iOS 26.5.1, since our first build. Team ID: 24XS837728 App ID: C54N9Q226H (bundle com.sucsessmaperrs.careerAssessmentApp) Verified on our side: com.apple.developer.applesignin = [Default] present in the distribution build (codesign -d --entitlements); embedded profile is the explicit App Store profile for the App ID (not wildcard). App ID has Sign in with Apple enabled as a primary App ID; capability deleted + recreated via the App Store Connect API today, no change. Firebase consumes the identity token; the failure is in Apple's UI before our code runs. App Store Connect agreements are clean. Key isolating fact: the same Apple ID on the same device completes a first-time Sign in with Apple sign-up in other third-party apps — only ours fails. So the cause appears scoped to our App ID / team on Apple's side, not the device, the Apple ID, 2FA, or our client code. This matches the widespread server-side "Sign Up Not Completed" failure in thread 675756 — same signature: multiple devices/Apple IDs, no console error, the failure delegate surfacing only as "cancel", newly created apps affected, even Apple's own sample app failing — which Apple ultimately resolved server-side (with a recurrence reported June 2025). Note this is the native ASAuthorizationController flow, not the REST/web flow, so the query-parameter percent-encoding fix from thread 122458 does not apply here. Could an Apple engineer check the server-side Sign in with Apple / account-association state for App ID C54N9Q226H (Team 24XS837728)? Happy to provide a screen recording or sysdiagnose.

We are hitting the same Sign in with Apple failure described in thread 837986, with an identical log signature. Posting our team details in case it helps the ongoing investigation. Team ID: CDLWFYN589 Bundle IDs: br.com.cesto, br.com.cestoparceiros App IDs created: 2026-08-20 (both recreated on that date) Build: TestFlight, iOS 26, physical iPhone SUMMARY Every first-time Sign in with Apple authorization fails with "Sign Up Not Completed". The Apple sheet renders correctly, with the right app name and the user's account. The user authorizes. The failure happens AFTER consent, in the SRP exchange with the Apple ID server. Our backend is never reached - signInAsync never returns a credential, so no server-side code of ours participates in the failing step. DEVICE LOG (akd, 2026-09-05 17:21:06-13, UTC-3) Client has default access level in SiwA entitlement Fetching developer team for client with ID: Encountered error while fetching developer team: Error Domain=AKSQLError Code=-6003 No applications were found with the provided Client ID: Application has no shared credentials Using personal credential state - 2, error - Error Domain=AKAuthenticationError Code=-7074 presenting authorization UI for request <- sheet appears Got a response from user <- user authorizes No password, but CK is available. Will ask for ck-based auth. Task <59764A72-...> received response, status 200 AppleIDAuthSupport: setError: 2:M2 missing (bad password) Invalid/missing value for key acname: (null) Invalid value for key ut: (null) Invalid value for key authType: (null) SRP authentication with server failed! Error Domain=com.apple.AppleIDAuthSupport Code=2 The server returns HTTP 200 with the server proof (M2) absent. The "bad password" string appears to be the generic label for error 2 rather than a diagnosis - there is no password in this exchange, as the preceding line shows (No password, but CK is available). WHAT WE HAVE ALREADY VERIFIED Capability APPLE_ID_AUTH present on both App IDs, with APPLE_ID_AUTH_APP_CONSENT: PRIMARY_APP_CONSENT (read back through the App Store Connect API). com.apple.developer.applesignin: [Default] present in the SHIPPED .ipa, verified with codesign -d --entitlements :- on the extracted payload rather than on the archive. Embedded profile is "iOS Team Store Provisioning Profile" and carries the entitlement (security cms -D -i embedded.mobileprovision). Bundle IDs match across the project config, Identifiers and App Store Connect. No other App ID in the team declares APPLE_ID_AUTH. Program License Agreement accepted on 2026-08-25; 2FA active on the account. Requesting only fullName, with no email scope, does not change the outcome. The log line "Client has default access level in SiwA entitlement" is what closes the client-side question for us: the entitlement is present and read correctly ON DEVICE, not merely present in our build output. QUESTION Given the confirmation earlier in thread 837986 for team GW7XA5CX69 - same build and same configuration starting to work with no changes on their side - this looks like the same server-side condition affecting recently created App IDs. Could our Team ID be included in that investigation? Happy to file a Feedback with the full log attached and post the number here if that is the preferred route.

Hi, I'm trying to understand how the new OpenID authentication in macOS 27 behaves after a user resets their password in the identity provider. I understand that Microsoft Entra ID does not currently support the new OpenID Platform SSO flow in macOS 27. I'm using Entra ID only as an example here, my question is about the general macOS behavior and should apply equally to other identity providers such as Okta, Google Workspace, or any other IdP that implements the required Platform SSO 2.0 / OpenID support. Example: Mac is configured with Platform SSO and AuthenticationMethod = OpenID FileVault is enabled the user already has an existing local account and login Keychain the user resets their IdP password remotely they no longer remember the old local Mac password at the next Mac login they authenticate successfully using the new OpenID web login What happens next? If AllowWebLoginPasswordSync is enabled, I understand that macOS can synchronize the new IdP password to the local Mac account. My main question is what happens to the existing Keychain. Does macOS preserve the existing login.keychain and its contents, or can the user lose access to it because the old local password is no longer known? I'm also interested in what happens to things that depend on the existing Keychain, for example: saved application credentials certificates and private keys Wi-Fi credentials Apple Account / iCloud sign-in state And how does Platform SSO 2.0 Key Service fit into this? Apple documentation says that Key Service can unlock the user's key bag before login. Does that also help preserve access to the existing login Keychain when the old local password is no longer available? In practical terms, I'm trying to understand whether macOS 27 finally supports this workflow without losing user data or credentials: User forgets the Mac password → resets their IdP password → signs in through OpenID → continues using the same Mac profile and Keychain normally. Thanks :)

Before promoting passkey registration, I would like to check whether the user device has platform authenticator (or passkey platform authenticator). While trying to search such feature in the docs, I cannot find it anywhere. Is this intended? If there is no such api, how can we know whether the user can register passkey?

Hi Apple Developers, I am attempting to create a Apple Sign In capability for a web app and I have attempted to configure my Services ID configuration on 2 devices in 4 browsers and I am unable to select Web Authentication Configuration > Website URLs from the list that I have added. I figured it would be easiest to share a video demonstrating what I am trying to do and proving that I cannot accomplish it. https://www.loom.com/share/b927b398ef2648e39e60c0fc76791c90 Any ideas?

Sign in with Apple is failing for every user, on every device, for our live App Store app. Each attempt fails inside Apple's native sign-in sheet with the error "Sign-Up Not Completed" — before any of our code runs (no ASAuthorizationController delegate callback is reached). Environment / identifiers: Bundle ID: online.framenet.app Team ID: 5F2256QJNT App Store app: FrameNet, App ID 6799345029 (approved and live as of Aug 24, 2026) Timeline: Last worked: Aug 8, 2026 Failing on every attempt since: Aug 14, 2026, across builds 12–16 Our sign-in code is unchanged between the working and failing period Already verified / attempted on our side: Sign in with Apple entitlement is present in the signed builds (confirmed via codesign entitlement dump) Capability is enabled on the App ID in Certificates, Identifiers & Profiles Provisioning profile is valid and includes the capability Removed and re-added the Sign in with Apple capability and regenerated the provisioning profile on Aug 17 — no change Google Sign-In in the same app works normally, so networking and the rest of the auth stack are fine Reproduced on multiple physical devices and Apple IDs Because the failure occurs inside Apple's own sign-in sheet before our code executes, this appears to be a server-side state problem with Sign in with Apple for our App ID, and nothing we change client-side has any effect. We were forced to ship v1.0 with Sign in with Apple disabled. A Developer Support case is already open for this: case 20000140460775. A screen recording and full environment details have been provided in that case. Has anyone from Apple seen this "Sign-Up Not Completed" state, and can engineering inspect/repair the server-side Sign in with Apple configuration for this App ID?

Sign in with Apple has never completed for our app. The native sheet presents correctly (name, Share/Hide My Email), but on confirmation it shows "Sign Up Not Completed" with a red exclamation. No identity token is returned; the delegate receives ASAuthorizationError 1001 only after the sheet is dismissed. The failure happens entirely inside the system sheet, before any callback reaches app code. Environment: iPhone 15 Pro Max / iOS 26.6, TestFlight builds. The Sign In with Apple capability was newly enabled on the App ID five days ago and the flow has failed on 100% of attempts ever since. (I'm withholding the Team ID / bundle ID here since this is public — happy to share them with an Apple engineer via the open support case or a Feedback report.) Implementation - identical to Apple's "Implementing User Authentication with Sign in with Apple" sample; we even replaced the third-party wrapper we originally used with this first-party version to rule it out, and the failure is unchanged: let provider = ASAuthorizationAppleIDProvider() let request = provider.createRequest() request.requestedScopes = [.fullName, .email] let controller = ASAuthorizationController(authorizationRequests: [request]) controller.delegate = self // controller strongly retained until completion controller.presentationContextProvider = self controller.performRequests() Verified correct (not assumed — extracted/inspected directly): Signed binary entitlements (extracted from the distributed IPA): com.apple.developer.applesignin = (Default), with the correct application-identifier and team-identifier for our team embedded.mobileprovision in the bundle contains the same entitlement App ID capability read back via the App Store Connect API: APPLE_ID_AUTH with APPLE_ID_AUTH_APP_CONSENT = PRIMARY_APP_CONSENT (portal shows "Enable as a primary App ID") Exactly one App ID in the account; no wildcard, no duplicates Program License Agreement accepted; nothing pending Already tried, no change: re-saving the capability in the portal; deleting and re-creating the capability via the App Store Connect API; generating a new provisioning profile after that re-registration and shipping a new build signed with it; Share My Email and Hide My Email; device restarts (iCloud + 2FA active); waiting 5+ days for propagation. This matches threads 789588, 789418 and 789323, and the service-side configuration issue described in thread 790827 (invalid_client / "Sign Up Not Completed" for developer accounts that created or edited app configurations, resolved server-side with no developer action). A Developer Support case and a TSI are already open. Question for Apple engineers: with the client implementation identical to the official sample and every developer-side artifact verified, is there anything left on the developer side that can produce this - or can the Sign in with Apple service-side registration for our client_id be checked? This is blocking an App Store release (the app was rejected under Guideline 4.8 and Sign in with Apple is the required remedy). A sysdiagnose captured during reproduction is available, and I can provide the Team ID, bundle ID and case numbers privately on request.