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.

We are integrating Sign in with Apple for our web application and have been stuck on an invalid_client error during the token exchange step. The Problem The authorization step works fine — the user authenticates on Apple's page and a valid authorization code is returned to our callback URL. However, when we exchange that code at https://appleid.apple.com/auth/token, it returns: {"error": "invalid_client"} The Puzzling Part When we send a dummy/expired authorization code with the exact same client_id and client_secret, Apple returns: {"error": "invalid_grant", "error_description": "The code has expired or has been revoked."} This confirms that our client credentials (client_id + client_secret JWT) are valid and accepted by Apple. The invalid_client error only occurs when a real, freshly-issued authorization code is used. Configuration Service ID configured with Sign in with Apple enabled Primary App ID with Sign in with Apple capability enabled Domain verified, Return URL registered Key created with Sign in with Apple enabled, linked to the correct Primary App ID Client Secret JWT Generated per Apple's documentation: Header: alg: ES256, kid set to our Key ID Claims: iss: Team ID iat: current timestamp exp: iat + 6 months (within Apple's limit) aud: https://appleid.apple.com sub: Service ID (matches the client_id used in authorization) Signed with: the .p8 private key associated with the Key Token Exchange Request POST https://appleid.apple.com/auth/tokenContent-Type: application/x-www-form-urlencodedclient_id=client_secret=code=grant_type=authorization_coderedirect_uri= What We've Tried Standalone test endpoint — built a minimal endpoint (no framework) that does the token exchange via server-side curl. Same invalid_client. Multiple Service IDs — created and tried 3 different Service IDs. All produce the same error with real codes. Multiple Keys — tried 2 different keys. Same error. Verified redirect_uri matches exactly between the authorization request and token request. Verified client_id matches exactly between the authorization URL and token request. Used client_secret_post (credentials in body, not Basic auth header). Freshness — code is used immediately upon receipt (within seconds), well before the 5-minute expiry. Filed a Developer Support case — was directed to Forums. Summary Scenario code Result Dummy/expired code abc123 invalid_grant (credentials accepted) Real fresh code from Apple callback invalid_client This pattern suggests something goes wrong specifically when Apple validates the authorization code against the client — even though the client credentials themselves are accepted in isolation. Has anyone encountered this behavior? Is there a known configuration issue that could cause invalid_client only with valid authorization codes? Any guidance would be greatly appreciated.

For my api I have a domain scheme of env.service.example.com. I am trying to setup sign in with apple, however, when trying to set my return urls, the env subdomain is stripped, making the return url incorrect. For example, when I try to set https://env.service.example.com/ it is changed to https://service.example.com/ when submitted. Is there any way around this issue?

Hi, we are experiencing a specific issue with the Private Email Relay service. Our domain e.glassesdirect.co.uk consistently fails SPF verification while our other domains pass. The Pattern: We've noticed that domains with SPF records fitting in 1-2 TXT strings pass, but this specific domain (~750 chars, 3 TXT strings) fails. Technical Details: Team ID: SM2J7LWD33 Domain: e.glassesdirect.co.uk SPF Record length: ~750 characters Third-party tools (MxToolbox) confirm the record is valid. We suspect Apple's verification parser might be failing to handle concatenated TXT strings or hitting a size limit. Could any Apple engineers confirm if there is a character limit or a bug in handling multi-part TXT records?

I set up "Sign in with Apple" via REST API according to the documentation. I can log in on my website and everything looks fine for the user. But I receive an email, that my "Sign in with Apple" account has been rejected by my own website. It states, I will have to re-submit my name and email address the next time I log in to this website. I don't see any error messages, no log entries, no HTTP errors anywhere. I also can't find anything in the docs, the emails seem to not be mentioned there, searching for anything with "rejected" in the forum did not yield any helpful result, because they are always about App entries being rejected etc. Did someone experience something similar yet? What's the reason, I'm getting these emails? I get them every time I go through the "Sign in with Apple" flow on my website again.

Problem Summary I'm experiencing a persistent invalid-credential error with Apple Sign-In on iOS despite having verified every aspect of the configuration over the past 6 months. The error occurs at the Firebase Authentication level after successfully receiving credentials from Apple. Error Message: Firebase auth error: invalid-credential - Invalid OAuth response from apple.com. Environment Platform: iOS (Flutter app) Firebase Auth: v5.7.0 Sign in with Apple: v6.1.2 Xcode: Latest version with capability enabled iOS Target: 13.0+ Bundle ID: com.harmonics.orakl What Actually Happens ✅ Apple Sign-In popup appears ✅ User can authenticate with Apple ID ✅ Apple returns credentials with identityToken ❌ Firebase rejects with invalid-credential error The error occurs at Firebase level, not Apple level. What I've Tried Created a brand new Apple Key (previous key was 6 months old) Tested with both App ID and Service ID in Firebase Completely reinstalled CocoaPods dependencies Verified nonce handling is correct (hashed to Apple, raw to Firebase) Activated Firebase Hosting and attempted to deploy .well-known file Checked Cloud Logging (no detailed error messages found) Disabled and re-enabled Apple Sign-In provider in Firebase Verified Return URL matches exactly Waited and retried multiple times over 6 months Questions Is the .well-known/apple-developer-domain-association.txt file required? If yes, how should it be generated? Firebase Hosting doesn't auto-generate it. Could there be a server-side caching/blacklist issue with my domain or Service ID after multiple failed attempts? Should the Apple Key be linked to the Service ID instead of the App ID? The key shows as linked to Z3NNDZVWMZ.com.harmonics.orakl (the App ID). Is there any way to get more detailed error logs from Firebase about why it's rejecting the Apple OAuth response? Could using a custom domain instead of .firebaseapp.com resolve the issue? Additional Context Google Sign-In works perfectly on the same app The configuration has been reviewed by multiple developers Error persists across different devices and iOS versions No errors in Xcode console except the Firebase rejection Any help would be greatly appreciated. I've exhausted all standard troubleshooting steps and documentation. Project Details: Bundle ID: com.harmonics.orakl Firebase Project: harmonics-app Team ID: Z3N....... code : // 1. Generate raw nonce final String rawNonce = _generateRandomNonce(); // 2. Hash with SHA-256 final String hashedNonce = _sha256Hash(rawNonce); // 3. Send HASHED nonce to Apple ✅ final appleCredential = await SignInWithApple.getAppleIDCredential( scopes: [AppleIDAuthorizationScopes.email, AppleIDAuthorizationScopes.fullName], nonce: hashedNonce, // Correct: hashed nonce to Apple ); // 4. Create Firebase credential with RAW nonce ✅ final oauthCredential = OAuthProvider("apple.com").credential( idToken: appleCredential.identityToken!, rawNonce: rawNonce, // Correct: raw nonce to Firebase ); // 5. Sign in with Firebase - ERROR OCCURS HERE ❌ await FirebaseAuth.instance.signInWithCredential(oauthCredential);

We use Sign in with Apple. Emails to @privaterelay.appleid.com bounce with "550 5.1.1 ...@send-subdomain: unauthorized sender" for 4+ days. Setup: Sending via Resend (Amazon SES, eu-west-1) From: siparis @ truefriends.com.tr, envelope: send.truefriends.com.tr All four Email Sources show green SPF in Certificates, IDs & Profiles: truefriends.com.tr (Domain) send.truefriends.com.tr (Domain) siparis @ truefriends.com.tr (Email) *@send.truefriends.com.tr (Email wildcard) — added today, no effect Test mail to non-Apple inbox: spf=pass, dkim=pass (d=truefriends.com.tr matches From), dmarc=pass. So full authentication is verified. Filed Feedback Assistant + Developer Support case 102902232938 — Tier 1 deflected to Feedback. Waiting for engineering response. Has anyone resolved a case where portal shows green ✓ but Relay still rejects as unauthorized? Internal sync issue?

Hi, it's very urgency! https://developer.apple.com/forums/thread/818346 After long time preparation, We finally execute this transfer operation today. Works fine at preliminary stage, lots of users had been transferred successfully. However, about 25% users transferred failed at the end, 'invalid_request' response from https://appleid.apple.com/auth/usermigrationinfo. No matter how many times we retry, it does work. Please help! 700,000 users are waiting us!

Hello Everyone I'm encountering a problem with the Apple Mail Private. I created a website with the possibility to log in with apple account and apple gives the possibility to privatize the mail address with xxxxx@privaterelay. appleid.com but also blocked the mail come from my server. In the log I get the error: relay=smtp3.privaterelay. appleid.com[17.56.9.14]:25, delay=2.4, delays=0.11/0/1.8/0.48, dsn=5.1.1, status=bounced (host smtp3.privaterelay. appleid.com[17.56.9.14] said: 550 5.1.1 mymail@mail. com: unauthorized sender (in reply to RCPT TO command)) How can I fix it ?

Hello, We are preparing to transfer an App Store app from one Apple Developer account/team to another. Our iOS app uses Sign in with Apple. However, in our legacy implementation, we did not store the Apple user subject identifier (sub) for many existing Apple login users. Our service primarily matched users by email. After reviewing Apple’s app transfer and Sign in with Apple migration documentation, we understood that we should generate a transfer identifier for each Sign in with Apple user before transferring the app. We have now started collecting and storing the sub value, but many legacy Apple login users still do not have their original sub value stored in our database. We are concerned about two main cases: Legacy users whose original Apple sub value was never stored For these users, we may not be able to generate the required transfer identifier before the app transfer. If the user uses Private Relay, we are also concerned that the email address we receive after the transfer may not match the email address we previously stored. In that case, our backend may not be able to match the post-transfer Sign in with Apple login to the user’s existing account, and the user may be treated as a new account. Users whose sub value is stored, but who do not sign in during the migration period For some users, we do have the Apple sub value and may be able to generate the transfer identifier before the app transfer. However, we are not sure what happens if those users do not sign in during the available Sign in with Apple migration period after the app transfer. If they sign in only after that period has ended, will the post-transfer Sign in with Apple user still be reliably mapped to the original pre-transfer user? The scenario we are worried about is: A user originally signed in with Apple before the app transfer. The app is transferred to another Apple Developer account/team. The user does not sign in during the Sign in with Apple migration period. After the migration period has ended, the same user signs in with Apple again. Our backend receives a new Apple user identifier and/or a different Private Relay email address. Our backend cannot correlate that login with the user’s original service account. The user may be treated as a new user and may lose access to their existing profile, activity history, chats, purchases, or other account data. Could someone confirm the expected behavior? Questions: If we have a legacy sub value and generate the transfer identifier before the app transfer, can the user still be mapped to the original account if they do not sign in during the Sign in with Apple migration period? After the migration period has ended, does Apple provide any identifier, token claim, API response, or other mechanism that allows us to correlate the post-transfer Sign in with Apple user with the pre-transfer user? For legacy users whose original sub value was never stored, is there any Apple-provided way to recover or map those users after the app transfer? Can a Private Relay email address change as part of or after an App Store app transfer? Should we avoid using email as a stable identifier for this migration? Should we delay the app transfer until we implement our own account recovery and account re-linking flow for all Sign in with Apple users? Environment: Platform: iOS Development environment: Xcode Runtime: iOS Framework: AuthenticationServices Feature: Sign in with Apple Context: App Store Connect app transfer between Apple Developer teams/accounts This issue does not appear to be specific to a particular iOS or Xcode version. We expect the development and runtime environments to be using the latest available versions of Xcode, macOS, and iOS at the time of submission. Any guidance on the correct migration behavior and the recommended implementation approach would be greatly appreciated.

Hello everyone, We are currently preparing for an App Transfer to a new Apple Developer account due to a corporate merger. We are trying to figure out the best way to handle Apple Sign-In user migration and would love to get some advice on our proposed fallback plan. 📌 Current Situation We need to transfer our app's ownership to a new corporate entity. The app heavily relies on Apple Sign-In. The Issue: We did not collect the transfer_sub values during our initial development phase. Although we started collecting them recently, we will not have them for all existing users by the time the transfer happens. 🚨 The Risk (The 60-Day Rule) Based on Apple's documentation, even if we provide the transfer_sub, users must log into the app within 60 days of the transfer to successfully migrate their accounts. This means that users who log in after 60 days, or those whose transfer_sub is missing, will fail the Apple migration process. They will be treated as "new users" and will lose access to their existing account data. 💡 Our Proposed Custom Recovery Flow Since we cannot rely entirely on Apple's automated migration, we are planning to build a custom internal account recovery process to prevent user drop-off: A user (who failed the migration or logged in after 60 days) attempts to use Apple Sign-In on the transferred app. Since the existing account isn't linked, Apple generates a new identifier (sub), and the user enters the new sign-up flow. During the sign-up process, we enforce a mandatory identity verification step (e.g., SMS phone number verification). We query our existing user database using this verified information. If a matching existing user is found: We interrupt the sign-up process and display a prompt: "An existing account was found. We will link your account." We then update our database by mapping the new Apple sub value to their existing account record, allowing them to log in seamlessly. ❓ My Questions App Review Risk: Could this manual mapping approach—overwriting the Apple sub on an existing account based on internal identity verification—violate any Apple guidelines or result in an App Store rejection? Shared Experiences: Has anyone dealt with missing transfer_sub values or the 60-day migration limit during an App Transfer? How did you mitigate user loss? Best Practices: Are there any alternative, safer, or more recommended workarounds for this scenario?

Hello everyone, I’m trying to better understand the expected behavior of Sign in with Apple after an app is transferred to another Apple Developer Team. Specifically, my question is about users who do not open or sign in to the app during the 60-day migration period after the app transfer. Here is the scenario we are concerned about: An existing user created an account using Sign in with Apple. The user is using a private relay email address. The app is transferred to another Apple Developer Team. The user does not sign in during the 60-day migration period. The user signs in again only after the 60-day period has ended. In this situation, is there any possibility that Apple may provide different user-related values compared to the values before the app transfer? For example, I am referring to values such as: sub private relay email address ID token claims any other API response value that may be used to identify the user The reason I’m asking is that if any of these values change after the transfer, our backend may not be able to match the user to the existing account in our database. In that case, the user could incorrectly be treated as a new user. My understanding is that the purpose of the Sign in with Apple migration process after an app transfer is to associate the user identifier from the original Team with the user identifier for the new Team. However, I would like to confirm what happens if the user was not processed during the 60-day migration period and signs in later. Do the values provided by Apple remain consistent in this case, or can they change after the migration period ends? If they can change, should we prepare our own account recovery or re-linking flow to handle these users? I would appreciate any clarification on Apple’s expected behavior and the recommended approach for this case. Thank you.

I've been struggling with "Sign in with Apple" for days. Firebase Authentication returns "configuration not found". I've tried everything. My configuration (all verified correct): App ID: com.pome.ai Services ID: come.pome.ai Key ID: 8UXM48JT9D (newly created) Apple Team ID: KDAMDMPNAW Domain: pome-ai.firebaseapp.com Return URL: https://pome-ai.firebaseapp.com/__/auth/handler What works: Android version (Google Sign-In) works perfectly Anonymous sign-in works What I tried: Created new Service ID and Key multiple times Verified Return URL has double underscore (__) Added authorized domains in Firebase Cleared iPhone cache, reinstalled app, restarted device Tested on different networks The error occurs only on iOS when tapping "Sign in with Apple". Firebase returns "configuration not found". Any help would be greatly appreciated.

Hi everyone, I'm experiencing a persistent issue with Sign in with Apple on my iOS app that I cannot resolve from my side. I've already opened a support case (ID: 20000115382721) and received a reply directing me back to the Developer Forum, so I'm posting here in hopes someone has encountered the same issue or can offer guidance. Error message: FirebaseAuthException: [firebase_auth/invalid-credential] Invalid OAuth response from apple.com Critical observation: The Apple authentication screen never appears. When the user taps "Continue with Apple", the error is returned immediately. This suggests the request is being rejected before reaching Apple's authentication servers — pointing to a backend configuration issue on Apple's side for my Team ID. My setup: Team ID: DHKU23JL7H Bundle ID: com.expensespy.app Framework: Flutter with sign_in_with_apple package v7.0.1 Backend: Firebase Authentication Other auth methods (Google Sign-In, Email/Password): working correctly Verified configuration (all done correctly): App ID (com.expensespy.app): Sign In with Apple capability is enabled Configured as a primary App ID Not grouped with any other App ID Service ID (com.expensespy.app.auth): Created and linked to the primary App ID Domain: expensespy-e11ab.firebaseapp.com Return URL: https://expensespy-e11ab.firebaseapp.com/__/auth/handler All other redundant Service IDs have been removed Sign In with Apple Key: Created with Key ID X8T9NLBT4Y Linked to the primary App ID .p8 file is available Firebase Apple provider: Tested with OAuth code flow fields populated (Services ID, Team ID, Key ID, Private Key) — same error Tested with OAuth code flow fields empty (recommended for iOS-only) — same error Client-side implementation: Proper nonce generation with SHA256 hashing OAuthProvider('apple.com').credential() with idToken and rawNonce Tested across 3 different builds (Build 12, 13, 14) Tested on multiple iOS devices (iOS 18+) What I've ruled out: Client-side code (tested 3 different implementations) Firebase configuration (tested both populated and empty) Multiple Service IDs (cleaned up to just one) App ID configuration (verified primary status) Context: During my Apple Developer Program enrollment, I experienced an error that was not fully resolved. I suspect this may have left my account in a state where Sign in with Apple is not fully activated on the Apple backend for my Team ID. Question: Has anyone encountered this where the Apple auth screen never appears at all? Is there a way to verify that Sign in with Apple is properly provisioned for a specific Team ID on Apple's backend? My App Store submission is blocked by this since Sign in with Apple is required when offering third-party authentication. Any guidance from Apple engineers or developers who solved a similar issue would be deeply appreciated. Thanks!

When i request 'https://appleid.apple.com/auth/keys' via my browser I do get 3 keys, But requesting from several cloud providers i get only a bogus reply: { "url": "https://appleid.apple.com/auth/keys" } Why is that? I'm using a very bare bones node request: fetch('https://appleid.apple.com/auth/keys');

Hello, I’m trying to remove the “Sign in with Apple” for my app via the iOS settings (also tried on a Mac, and on the web via account.apple.com). When I tap “Stop Using”, nothing happens, the dialog disappear but the app remains listed. Someone said on a forum that the issue is linked with the ServiceId that doesn't exist anymore. But how to recover it ? And anyway this behavior is unintended and creates a gap in the process. Has anyone experienced this before? Is there a known fix, or should I contact Apple Support directly for server-side revocation? Thank you!

We are experiencing an issue with Apple’s Private Email Relay service for Sign in with Apple users. Our setup details are as follows: • Domain: joinalyke.com • Domain successfully added under “Sign in with Apple for Email Communication” • SPF verified • DKIM enabled (2048-bit Easy DKIM via AWS SES) • Emails are being sent from S***@joinalyke.com Amazon SES confirms that emails sent to users’ @privaterelay.appleid.com addresses are successfully delivered (Delivery events recorded in SES and no bounce reported). However, users are not receiving the forwarded emails in their actual inboxes. Since: SES shows successful delivery, SPF and DKIM are properly configured, Domain is registered in the Apple Developer portal, we suspect that the Private Email Relay service may be blocking or not forwarding these emails. Could you please investigate whether: Our domain or IP reputation is being blocked or filtered, There are additional configuration requirements, The relay service is rejecting emails after acceptance, There are content-related filtering policies we should review. We are happy to provide message IDs, timestamps, and sample relay email addresses if required.

PLATFORM AND VERSION iOS Development environment: Xcode 26.2, macOS x Run-time configuration: iOS The issue does not seem to be limited to a specific version. DESCRIPTION OF PROBLEM We are reaching out to request in-depth technical assistance regarding an intermittent issue with Sign in with Apple implementation in our application. [Technical Status] We have confirmed that our technical implementation is correct. All necessary code and Xcode Capabilities are properly configured, and the service is working perfectly for the vast majority of our users. However, a small subset of users is consistently encountering "Unknown" Error (Error Code 1000), which prevents them from logging in entirely. [Identified Scenario] Currently, the only reproducible case we have found involves Child Accounts (protected accounts) under Family Sharing, specifically when the user's age is set below the regional requirement for a standalone Apple ID. However, we are receiving reports from other users who do not seem to fall into this category. [Requests for Clarification] To resolve this issue and support our users, we would like to obtain clear answers to the following questions: Root Cause: Why does Error 1000 occur specifically for a small number of users while the service works for most others? Other Scenarios: Are there any known cases or conditions other than the "Child Account" age restriction that trigger this specific error? Account-side Issues: If our code and configurations are verified to be correct, should we conclude that this is an issue specific to the individual's Apple ID/Account status? If so, could you provide a troubleshooting guide or official recommendation that we can share with these users to help them resolve their account-related issues? We are committed to providing a seamless authentication experience and would appreciate your expert insight into these edge cases. Thank you for your support. - (void) quickLogin:(uint)requestId withNonce:(NSString *)nonce andState:(NSString *)state { #if AUTHENTICATION_SERVICES_AVAILABLE if (@available(iOS 13.0, tvOS 13.0, macOS 10.15, *)) { ASAuthorizationAppleIDRequest *appleIDRequest = [[self appleIdProvider] createRequest]; [appleIDRequest setNonce:nonce]; [appleIDRequest setState:state]; ASAuthorizationPasswordRequest *keychainRequest = [[self passwordProvider] createRequest]; ASAuthorizationController *authorizationController = [[ASAuthorizationController alloc] initWithAuthorizationRequests:@[appleIDRequest, keychainRequest]]; [self performAuthorizationRequestsForController:authorizationController withRequestId:requestId]; } else { [self sendsLoginResponseInternalErrorWithCode:-100 andMessage:@"Native AppleAuth is only available from iOS 13.0" forRequestWithId:requestId]; } #else [self sendsLoginResponseInternalErrorWithCode:-100 andMessage:@"Native AppleAuth is only available from iOS 13.0" forRequestWithId:requestId]; #endif } - (void) loginWithAppleId:(uint)requestId withOptions:(AppleAuthManagerLoginOptions)options nonce:(NSString *)nonce andState:(NSString *)state { #if AUTHENTICATION_SERVICES_AVAILABLE if (@available(iOS 13.0, tvOS 13.0, macOS 10.15, *)) { ASAuthorizationAppleIDRequest *request = [[self appleIdProvider] createRequest]; NSMutableArray *scopes = [NSMutableArray array]; if (options & AppleAuthManagerIncludeName) [scopes addObject:ASAuthorizationScopeFullName]; if (options & AppleAuthManagerIncludeEmail) [scopes addObject:ASAuthorizationScopeEmail]; [request setRequestedScopes:[scopes copy]]; [request setNonce:nonce]; [request setState:state]; ASAuthorizationController *authorizationController = [[ASAuthorizationController alloc] initWithAuthorizationRequests:@[request]]; [self performAuthorizationRequestsForController:authorizationController withRequestId:requestId]; } else { [self sendsLoginResponseInternalErrorWithCode:-100 andMessage:@"Native AppleAuth is only available from iOS 13.0" forRequestWithId:requestId]; } #else [self sendsLoginResponseInternalErrorWithCode:-100 andMessage:@"Native AppleAuth is only available from iOS 13.0" forRequestWithId:requestId]; #endif } - (void) getCredentialStateForUser:(NSString *)userId withRequestId:(uint)requestId { #if AUTHENTICATION_SERVICES_AVAILABLE if (@available(iOS 13.0, tvOS 13.0, macOS 10.15, *)) { [[self appleIdProvider] getCredentialStateForUserID:userId completion:^(ASAuthorizationAppleIDProviderCredentialState credentialState, NSError * _Nullable error) { NSNumber *credentialStateNumber = nil; NSDictionary *errorDictionary = nil; if (error) errorDictionary = [AppleAuthSerializer dictionaryForNSError:error]; else credentialStateNumber = @(credentialState); NSDictionary *responseDictionary = [AppleAuthSerializer credentialResponseDictionaryForCredentialState:credentialStateNumber errorDictionary:errorDictionary]; [self sendNativeMessageForDictionary:responseDictionary forRequestId:requestId]; }]; } else { [self sendsCredentialStatusInternalErrorWithCode:-100 andMessage:@"Native AppleAuth is only available from iOS 13.0" forRequestWithId:requestId]; } #else [self sendsCredentialStatusInternalErrorWithCode:-100 andMessage:@"Native AppleAuth is only available from iOS 13.0" forRequestWithId:requestId]; #endif }