I regularly help developers with keychain problems, both here on DevForums and for my Day Job™ in DTS. Many of these problems are caused by a fundamental misunderstanding of how the keychain works. This post is my attempt to explain that. I wrote it primarily so that Future Quinn™ can direct folks here rather than explain everything from scratch (-: If you have questions or comments about any of this, put them in a new thread and apply the Security tag so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" SecItem: Fundamentals or How I Learned to Stop Worrying and Love the SecItem API The SecItem API seems very simple. After all, it only has four function calls, how hard can it be? In reality, things are not that easy. Various factors contribute to making this API much trickier than it might seem at first glance. This post explains the fundamental underpinnings of the keychain. For information about specific issues, see its companion post, SecItem: Pitfalls and Best Practices. Keychain Documentation Your basic starting point should be Keychain Items. If your code runs on the Mac, also read TN3137 On Mac keychain APIs and implementations. Read the doc comments in <Security/SecItem.h>. In many cases those doc comments contain critical tidbits. When you read keychain documentation [1] and doc comments, keep in mind that statements specific to iOS typically apply to iPadOS, tvOS, and watchOS as well (r. 102786959). Also, they typically apply to macOS when you target the data protection keychain. Conversely, statements specific to macOS may not apply when you target the data protection keychain. [1] Except TN3137, which is very clear about this (-: Caveat Mac Developer macOS supports two different keychain implementations: the original file-based keychain and the iOS-style data protection keychain. IMPORTANT If you’re able to use the data protection keychain, do so. It’ll make your life easier. See the Careful With that Shim, Mac Developer section of SecItem: Pitfalls and Best Practices for more about this. TN3137 On Mac keychain APIs and implementations explains this distinction. It also says: The file-based keychain is on the road to deprecation. This is talking about the implementation, not any specific API. The SecItem API can’t be deprecated because it works with both the data protection keychain and the file-based keychain. However, Apple has deprecated many APIs that are specific to the file-based keychain, for example, SecKeychainCreate. TN3137 also notes that some programs, like launchd daemons, can’t use the file-based keychain. If you’re working on such a program then you don’t have to worry about the deprecation of these file-based keychain APIs. You’re already stuck with the file-based keychain implementation, so using a deprecated file-based keychain API doesn’t make things worse. The Four Freedoms^H^H^H^H^H^H^H^H Functions The SecItem API contains just four functions: SecItemAdd(_:_:) SecItemCopyMatching(_:_:) SecItemUpdate(_:_:) SecItemDelete(_:) These directly map to standard SQL database operations: SecItemAdd(_:_:) maps to INSERT. SecItemCopyMatching(_:_:) maps to SELECT. SecItemUpdate(_:_:) maps to UPDATE. SecItemDelete(_:) maps to DELETE. You can think of each keychain item class (generic password, certificate, and so on) as a separate SQL table within the database. The rows of that table are the individual keychain items for that class and the columns are the attributes of those items. Note Except for the digital identity class, kSecClassIdentity, where the values are split across the certificate and key tables. See Digital Identities Aren’t Real in SecItem: Pitfalls and Best Practices. This is not an accident. The data protection keychain is actually implemented as an SQLite database. If you’re curious about its structure, examine it on the Mac by pointing your favourite SQLite inspection tool — for example, the sqlite3 command-line tool — at the keychain database in ~/Library/Keychains/UUU/keychain-2.db, where UUU is a UUID. WARNING Do not depend on the location and structure of this file. These have changed in the past and are likely to change again in the future. If you embed knowledge of them into a shipping product, it’s likely that your product will have binary compatibility problems at some point in the future. The only reason I’m mentioning them here is because I find it helpful to poke around in the file to get a better understanding of how the API works. For information about which attributes are supported by each keychain item class — that is, what columns are in each table — see the Note box at the top of Item Attribute Keys and Values. Alternatively, look at the Attribute Key Constants doc comment in <Security/SecItem.h>. Uniqueness A critical part of the keychain model is uniqueness. How does the keychain determine if item A is the same as item B? It turns out that this is class dependent. For each keychain item class there is a set of attributes that form the uniqueness constraint for items of that class. That is, if you try to add item A where all of its attributes are the same as item B, the add fails with errSecDuplicateItem. For more information, see the errSecDuplicateItem page. It has lists of attributes that make up this uniqueness constraint, one for each class. These uniqueness constraints are a major source of confusion, as discussed in the Queries and the Uniqueness Constraints section of SecItem: Pitfalls and Best Practices. Parameter Blocks Understanding The SecItem API is a classic ‘parameter block’ API. All of its inputs are dictionaries, and you have to know which properties to set in each dictionary to achieve your desired result. Likewise for when you read properties in output dictionaries. There are five different property groups: The item class property, kSecClass, determines the class of item you’re operating on: kSecClassGenericPassword, kSecClassCertificate, and so on. The item attribute properties, like kSecAttrAccessGroup, map directly to keychain item attributes. The search properties, like kSecMatchLimit, control how the system runs a query. The return type properties, like kSecReturnAttributes, determine what values the query returns. The value type properties, like kSecValueRef perform multiple duties, as explained below. There are other properties that perform a variety of specific functions. For example, kSecUseDataProtectionKeychain tells macOS to use the data protection keychain instead of the file-based keychain. These properties are hard to describe in general; for the details, see the documentation for each such property. Inputs Each of the four SecItem functions take dictionary input parameters of the same type, CFDictionary, but these dictionaries are not the same. Different dictionaries support different property groups: The first parameter of SecItemAdd(_:_:) is an add dictionary. It supports all property groups except the search properties. The first parameter of SecItemCopyMatching(_:_:) is a query and return dictionary. It supports all property groups. The first parameter of SecItemUpdate(_:_:) is a pure query dictionary. It supports all property groups except the return type properties. Likewise for the only parameter of SecItemDelete(_:). The second parameter of SecItemUpdate(_:_:) is an update dictionary. It supports the item attribute and value type property groups. Outputs Two of the SecItem functions, SecItemAdd(_:_:) and SecItemCopyMatching(_:_:), return values. These output parameters are of type CFTypeRef because the type of value you get back depends on the return type properties you supply in the input dictionary: If you supply a single return type property, except kSecReturnAttributes, you get back a value appropriate for that return type. If you supply multiple return type properties or kSecReturnAttributes, you get back a dictionary. This supports the item attribute and value type property groups. To get a non-attribute value from this dictionary, use the value type property that corresponds to its return type property. For example, if you set kSecReturnPersistentRef in the input dictionary, use kSecValuePersistentRef to get the persistent reference from the output dictionary. In the single item case, the type of value you get back depends on the return type property and the keychain item class: For kSecReturnData you get back the keychain item’s data. This makes most sense for password items, where the data holds the password. It also works for certificate items, where you get back the DER-encoded certificate. Using this for key items is kinda sketchy. If you want to export a key, called SecKeyCopyExternalRepresentation. Using this for digital identity items is nonsensical. For kSecReturnRef you get back an object reference. This only works for keychain item classes that have an object representation, namely certificates, keys, and digital identities. You get back a SecCertificate, a SecKey, or a SecIdentity, respectively. For kSecReturnPersistentRef you get back a data value that holds the persistent reference. Value Type Subtleties There are three properties in the value type property group: kSecValueData kSecValueRef kSecValuePersistentRef Their semantics vary based on the dictionary type. For kSecValueData: In an add dictionary, this is the value of the item to add. For example, when adding a generic password item (kSecClassGenericPassword), the value of this key is a Data value containing the password. This is not supported in a query dictionary. In an update dictionary, this is the new value for the item. For kSecValueRef: In add and query dictionaries, the system infers the class property and attribute properties from the supplied object. For example, if you supply a certificate object (SecCertificate, created using SecCertificateCreateWithData), the system will infer a kSecClass value of kSecClassCertificate and various attribute values, like kSecAttrSerialNumber, from that certificate object. This is not supported in an update dictionary. For kSecValuePersistentRef: For query dictionaries, this uniquely identifies the item to operate on. This is not supported in add and update dictionaries. Revision History 2025-05-28 Expanded the Caveat Mac Developer section to cover some subtleties associated with the deprecation of the file-based keychain. 2023-09-12 Fixed various bugs in the revision history. Added a paragraph explaining how to determine which attributes are supported by each keychain item class. 2023-02-22 Made minor editorial changes. 2023-01-28 First posted.

The Core Problem After Users sign out from the App, the app isn’t properly retrieving the user on second sign in. Instead, it’s treating the user as “Unknown” and saving a new entry in CloudKit and locally. Is there a tutorial aside from 'Juice' that is recent and up to date?

Hello Apple Developer Community and Support, Our team is encountering a critical and persistent issue with our backend integration of Sign In with Apple, and we are hoping for some insights or assistance. Problem: We consistently receive an "invalid_client" error (HTTP 400 status) when our backend service attempts to exchange the authorization code for tokens at Apple's https://appleid.apple.com/auth/token endpoint. The error message from Apple's response is simply {"error":"invalid_client"}. Our Setup: Client Application: An iOS native application. Backend Service: A Go backend responsible for server-to-server token exchange and user management. Sign In with Apple Flow: The iOS app initiates the Sign In with Apple flow, obtains an authorization code, and then passes this code to our backend for token exchange. Extensive Troubleshooting Performed (No Success): We have meticulously followed all official Apple documentation (including TN3107: Resolving Sign In with Apple Response Errors) and industry best practices. Here's a summary of our verification steps, all of which currently show correct configurations and parameters: Backend client_secret JWT Construction: We generate a client_secret JWT as required for server-to-server communication. We've confirmed the claims in the generated JWT are correct: iss (Issuer): Our Team ID (e.g., XXXXXXXXXX). sub (Subject): Our Service ID (e.g., com.example.service.backendauth). aud (Audience): https://appleid.apple.com. kid (Key ID): The Key ID associated with our .p8 private key (e.g., YYYYYYYYYY). We have performed rigorous verification of the .p8 private key content itself, ensuring no corruption, extra characters, or formatting issues in the environment variable. Our backend logs confirm it's parsing the correct PEM content. Token Exchange Request Parameters: The client_id parameter sent in the POST request to /auth/token is correctly set to our App Bundle ID (e.g., com.example.app.ios), as this is the identifier for which the code was originally issued. The redirect_uri parameter sent in the POST request to /auth/token is precisely matched to a registered "Return URL" in our Apple Developer Portal (e.g., https://api.example.com:port/api/auth/callback?provider=apple). Apple Developer Portal Configuration (Meticulously Verified): App ID: Enabled for "Sign In with Apple". Service ID: Enabled for "Sign In with Apple". Its "Primary App ID" is correctly linked to our App Bundle ID (e.g., com.example.app.ios). Its "Return URLs" exactly match our backend's redirect_uri (e.g., https://api.example.com:port/api/auth/callback?provider=apple). Key: Our .p8 key has "Sign In with Apple" enabled. Crucially, in its configuration panel, the "Primary App ID" is correctly linked to our App Bundle ID (e.g., com.example.app.ios). We've ensured this key is specifically created for "Sign In with Apple" and not other services like APNs. We have performed multiple full revocations and meticulous re-creations of the App ID, Service ID, and Key in the Apple Developer Portal, ensuring correct linkages and using new identifiers to bypass any potential caching issues. Network & System Health Checks: Network connectivity from our backend server to https://appleid.apple.com (port 443) has been confirmed as fully functional via ping and curl -v. The incoming TLS handshake from our iOS client app to our backend server's callback URL (https://api.example.com:port/...) is successful and verified via openssl s_client -connect. There are no longer any TLS handshake errors (EOF). Our backend server's system clock is accurately synchronized via NTP. Request for Assistance: Given that all our visible configurations, environment variables, and request parameters appear to be correct and align with Apple's documentation, and network connectivity is confirmed, we are at a loss for why the invalid_client error persists. Based on TN3107, this error typically implies an issue with the client secret's signature or its validity for the given client_id. However, our logs confirm correct iss, sub, aud, and kid, and the private key content. Has anyone encountered this persistent invalid_client error when all checks pass? Are there any less common configurations or troubleshooting steps we might be missing? Could this indicate a caching or propagation delay on Apple's servers, even after waiting periods? Any insights or guidance would be greatly appreciated. We are prepared to provide detailed, anonymized logs and screenshots to Apple Developer Support privately if requested. Thank you.

Hello. I want to do the following and need your help. I want to import a certificate (pkcs#12) into my macOS keychain with a setting that prohibits exporting the certificate. I want to import the certificate (pkcs#12) into my login keychain or system keychain. I was able to achieve [1] with the help of the following threads, but have the following problems. https://developer.apple.com/forums/thread/677314?answerId=824644022#824644022 how to import into login keychain or system keychain How to achieve this without using the deprecated API To import into the login keychain, I could use the “SecKeychainCopyDefault” function instead of the “SecKeychainCopySearchList” function, However, both of these functions were deprecated APIs. https://developer.apple.com/documentation/security/seckeychaincopysearchlist(_:) https://developer.apple.com/documentation/security/seckeychaincopydefault(_:) I checked the following URL and it seems that using the SecItem API is correct, but I could not figure out how to use it. https://developer.apple.com/documentation/technotes/tn3137-on-mac-keychains Is there any way to import them into the login keychain or system keychain without using these deprecated APIs?

Hi, I am developing a Platform SSO in order to have integrated with our IdP, which I am also adapting to provide the right endpoints for Platform SSO. I have a few questions about the implementation: does the client-request-id need to be present on all requests? Is it unique per request, or requests that are bound together like those requesting a nonce and those who will use that nonce should use the same client-request-id? I am not sure how the loginManager.presentRegistrationViewController works. I'd like to get the user to authenticate to my IdP before device registration. So I am not sure if I should provide my own Webview or something similar or if this method should do something for me; My idea is to request user authentication once, save the state when performing device registration, so that I avoid asking for user authentication twice when performing user registration. Is this the right way to do it? How does platform SSO handles tokens? If one application of my IdP requests the authentication on a common OIDC/OAuth2 flow, should I perform some sort of token exchange? How about SAML? Platform SSO seems to be token-centric, but how does one handle SAML flows? Is it by using WebView as well?

General: Forums topic: Privacy & Security Apple Platform Security support document Developer > Security Enabling enhanced security for your app documentation article Creating enhanced security helper extensions documentation article Security Audit Thoughts forums post Cryptography: Forums tags: Security, Apple CryptoKit Security framework documentation Apple CryptoKit framework documentation Common Crypto man pages — For the full list of pages, run: % man -k 3cc For more information about man pages, see Reading UNIX Manual Pages. On Cryptographic Key Formats forums post SecItem attributes for keys forums post CryptoCompatibility sample code Keychain: Forums tags: Security Security > Keychain Items documentation TN3137 On Mac keychain APIs and implementations SecItem Fundamentals forums post SecItem Pitfalls and Best Practices forums post Investigating hard-to-reproduce keychain problems forums post App ID Prefix Change and Keychain Access forums post Smart cards and other secure tokens: Forums tag: CryptoTokenKit CryptoTokenKit framework documentation Mac-specific resources: Forums tags: Security Foundation, Security Interface Security Foundation framework documentation Security Interface framework documentation BSD Privilege Escalation on macOS Related: Networking Resources — This covers high-level network security, including HTTPS and TLS. Network Extension Resources — This covers low-level network security, including VPN and content filters. Code Signing Resources Notarisation Resources Trusted Execution Resources — This includes Gatekeeper. App Sandbox Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

When presenting a cookie banner for GDPR purposes, should ATT precede the cookie banner? It seems that showing a Cookie Banner and then showing the ATT permission prompt afterwards (if a user elects to allow cookies/tracking) would be more appropriate. Related question: Should the “Allow Tracking” toggle for an app in system settings serve as a master switch for any granular tracking that might be managed by a 3rd party Consent Management Platform? If ATT is intended to serve as a master switch for tracking consent, if the ATT prompt is presented before a cookie banner, should the banner even appear if a user declines tracking consent? I’m not finding any good resources that describe this flow in detail and I’m seeing implementations all over the place on this. Help! Thanks!!!

The One-time codes documentation details how to enable autofill for SMS based codes. However, there is no details about how to correctly implement autofill for email based codes. I am observing the email based autofill works inconsistently when using email based OTC. In my application: There is latency of 10-15 seconds from when the email arrives to when it is available for autofill. After the autofill feature is used, the OTC email is not being deleted from the inbox automatically. Without documentation, it's unclear to me what I might be doing wrong that is causing these side effects. I found an ietf proposal for how autofill with email based codes might work, but it’s unclear if this is how Apple has implemented the feature: https://www.ietf.org/archive/id/draft-wells-origin-bound-one-time-codes-00.html#name-email Existing docs for Autofill using SMS: https://developer.apple.com/documentation/security/enabling-autofill-for-domain-bound-sms-codes

We’ve identified an issue in our app where, upon clicking the "Call Customer Center" button, users are unexpectedly shown a logo and message option on a native pop-up window. However, this wasn't the case before, and it should only display a phone number to dial, which was given inside our code. This is incorrect and misleading for our users, as: We are a Canadian-based service and have no affiliation with US messaging chat. The messaging feature was never enabled or intended for our app. Our app should only initiate a phone call to our customer support center — no messages or branding from third parties should appear

Using personal physical iPhone for simulations. Can't get Keychain to read or store AppleID name/email. I want to avoid hard reseting physical phone. Logs confirm Keychain is working, but userIdentifier and savedEmail are not being stored correctly. 🔄 Initializing UserManager... ✅ Saved testKeychain to Keychain: Test Value ✅ Retrieved testKeychain from Keychain: Test Value 🔍 Keychain Test - Retrieved Value: Test Value ⚠️ Keychain Retrieve Warning: No stored value found for userIdentifier ⚠️ Keychain Retrieve Warning: No stored value found for savedEmail 🔍 Debug - Retrieved from Keychain: userIdentifier=nil, savedEmail=nil ⚠️ No stored userIdentifier in Keychain. User needs to sign in. 📦 Converting User to CKRecord: Unknown, No Email ✅ User saved locally: Unknown, No Email ✅ User saved to CloudKit: Unknown, No Email Below UserManager.swift if someone can help troubleshoot. Or step by step tutorial to configure a project and build a User Login &amp; User Account creation for Apple Only app. import Foundation import CloudKit import AuthenticationServices import SwiftData @MainActor class UserManager: ObservableObject { @Published var user: User? @Published var isLoggedIn = false @Published var errorMessage: String? private let database = CKContainer.default().publicCloudDatabase init() { print("🔄 Initializing UserManager...") // 🔍 Keychain Debug Test let testKey = "testKeychain" KeychainHelper.shared.save("Test Value", forKey: testKey) let retrievedValue = KeychainHelper.shared.retrieve(forKey: testKey) print("🔍 Keychain Test - Retrieved Value: \(retrievedValue ?? "nil")") fetchUser() // Continue normal initialization } // ✅ Sign in &amp; Save User func handleSignIn(_ authResults: ASAuthorization) { guard let appleIDCredential = authResults.credential as? ASAuthorizationAppleIDCredential else { errorMessage = "Error retrieving Apple credentials" print("❌ ASAuthorization Error: Invalid credentials received") return } let userIdentifier = appleIDCredential.user let fullName = appleIDCredential.fullName?.givenName ?? retrieveSavedName() var email = appleIDCredential.email ?? retrieveSavedEmail() print("🔍 Apple Sign-In Data: userIdentifier=\(userIdentifier), fullName=\(fullName), email=\(email)") // 🔄 If Apple doesn't return an email, check if it exists in Keychain if appleIDCredential.email == nil { print("⚠️ Apple Sign-In didn't return an email. Retrieving saved email from Keychain.") } // ✅ Store userIdentifier &amp; email in Keychain KeychainHelper.shared.save(userIdentifier, forKey: "userIdentifier") KeychainHelper.shared.save(email, forKey: "savedEmail") let newUser = User(fullName: fullName, email: email, userIdentifier: userIdentifier) saveUserToCloudKit(newUser) } func saveUserToCloudKit(_ user: User) { let record = user.toRecord() Task { do { try await database.save(record) DispatchQueue.main.async { self.user = user self.isLoggedIn = true self.saveUserLocally(user) print("✅ User saved to CloudKit: \(user.fullName), \(user.email)") } } catch { DispatchQueue.main.async { self.errorMessage = "Error saving user: \(error.localizedDescription)" print("❌ CloudKit Save Error: \(error.localizedDescription)") } } } } // ✅ Fetch User from CloudKit func fetchUser() { let userIdentifier = KeychainHelper.shared.retrieve(forKey: "userIdentifier") let savedEmail = KeychainHelper.shared.retrieve(forKey: "savedEmail") print("🔍 Debug - Retrieved from Keychain: userIdentifier=\(userIdentifier ?? "nil"), savedEmail=\(savedEmail ?? "nil")") guard let userIdentifier = userIdentifier else { print("⚠️ No stored userIdentifier in Keychain. User needs to sign in.") return } let predicate = NSPredicate(format: "userIdentifier == %@", userIdentifier) let query = CKQuery(recordType: "User", predicate: predicate) Task { [weak self] in guard let self = self else { return } do { let results = try await self.database.records(matching: query, resultsLimit: 1).matchResults if let (_, result) = results.first { switch result { case .success(let record): DispatchQueue.main.async { let fetchedUser = User(record: record) self.user = User( fullName: fetchedUser.fullName, email: savedEmail ?? fetchedUser.email, userIdentifier: userIdentifier ) self.isLoggedIn = true self.saveUserLocally(self.user!) print("✅ User loaded from CloudKit: \(fetchedUser.fullName), \(fetchedUser.email)") } case .failure(let error): DispatchQueue.main.async { print("❌ Error fetching user from CloudKit: \(error.localizedDescription)") } } } } catch { DispatchQueue.main.async { print("❌ CloudKit fetch error: \(error.localizedDescription)") } } } } // ✅ Save User Locally private func saveUserLocally(_ user: User) { if let encoded = try? JSONEncoder().encode(user) { UserDefaults.standard.set(encoded, forKey: "savedUser") UserDefaults.standard.set(user.fullName, forKey: "savedFullName") UserDefaults.standard.set(user.email, forKey: "savedEmail") print("✅ User saved locally: \(user.fullName), \(user.email)") } else { print("❌ Local Save Error: Failed to encode user data") } } // ✅ Retrieve Previously Saved Name private func retrieveSavedName() -&gt; String { return UserDefaults.standard.string(forKey: "savedFullName") ?? "Unknown" } // ✅ Retrieve Previously Saved Email private func retrieveSavedEmail() -&gt; String { return KeychainHelper.shared.retrieve(forKey: "savedEmail") ?? UserDefaults.standard.string(forKey: "savedEmail") ?? "No Email" } // ✅ Sign Out func signOut() { isLoggedIn = false user = nil UserDefaults.standard.removeObject(forKey: "savedUser") print("🚪 Signed Out") } }

I would like to make an app that uses Sign in with Apple to provide the users with a very convenient way of authenticating their (anonymous) identity. I'm using the identityToken that the SignInWithAppleButton provides to the onCompletion closure to build an AWS Identity Resolver that will be used to access AWS resources for that user. At the moment, everything works fine, except that the identityToken eventually stops working (I think after 24 hours) and is no longer usable for AWS identity resolvers. Is there a way to refresh the identityToken, or to generate a new one, without user interaction? I don't mind at all, if in some situations (eg logout from another device, deletion of account, etc), it cannot refresh the token, and it directs me to take further action by giving an error. Most importantly, I don't want the user to be forced to deal with the SignInWithAppleButton every time that they interact with web services. From the user's point of view, I would like the experience to be that they simply confirm that they agree to use SignInWithApple on first use (maybe once per device), and are never inconvenienced by it again. P.S. Sorry for posting this here. I tried to set the topic to "Privacy & Security" and ran into form validation errors.

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 received Apple’s recent notice about the new requirement to provide a server-to-server notification endpoint when registering or updating a Services ID that uses Sign in with Apple. (Official notice: https://developer.apple.com/news/?id=j9zukcr6 ) We already use Sign in with Apple on our website and app, but only as a login method for pre-registered users, not as a way to create new accounts. That means users already exist in our system, and Apple login is used only for authentication convenience (similar to linking a social account). I have some questions about how to properly implement the required server-to-server notifications in this case: 1. email-enabled / email-disabled: We don’t use or store the email address provided by Apple. Are we still required to handle these events, or can we safely ignore them if the email is not used in our system? 2. consent-revoked: We don’t store Apple access or refresh tokens, we use them only during login and discard them immediately. In this case, do we still need to handle token revocation, or can we simply unlink the Apple login from the user account when receiving this notification? 3. account-delete: If a user deletes their Apple account, we can unlink the Apple login and remove related Apple data, but we cannot delete the user’s primary account in our system (since the account exists independently). Is this acceptable under Apple’s requirements as well? We want to make sure our implementation aligns with Apple’s policy and privacy requirements, while maintaining consistency with our existing account management system. If anyone from Apple or other developers who implemented similar logic could provide guidance or share examples, it would be greatly appreciated. Thank you!

I have an Autofill Passkey Provider working for Safari and Chrome via WebAuthn protocol. Unfortunately, Chrome will not offer my extension as a logon credential provider unless I add the credential to the ASCredentialIdentityStore. I wonder what is the best way to access the ASCredentialIdentityStore from an AutoFill extension? I understand I cannot access it directly from the extension context, so what is the best way to trigger my container app to run, based on a new WebAuthn registration? The best I can think of so far is for the www site to provide an App Link to launch my container app as part of the registration ceremony. Safari will offer my extension even without adding it to the ASCredentialIdentityStore, so I guess I should file a request with Chrome to work this way too, given difficulty of syncing ASCredentialIdentityStore with WebAuthn registration.

Hi Community, We've implemented Sign In with Apple in our application. Our domains are properly registered in the developer console, but we're experiencing inconsistent email functionality with Apple's privacy email service. Some domains work correctly while others show delivery problems, even though all domains have identical configurations. Apple's console displays green verification status for all domains, yet testing reveals that emails to privacy-protected accounts don't arrive as expected. We're using SendGrid as our email service provider, and all domains have valid authentication records (SPF, DKIM, DMARC) in place. Has anyone encountered similar inconsistencies with Apple's privacy email service? Would appreciate any configuration tips or troubleshooting guidance. Thanks.

I'm trying to setup device attestation. I believe I have everything setup correctly but the final step of signature validation never succeeds. I've added validation on the client side for debugging and it doesn't validate using CryptoKit. After the assertion is created, I try to validate it: assertion = try await DCAppAttestService.shared.generateAssertion(keyId, clientDataHash: clientDataHash) await validateAssertionLocallyForDebugging(keyId: keyId, assertionObject: assertion, clientDataHash: clientDataHash) In the validateAssertionLocallyForDebugging method, I extract all the data from the CBOR assertionObject and then setup the parameters to validate the signature, using the key that was created from the original attestation flow, but it fails every time. I'm getting the public key from the server using a temporary debugging API. let publicKeyData = Data(base64Encoded: publicKeyB64)! let p256PublicKey = try P256.Signing.PublicKey(derRepresentation: publicKeyData) let ecdsaSignature = try P256.Signing.ECDSASignature(derRepresentation: signature) let digestToVerify = SHA256.hash(data: authenticatorData + clientDataHash) print(" - Recreated Digest to Verify: \(Data(digestToVerify).hexDescription)") if p256PublicKey.isValidSignature(ecdsaSignature, for: digestToVerify) { print("[DEBUG] SUCCESS: Local signature validation passed!") } else { print("[DEBUG] FAILED: Local signature validation failed.") } I have checked my .entitlements file and it is set to development. I have checked the keyId and verified the public key. I have verified the public key X,Y, the RP ID Hash, COSE data, and pretty much anything else I could think of. I've also tried using Gemini and Claude to debug this and that just sends me in circles of trying hashed, unhashed, and double hashed clientData. I'm doing this from Xcode on an M3 macbook air to an iPhone 16 Pro Max. Do you have any ideas on why the signature is not validating with everything else appears to be working? Thanks

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);

Hello, I currently have an app that includes the "Sign in with Apple" feature, and I need to transfer this app to another app team. I have reviewed all official documentation but have not found the answer I need. My situation has some specificities, and I hope to receive assistance. The .p8 key created by the original developer team has been lost, and the app’s backend does not use a .p8 key for verification—instead, it verifies by obtaining Apple’s public key. However, according to the official documentation I reviewed, obtaining a transfer identifier during the app transfer process requires a client_secret generated from the original team’s .p8 key. This has left us facing a challenge, and we have two potential approaches to address this issue: Q1: During the transfer, is it possible to skip obtaining the transfer identifier and proceed directly with the app transfer, without performing any backend operations? Is this approach feasible? Q2: If the above approach is not feasible, should we create a new .p8 key in the original team’s account and use this new key for the transfer? If a new key is generated, do we need to re-release a new version of the app before initiating the transfer? If neither of the above approaches is feasible, are there better solutions to resolve our issue? I hope to receive a response. Thank you. TN3159: Migrating Sign in with Apple users for an app transfer | Apple Developer Documentation/ https://developer.apple.com/documentation/signinwithapple/transferring-your-apps-and-users-to-another-team

override func prepareInterface(forPasskeyRegistration registrationRequest: any ASCredentialRequest) int this function how can i get the "challenge" from user agent, the params "challenge" need to be used in webauthn navigator.credentials.create

I'm experiencing an issue with Sign In with Apple integration in my React Native Expo app (Bundle ID: com.anonymous.TuZjemyApp). Problem Description: When users attempt to sign in using Sign In with Apple, they successfully complete Face ID/password authentication, but then receive a "Sign-Up not completed" error message. The authentication flow appears to stop at this point and doesn't return the identity token to my app. Technical Details: Frontend Implementation: Using expo-apple-authentication. Requesting scopes: FULL_NAME and EMAIL App is properly configured in app.json with: usesAppleSignIn: true Entitlement: com.apple.developer.applesignin Backend Implementation: Endpoint: POST /api/auth/apple Using apple-signin-auth package for token verification Verifying tokens with audience: com.anonymous.TuZjemyApp Backend creates/updates user accounts based on Apple ID Question: I'm not sure why the authentication flow stops with "Sign-Up not completed" after successful Face ID verification. The identity token never reaches my app. Could you please help me understand: What might cause this specific error message? Are there any additional Apple Developer Portal configurations required? Could this be related to app capabilities or entitlements? Is there a specific setup needed for the app to properly receive identity tokens? I set up provisioning profiles, and added Sign in with Apple as a capability and still it doesn't work.