Dear Apple Support Team, I hope this message finds you well. Our tech team is currently working on integrating the Apple Sign-In feature, and we have a specific query where we would appreciate your guidance. Background Context: We have several applications across different brands and are aiming to implement a unified sign-up and sign-in experience. Currently, we are utilizing a shared website to enable single sign-in functionality across all these applications. Our Query: If we embed the same website in all of these applications and implement the Apple Sign-In within this website—using a dedicated Service ID that is configured with the App Store name and icon—will users consistently see the Apple Sign-In pop-up with the Service ID’s name and icon, regardless of which base application (e.g., App A, App B, etc.) the website is accessed from? We would like to ensure a seamless and consistent user experience and want to confirm that the branding within the Apple Sign-In prompt will reflect the Service ID’s configuration, rather than that of the hosting app. Looking forward to your guidance on this matter.

Hi. We are trying to get the access token before calling any API. The app can go in bad network areas but the token acquisition keeps happening for the network call. The devices are managed devices which means it has some policies installed. We are using MSAL lib for the authentication and we are investigating from that angle too but the below error seems to be coming from apple authentication which needs our attention. ========================================== LaunchServices: store (null) or url (null) was nil: Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={NSDebugDescription=process may not map database, _LSLine=68, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler} Attempt to map database failed: permission was denied. This attempt will not be retried. Failed to initialize client context with error Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={NSDebugDescription=process may not map database, _LSLine=68, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler} Failed to get application extension record: Error Domain=NSOSStatusErrorDomain Code=-54 "(null)" ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1003 "(null)" ========================================== This happens mostly when we switches the network or keep the device in no or low network area. This comes sometimes when app goes in background too. Just trying to give as much as information I could. Any lead would be highly appreciated. Thank you

I regularly help developers with keychain problems, both here on DevForums and for my Day Job™ in DTS. Over the years I’ve learnt a lot about the API, including many pitfalls and best practices. This post is my attempt to collect that experience in one place. 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: Pitfalls and Best Practices It’s just four functions, how hard can it be? 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 some of the keychain’s pitfalls and then goes on to explain various best practices. Before reading this, make sure you understand the fundamentals by reading its companion post, SecItem: Fundamentals. Pitfalls Lets start with some common pitfalls. Queries and Uniqueness Constraints The relationship between query dictionaries and uniqueness constraints is a major source of problems with the keychain API. Consider code like this: var copyResult: CFTypeRef? = nil let query = [ kSecClass: kSecClassGenericPassword, kSecAttrService: "AYS", kSecAttrAccount: "mrgumby", kSecAttrGeneric: Data("SecItemHints".utf8), ] as NSMutableDictionary let err = SecItemCopyMatching(query, &copyResult) if err == errSecItemNotFound { query[kSecValueData] = Data("opendoor".utf8) let err2 = SecItemAdd(query, nil) if err2 == errSecDuplicateItem { fatalError("… can you get here? …") } } Can you get to the fatal error? At first glance this might not seem possible because you’ve run your query and it’s returned errSecItemNotFound. However, the fatal error is possible because the query contains an attribute, kSecAttrGeneric, that does not contribute to the uniqueness. If the keychain contains a generic password whose service (kSecAttrService) and account (kSecAttrAccount) attributes match those supplied but whose generic (kSecAttrGeneric) attribute does not, the SecItemCopyMatching calls will return errSecItemNotFound. However, for a generic password item, of the attributes shown here, only the service and account attributes are included in the uniqueness constraint. If you try to add an item where those attributes match an existing item, the add will fail with errSecDuplicateItem even though the value of the generic attribute is different. The take-home point is that that you should study the attributes that contribute to uniqueness and use them in a way that’s aligned with your view of uniqueness. See the Uniqueness section of SecItem: Fundamentals for a link to the relevant documentation. Erroneous Attributes Each keychain item class supports its own specific set of attributes. For information about the attributes supported by a given class, see SecItem: Fundamentals. I regularly see folks use attributes that aren’t supported by the class they’re working with. For example, the kSecAttrApplicationTag attribute is only supported for key items (kSecClassKey). Using it with a certificate item (kSecClassCertificate) will cause, at best, a runtime error and, at worst, mysterious bugs. This is an easy mistake to make because: The ‘parameter block’ nature of the SecItem API means that the compiler won’t complain if you use an erroneous attribute. On macOS, the shim that connects to the file-based keychain ignores unsupported attributes. Imagine you want to store a certificate for a particular user. You might write code like this: let err = SecItemAdd([ kSecClass: kSecClassCertificate, kSecAttrApplicationTag: Data(name.utf8), kSecValueRef: cert, ] as NSDictionary, nil) The goal is to store the user’s name in the kSecAttrApplicationTag attribute so that you can get back their certificate with code like this: let err = SecItemCopyMatching([ kSecClass: kSecClassCertificate, kSecAttrApplicationTag: Data(name.utf8), kSecReturnRef: true, ] as NSDictionary, &copyResult) On iOS, and with the data protection keychain on macOS, both calls will fail with errSecNoSuchAttr. That makes sense, because the kSecAttrApplicationTag attribute is not supported for certificate items. Unfortunately, the macOS shim that connects the SecItem API to the file-based keychain ignores extraneous attributes. This results in some very bad behaviour: SecItemAdd works, ignoring kSecAttrApplicationTag. SecItemCopyMatching ignores kSecAttrApplicationTag, returning the first certificate that it finds. If you only test with a single user, everything seems to work. But, later on, when you try your code with multiple users, you might get back the wrong result depending on the which certificate the SecItemCopyMatching call happens to discover first. Ouch! Context Matters Some properties change behaviour based on the context. The value type properties are the biggest offender here, as discussed in the Value Type Subtleties section of SecItem: Fundamentals. However, there are others. The one that’s bitten me is kSecMatchLimit: In a query and return dictionary its default value is kSecMatchLimitOne. If you don’t supply a value for kSecMatchLimit, SecItemCopyMatching returns at most one item that matches your query. In a pure query dictionary its default value is kSecMatchLimitAll. For example, if you don’t supply a value for kSecMatchLimit, SecItemDelete will delete all items that match your query. This is a lesson that, once learnt, is never forgotten! Note Although this only applies to the data protection keychain. If you’re on macOS and targeting the file-based keychain, kSecMatchLimit always defaults to kSecMatchLimitOne (r. 105800863). Fun times! Digital Identities Aren’t Real A digital identity is the combination of a certificate and the private key that matches the public key within that certificate. The SecItem API has a digital identity keychain item class, namely kSecClassIdentity. However, the keychain does not store digital identities. When you add a digital identity to the keychain, the system stores its components, the certificate and the private key, separately, using kSecClassCertificate and kSecClassKey respectively. This has a number of non-obvious effects: Adding a certificate can ‘add’ a digital identity. If the new certificate happens to match a private key that’s already in the keychain, the keychain treats that pair as a digital identity. Likewise when you add a private key. Similarly, removing a certificate or private key can ‘remove’ a digital identity. Adding a digital identity will either add a private key, or a certificate, or both, depending on what’s already in the keychain. Removing a digital identity removes its certificate. It might also remove the private key, depending on whether that private key is used by a different digital identity. The system forms a digital identity by matching the kSecAttrApplicationLabel (klbl) attribute of the private key with the kSecAttrPublicKeyHash (pkhh) attribute of the certificate. If you add both items to the keychain and the system doesn’t form an identity, check the value of these attributes. For more information the key attributes, see SecItem attributes for keys. Keys Aren’t Stored in the Secure Enclave Apple platforms let you protect a key with the Secure Enclave (SE). The key is then hardware bound. It can only be used by that specific SE [1]. Earlier versions of the Protecting keys with the Secure Enclave article implied that SE-protected keys were stored in the SE itself. This is not true, and it’s caused a lot of confusion. For example, I once asked the keychain team “How much space does the SE have available to store keys?”, a question that’s complete nonsense once you understand how this works. In reality, SE-protected keys are stored in the standard keychain database alongside all your other keychain items. The difference is that the key is wrapped in such a way that only the SE can use it. So, the key is protected by the SE, not stored in the SE. A while back we updated the docs to clarify this point but the confusion persists. [1] Technically it’s that specific iteration of that specific SE. If you erase the device then the key material needed to use the key is erased and so the key becomes permanently useless. This is the sort of thing you’ll find explained in Apple Platform Security. Careful With that Shim, Mac Developer As explained in TN3137 On Mac keychain APIs and implementations, macOS has a shim that connects the SecItem API to either the data protection keychain or the file-based keychain depending on the nature of the request. That shim has limitations. Some of those are architectural but others are simply bugs in the shim. For some great examples, see the Investigating Complex Attributes section below. The best way to avoid problems like this is to target the data protection keychain. If you can’t do that, try to avoid exploring the outer reaches of the SecItem API. If you encounter a case that doesn’t make sense, try that same case with the data protection keychain. If it works there but fails with the file-based keychain, please do file a bug against the shim. It’ll be in good company. Here’s some known issues with the shim: It ignores unsupported attributes. See Erroneous Attributes, above, for more background on that. The shim can fan out to both the data protection and the file-based keychain. In that case it has to make a policy decision about how to handle errors. This results in some unexpected behaviour (r. 143405965). For example, if you call SecItemCopyMatching while the keychain is locked, the data protection keychain will fail with errSecInteractionNotAllowed (-25308). OTOH, it’s possible to query for the presence of items in the file-based keychain even when it’s locked. If you do that and there’s no matching item, the file-based keychain fails with errSecItemNotFound (-25300). When the shim gets these conflicting errors, it chooses to return the latter. Whether this is right or wrong depends on your perspective, but it’s certainly confusing, especially if you’re coming at this from the iOS side. If you call SecItemDelete without specifying a match limit (kSecMatchLimit), the data protection keychain deletes all matching items, whereas the file-based keychain just deletes a single match (r. 105800863). While these issue have all have bug numbers, there’s no guarantee that any of them will be fixed. Fixing bugs like this is tricky because of binary compatibility concerns. Add-only Attributes Some attributes can only be set when you add an item. These attributes are usually associated with the scope of the item. For example, to protect an item with the Secure Enclave, supply the kSecAttrAccessControl attribute to the SecItemAdd call. Once you do that, however, you can’t change the attribute. Calling SecItemUpdate with a new kSecAttrAccessControl won’t work. Lost Keychain Items A common complaint from developers is that a seemingly minor update to their app has caused it to lose all of its keychain items. Usually this is caused by one of two problems: Entitlement changes Query dictionary confusion Access to keychain items is mediated by various entitlements, as described in Sharing access to keychain items among a collection of apps. If the two versions of your app have different entitlements, one version may not be able to ‘see’ items created by the other. Imagine you have an app with an App ID of SKMME9E2Y8.com.example.waffle-varnisher. Version 1 of your app is signed with the keychain-access-groups entitlement set to [ SKMME9E2Y8.groupA, SKMME9E2Y8.groupB ]. That makes its keychain access group list [ SKMME9E2Y8.groupA, SKMME9E2Y8.groupB, SKMME9E2Y8.com.example.waffle-varnisher ]. If this app creates a new keychain item without specifying kSecAttrAccessGroup, the system places the item into SKMME9E2Y8.groupA. If version 2 of your app removes SKMME9E2Y8.groupA from the keychain-access-groups, it’ll no longer be able to see the keychain items created by version 1. You’ll also see this problem if you change your App ID prefix, as described in App ID Prefix Change and Keychain Access. IMPORTANT When checking for this problem, don’t rely on your .entitlements file. There are many steps between it and your app’s actual entitlements. Rather, run codesign to dump the entitlements of your built app: % codesign -d --entitlements - /path/to/your.app Lost Keychain Items, Redux Another common cause of lost keychain items is confusion about query dictionaries, something discussed in detail in this post and SecItem: Fundamentals. If SecItemCopyMatching isn’t returning the expected item, add some test code to get all the items and their attributes. For example, to dump all the generic password items, run code like this: func dumpGenericPasswords() throws { let itemDicts = try secCall { SecItemCopyMatching([ kSecClass: kSecClassGenericPassword, kSecMatchLimit: kSecMatchLimitAll, kSecReturnAttributes: true, ] as NSDictionary, $0) } as! [[String: Any]] print(itemDicts) } Then compare each item’s attributes against the attributes you’re looking for to see why there was no match. Data Protection and Background Execution Keychain items are subject to data protection. Specifically, an item may or may not be accessible depending on whether specific key material is available. For an in-depth discussion of how this works, see Apple Platform Security. Note This section focuses on iOS but you’ll see similar effects on all Apple platforms. On macOS specifically, the contents of this section only apply to the data protection keychain. The keychain supports three data protection levels: kSecAttrAccessibleWhenUnlocked kSecAttrAccessibleAfterFirstUnlock kSecAttrAccessibleAlways Note There are additional data protection levels, all with the ThisDeviceOnly suffix. Understanding those is not necessary to understanding this pitfall. Each data protection level describes the lifetime of the key material needed to work with items protected in that way. Specifically: The key material needed to work with a kSecAttrAccessibleWhenUnlocked item comes and goes as the user locks and unlocks their device. The key material needed to work with a kSecAttrAccessibleAfterFirstUnlock item becomes available when the device is first unlocked and remains available until the device restarts. The default data protection level is kSecAttrAccessibleWhenUnlocked. If you add an item to the keychain and don’t specify a data protection level, this is what you get [1]. To specify a data protection level when you add an item to the keychain, apply the kSecAttrAccessible attribute. Alternatively, embed the access level within a SecAccessControl object and apply that using the kSecAttrAccessControl attribute. IMPORTANT It’s best practice to set these attributes when you add the item and then never update them. See Add-only Attributes, above, for more on that. If you perform an operation whose data protection is incompatible with the currently available key material, that operation fails with errSecInteractionNotAllowed [2]. There are four fundamental keychain operations, discussed in the SecItem: Fundamentals, and each interacts with data protection in a different way: Copy — If you attempt to access a keychain item whose key material is unavailable, SecItemCopyMatching fails with errSecInteractionNotAllowed. This is an obvious result; the whole point of data protection is to enforce this security policy. Add — If you attempt to add a keychain item whose key material is unavailable, SecItemAdd fails with errSecInteractionNotAllowed. This is less obvious. The reason why this fails is that the system needs the key material to protect (by encryption) the keychain item, and it can’t do that if if that key material isn’t available. Update — If you attempt to update a keychain item whose key material is unavailable, SecItemUpdate fails with errSecInteractionNotAllowed. This result is an obvious consequence of the previous result. Delete — Deleting a keychain item, using SecItemDelete, doesn’t require its key material, and thus a delete will succeed when the item is otherwise unavailable. That last point is a significant pitfall. I regularly see keychain code like this: Read an item holding a critical user credential. If that works, use that credential. If it fails, delete the item and start from a ‘factory reset’ state. The problem is that, if your code ends up running in the background unexpectedly, step 1 fails with errSecInteractionNotAllowed and you turn around and delete the user’s credential. Ouch! Note Even if you didn’t write this code, you might have inherited it from a keychain wrapper library. See *Think Before Wrapping, below. There are two paths forward here: If you don’t expect this code to work in the background, check for the errSecInteractionNotAllowed error and non-destructively cancel the operation in that case. If you expect this code to be running in the background, switch to a different data protection level. WARNING For the second path, the most obvious fix is to move from kSecAttrAccessibleWhenUnlocked to kSecAttrAccessibleAfterFirstUnlock. However, this is not a panacea. It’s possible that your app might end up running before first unlock [3]. So, if you choose the second path, you must also make sure to follow the advice for the first path. You can determine whether the device is unlocked using the isProtectedDataAvailable property and its associated notifications. However, it’s best not to use this property as part of your core code, because such preflighting is fundamentally racy. Rather, perform the operation and handle the error gracefully. It might make sense to use isProtectedDataAvailable property as part of debugging, logging, and diagnostic code. [1] For file data protection there’s an entitlement (com.apple.developer.default-data-protection) that controls the default data protection level. There’s no such entitlement for the keychain. That’s actually a good thing! In my experience the file data protection entitlement is an ongoing source of grief. See this thread if you’re curious. [2] This might seem like an odd error but it’s actually pretty reasonable: The operation needs some key material that’s currently unavailable. Only a user action can provide that key material. But the data protection keychain will never prompt the user to unlock their device. Thus you get an error instead. [3] iOS generally avoids running third-party code before first unlock, but there are circumstances where that can happen. The obvious legitimate example of this is a VoIP app, where the user expects their phone to ring even if they haven’t unlocked it since the last restart. There are also other less legitimate examples of this, including historical bugs that caused apps to launch in the background before first unlock. Best Practices With the pitfalls out of the way, let’s talk about best practices. Less Painful Dictionaries I look at a lot of keychain code and it’s amazing how much of it is way more painful than it needs to be. The biggest offender here is the dictionaries. Here are two tips to minimise the pain. First, don’t use CFDictionary. It’s seriously ugly. While the SecItem API is defined in terms of CFDictionary, you don’t have to work with CFDictionary directly. Rather, use NSDictionary and take advantage of the toll-free bridge. For example, consider this CFDictionary code: CFTypeRef keys[4] = { kSecClass, kSecAttrService, kSecMatchLimit, kSecReturnAttributes, }; static const int kTen = 10; CFNumberRef ten = CFNumberCreate(NULL, kCFNumberIntType, &kTen); CFAutorelease(ten); CFTypeRef values[4] = { kSecClassGenericPassword, CFSTR("AYS"), ten, kCFBooleanTrue, }; CFDictionaryRef query = CFDictionaryCreate( NULL, keys, values, 4, &kCFTypeDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks ); Note This might seem rather extreme but I’ve literally seen code like this, and worse, while helping developers. Contrast this to the equivalent NSDictionary code: NSDictionary * query = @{ (__bridge NSString *) kSecClass: (__bridge NSString *) kSecClassGenericPassword, (__bridge NSString *) kSecAttrService: @"AYS", (__bridge NSString *) kSecMatchLimit: @10, (__bridge NSString *) kSecReturnAttributes: @YES, }; Wow, that’s so much better. Second, if you’re working in Swift, take advantage of its awesome ability to create NSDictionary values from Swift dictionary literals. Here’s the equivalent code in Swift: let query = [ kSecClass: kSecClassGenericPassword, kSecAttrService: "AYS", kSecMatchLimit: 10, kSecReturnAttributes: true, ] as NSDictionary Nice! Avoid Reusing Dictionaries I regularly see folks reuse dictionaries for different SecItem calls. For example, they might have code like this: var copyResult: CFTypeRef? = nil let dict = [ kSecClass: kSecClassGenericPassword, kSecAttrService: "AYS", kSecAttrAccount: "mrgumby", kSecReturnData: true, ] as NSMutableDictionary var err = SecItemCopyMatching(dict, &copyResult) if err == errSecItemNotFound { dict[kSecValueData] = Data("opendoor".utf8) err = SecItemAdd(dict, nil) } This specific example will work, but it’s easy to spot the logic error. kSecReturnData is a return type property and it makes no sense to pass it to a SecItemAdd call whose second parameter is nil. I’m not sure why folks do this. I think it’s because they think that constructing dictionaries is expensive. Regardless, this pattern can lead to all sorts of weird problems. For example, it’s the leading cause of the issue described in the Queries and the Uniqueness Constraints section, above. My advice is that you use a new dictionary for each call. That prevents state from one call accidentally leaking into a subsequent call. For example, I’d rewrite the above as: var copyResult: CFTypeRef? = nil let query = [ kSecClass: kSecClassGenericPassword, kSecAttrService: "AYS", kSecAttrAccount: "mrgumby", kSecReturnData: true, ] as NSMutableDictionary var err = SecItemCopyMatching(query, &copyResult) if err == errSecItemNotFound { let add = [ kSecClass: kSecClassGenericPassword, kSecAttrService: "AYS", kSecAttrAccount: "mrgumby", kSecValueData: Data("opendoor".utf8), ] as NSMutableDictionary err = SecItemAdd(add, nil) } It’s a bit longer, but it’s much easier to track the flow. And if you want to eliminate the repetition, use a helper function: func makeDict() -> NSMutableDictionary { [ kSecClass: kSecClassGenericPassword, kSecAttrService: "AYS", kSecAttrAccount: "mrgumby", ] as NSMutableDictionary } var copyResult: CFTypeRef? = nil let query = makeDict() query[kSecReturnData] = true var err = SecItemCopyMatching(query, &copyResult) if err == errSecItemNotFound { let add = makeDict() query[kSecValueData] = Data("opendoor".utf8) err = SecItemAdd(add, nil) } Think Before Wrapping A lot of folks look at the SecItem API and immediately reach for a wrapper library. A keychain wrapper library might seem like a good idea but there are some serious downsides: It adds another dependency to your project. Different subsystems within your project may use different wrappers. The wrapper can obscure the underlying API. Indeed, its entire raison d’être is to obscure the underlying API. This is problematic if things go wrong. I regularly talk to folks with hard-to-debug keychain problems and the conversation goes something like this: Quinn: What attributes do you use in the query dictionary? J R Developer: What’s a query dictionary? Quinn: OK, so what error are you getting back? J R Developer: It throws WrapperKeychainFailedError. That’s not helpful )-: If you do use a wrapper, make sure it has diagnostic support that includes the values passed to and from the SecItem API. Also make sure that, when it fails, it returns an error that includes the underlying keychain error code. These benefits will be particularly useful if you encounter a keychain problem that only shows up in the field. Wrappers must choose whether to be general or specific. A general wrapper may be harder to understand than the equivalent SecItem calls, and it’ll certainly contain a lot of complex code. On the other hand, a specific wrapper may have a model of the keychain that doesn’t align with your requirements. I recommend that you think twice before using a keychain wrapper. Personally I find the SecItem API relatively easy to call, assuming that: I use the techniques shown in Less Painful Dictionaries, above, to avoid having to deal with CFDictionary. I use my secCall(…) helpers to simplify error handling. For the code, see Calling Security Framework from Swift. If you’re not prepared to take the SecItem API neat, consider writing your own wrapper, one that’s tightly focused on the requirements of your project. For example, in my VPN apps I use the wrapper from this post, which does exactly what I need in about 100 lines of code. Prefer to Update Of the four SecItem functions, SecItemUpdate is the most neglected. Rather than calling SecItemUpdate I regularly see folks delete and then re-add the item. This is a shame because SecItemUpdate has some important benefits: It preserves persistent references. If you delete and then re-add the item, you get a new item with a new persistent reference. It’s well aligned with the fundamental database nature of the keychain. It forces you to think about which attributes uniquely identify your item and which items can be updated without changing the item’s identity. Understand These Key Attributes Key items have a number of attributes that are similarly named, and it’s important to keep them straight. I created a cheat sheet for this, namely, SecItem attributes for keys. You wouldn’t believe how often I consult this! Investigating Complex Attributes Some attributes have values where the format is not obvious. For example, the kSecAttrIssuer attributed is documented as: The corresponding value is of type CFData and contains the X.500 issuer name of a certificate. What exactly does that mean? If I want to search the keychain for all certificates issued by a specific certificate authority, what value should I supply? One way to figure this out is to add a certificate to the keychain, read the attributes back, and then dump the kSecAttrIssuer value. For example: let cert: SecCertificate = … let attrs = try secCall { SecItemAdd([ kSecValueRef: cert, kSecReturnAttributes: true, ] as NSDictionary, $0) } as! [String: Any] let issuer = attrs[kSecAttrIssuer as String] as! NSData print((issuer as NSData).debugDescription) // prints: <3110300e 06035504 030c074d 6f757365 4341310b 30090603 55040613 024742> Those bytes represent the contents of a X.509 Name ASN.1 structure with DER encoding. This is without the outer SEQUENCE element, so if you dump it as ASN.1 you’ll get a nice dump of the first SET and then a warning about extra stuff at the end of the file: % xxd issuer.asn1 00000000: 3110 300e 0603 5504 030c 074d 6f75 7365 1.0...U....Mouse 00000010: 4341 310b 3009 0603 5504 0613 0247 42 CA1.0...U....GB % dumpasn1 -p issuer.asn1 SET { SEQUENCE { OBJECT IDENTIFIER commonName (2 5 4 3) UTF8String 'MouseCA' } } Warning: Further data follows ASN.1 data at position 18. Note For details on the Name structure, see section 4.1.2.4 of RFC 5280. Amusingly, if you run the same test against the file-based keychain you’ll… crash. OK, that’s not amusing. It turns out that the code above doesn’t work when targeting the file-based keychain because SecItemAdd doesn’t return a dictionary but rather an array of dictionaries (r. 21111543). Once you get past that, however, you’ll see it print: <301f3110 300e0603 5504030c 074d6f75 73654341 310b3009 06035504 06130247 42> Which is different! Dumping it as ASN.1 shows that it’s the full Name structure, including the outer SEQUENCE element: % xxd issuer-file-based.asn1 00000000: 301f 3110 300e 0603 5504 030c 074d 6f75 0.1.0...U....Mou 00000010: 7365 4341 310b 3009 0603 5504 0613 0247 seCA1.0...U....G 00000020: 42 B % dumpasn1 -p issuer-file-based.asn1 SEQUENCE { SET { SEQUENCE { OBJECT IDENTIFIER commonName (2 5 4 3) UTF8String 'MouseCA' } } SET { SEQUENCE { OBJECT IDENTIFIER countryName (2 5 4 6) PrintableString 'GB' } } } This difference in behaviour between the data protection and file-based keychains is a known bug (r. 26391756) but in this case it’s handy because the file-based keychain behaviour makes it easier to understand the data protection keychain behaviour. Import, Then Add It’s possible to import data directly into the keychain. For example, you might use this code to add a certificate: let certData: Data = … try secCall { SecItemAdd([ kSecClass: kSecClassCertificate, kSecValueData: certData, ] as NSDictionary, nil) } However, it’s better to import the data and then add the resulting credential reference. For example: let certData: Data = … let cert = try secCall { SecCertificateCreateWithData(nil, certData as NSData) } try secCall { SecItemAdd([ kSecValueRef: cert, ] as NSDictionary, nil) } There are two advantages to this: If you get an error, you know whether the problem was with the import step or the add step. It ensures that the resulting keychain item has the correct attributes. This is especially important for keys. These can be packaged in a wide range of formats, so it’s vital to know whether you’re interpreting the key data correctly. I see a lot of code that adds key data directly to the keychain. That’s understandable because, back in the day, this was the only way to import a key on iOS. Fortunately, that’s not been the case since the introduction of SecKeyCreateWithData in iOS 10 and aligned releases. For more information about importing keys, see Importing Cryptographic Keys. App Groups on the Mac Sharing access to keychain items among a collection of apps explains that three entitlements determine your keychain access: keychain-access-groups application-identifier (com.apple.application-identifier on macOS) com.apple.security.application-groups In the discussion of com.apple.security.application-groups it says: Starting in iOS 8, the array of strings given by this entitlement also extends the list of keychain access groups. That’s true, but it’s also potentially misleading. This affordance only works on iOS and its child platforms. It doesn’t work on macOS. That’s because app groups work very differently on macOS than they do on iOS. For all the details, see App Groups: macOS vs iOS: Working Towards Harmony. However, the take-home point is that, when you use the data protection keychain on macOS, your keychain access group list is built from keychain-access-groups and com.apple.application-identifier. Revision History 2025-06-29 Added the Data Protection and Background Execution section. Made other minor editorial changes. 2025-02-03 Added another specific example to the Careful With that Shim, Mac Developer section. 2025-01-29 Added somes specific examples to the Careful With that Shim, Mac Developer section. 2025-01-23 Added the Import, Then Add section. 2024-08-29 Added a discussion of identity formation to the Digital Identities Aren’t Real section. 2024-04-11 Added the App Groups on the Mac section. 2023-10-25 Added the Lost Keychain Items and Lost Keychain Items, Redux sections. 2023-09-22 Made minor editorial changes. 2023-09-12 Fixed various bugs in the revision history. Added the Erroneous Attributes section. 2023-02-22 Fixed the link to the VPNKeychain post. Corrected the name of the Context Matters section. Added the Investigating Complex Attributes section. 2023-01-28 First posted.

Hi, My app keeps getting rejected during App Review with the reason that the Sign in with Apple button is unresponsive. However, I have tested it extensively on: • A real iPad Pro (iPadOS 18.3.2) • Multiple Xcode simulators • Including an iPad Air 5th simulator (18.3.1) In all of these cases, the button works correctly. The reviewer mentioned they are using an iPad Air 5th running iPadOS 18.3.2, which I cannot find as a simulator in Xcode, nor do I have access to this exact device around me. I’m using standard SignInWithAppleButton code with no custom wrappers or UI layers on top. Here is the relevant snippet: GeometryReader { geometry in ZStack { Color.black.opacity(0.3) .ignoresSafeArea() .onTapGesture { prompt = "" showChat = false } VStack(alignment: .leading, spacing: 0){ switch purchaseManager.hasAISubscription { case 1: HStack{ } case 2: HStack{ } case 3: HStack{ } default: HStack{ } } Divider() ScrollView { VStack(alignment: .leading, spacing: 8) { ForEach(filteredChatHistory, id: \.id) { chat in } } Spacer() } .frame(maxHeight: geometry.size.height * 0.7) .defaultScrollAnchor(.bottom) .padding() Divider() HStack(){ if httpManager.isLoggedIn && purchaseManager.hasAISubscription > 0 { } } else if purchaseManager.hasAISubscription == 0{ } else{ Spacer() SignInWithAppleButton(.continue){ request in request.requestedScopes = [.email] } onCompletion: { result in switch result { case .success(let auth): switch auth.credential { case let appleCredential as ASAuthorizationAppleIDCredential: let userID = appleCredential.user saveToKeychain(userID, for: "com.xing-fu.aireader.apple.userid") if let identityTokenData = appleCredential.identityToken, let identityToken = String(data: identityTokenData, encoding: .utf8) { Task { //后端认证过,才算登录成功 await httpManager.loginWithApple(identityToken) } } break default: break } case .failure(let error): print("error") } } .frame(maxWidth: 350, maxHeight: 40) .padding() .cornerRadius(10) Spacer() } } } .overlay( // 边框 RoundedRectangle(cornerRadius: 10) .stroke(Color.g2, lineWidth: 4) ) .background(Color(UIColor.systemBackground)) .cornerRadius(10) // 圆角 .shadow(color: Color.black.opacity(0.1), radius: 5, x: 0, y: 5) .frame(width: geometry.size.width * 0.8) .onDisappear{ httpManager.alertMessage = nil } } }

General: Forums topic: Privacy & Security Forums tag: Privacy Developer > Security — This also covers privacy topics. App privacy details on the App Store UIKit > Protecting the User’s Privacy documentation Bundle Resources > Privacy manifest files documentation TN3181 Debugging an invalid privacy manifest technote TN3182 Adding privacy tracking keys to your privacy manifest technote TN3183 Adding required reason API entries to your privacy manifest technote TN3184 Adding data collection details to your privacy manifest technote TN3179 Understanding local network privacy technote Handling ITMS-91061: Missing privacy manifest forums post Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi everyone, I'm developing an iOS app using the AppsFlyer SDK. I understand that starting with iOS 14.5, if a user denies the App Tracking Transparency (ATT) permission, we are not allowed to access the IDFA or perform cross-app tracking. However, I’d like to clarify which in-app events are still legally and technically safe to send when the user denies ATT permission. Specifically, I want to know: Is it acceptable to send events like onboarding_completed, paywall_viewed, subscription_started, subscribe, subscribe_price, or app_opened if they are not linked to IDFA or any form of user tracking? Would sending such internal behavioral events (used purely for SKAdNetwork performance tracking or in-app analytics) violate Apple’s privacy policy if no device identifiers are attached? Additionally, if these events are sent in fully anonymous form (i.e., not associated with IDFA, user ID, email, or any identifiable metadata), does Apple still consider this a privacy concern? In other words, can onboarding_completed, paywall_viewed, subsribe, subscribe_price, etc., be sent in anonymous format without violating ATT policies? Are there any official Apple guidelines or best practices that outline what types of events are considered compliant in the absence of ATT consent? My goal is to remain 100% compliant with Apple’s policies while still analyzing meaningful user behavior to improve the in-app experience. Any clarification or pointers to documentation would be greatly appreciated. Thanks in advance!

Hello, we're currently evaluating the side effects of transferring our app to a different Apple developer account. Our users use SIWA to sign in to our platform which uses Auth0. As I understand it, the identifiers provided by Apple will change, and as such Auth0 will not recognise them and treat them as new users. I've read conflicting documentation, reports, discussions, etc, so it would be great if I could get some clarification on the topic. Furthermore we're concerned about the Hide My Email functionality. A lot of our users use this feature. Will the relay email for each user change with the transfer? If so, does the 'old' relay email stop working as soon as the transfer happens? Thanks in advance!

Hey everyone, I'm hitting a really frustrating issue with App Attest. My app was working perfectly with DCAppAttestService on October 12th, but starting October 13th it started failing with DCError Code 2 "Failed to fetch App UUID" at DCAppAttestController.m:153. The weird part is I didn't change any code - same implementation, same device, same everything. I've tried switching between development and production entitlement modes, re-registered my device in the Developer Portal, created fresh provisioning profiles with App Attest capability, and verified that my App ID has App Attest enabled. DCAppAttestService.isSupported returns true, so the device supports it. Has anyone else run into this? This is blocking my production launch and I'm not sure if it's something on my end or an Apple infrastructure issue.

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.

With the new ios 26 update, certain numbers will be filtered into other inboxes within imessage. What numbers are classified as "known", and will not be moved into these filters. Do they need to be a contact in your phone, or if a business texts you how will that be filtered?

We have a crash on DCDevice.current.isSupported We want to try to make a serial queue to generate tokens but the side effect would be the same token would be used on multiple server API requests that are made within a few ms of each other? Is this safe or will the Apple server immediately reject the same token being reused? Can you share how long tokens are safe to use for? Here is the code we want to try final actor DeviceTokenController: NSObject { static var shared: DeviceTokenController = .init() private var tokenGenerationTask: Task<Data?, Never>? var ephemeralDeviceToken: Data? { get async { // Re-using the token for short periods of time if let existingTask = tokenGenerationTask { return await existingTask.value } let task = Task<Data?, Never> { guard DCDevice.current.isSupported else { return nil } do { return try await DCDevice.current.generateToken() } catch { Log("Failed to generate ephemeral device token", error) return nil } } tokenGenerationTask = task let result = await task.value tokenGenerationTask = nil return result } } }

We are working on a PoC iOS App to use "Sign in with Apple" on iOS. The app needs to authenticate the current user on MDM managed corporate iPads (with Shared iPad enabled) and each user having a Managed Apple ID (created in Apple Business Manager). We have started with Apple's example app: https://developer.apple.com/documentation/authenticationservices/implementing-user-authentication-with-sign-in-with-apple When we run it on a normal iPad (without MDM supervision) it works fine. When we run the same code on a managed iPad with Shared iPad enabled and Managed Apple ID's the app errors out when a user taps the "Sign in with Apple" button. A User-facing error message is displayed: “Your Apple Account cannot be used to create accounts for other apps.” And when we run the app from Xcode we see the following logs: Authorization failed: Error Domain=AKAuthenticationError Code=-7027 "(null)" UserInfo={AKClientBundleID=com.sampleapp.test2} LaunchServices: store (null) or url (null) was nil: Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={NSDebugDescription=process may not map database, _LSLine=72, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler} Attempt to map database failed: permission was denied. This attempt will not be retried. Failed to initialize client context with error Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={NSDebugDescription=process may not map database, _LSLine=72, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler} Failed to get application extension record: Error Domain=NSOSStatusErrorDomain Code=-54 "(null)" ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1000 "(null)" Could not authenticate: The operation couldn’t be completed. (com.apple.AuthenticationServices.AuthorizationError error 1000.) We have confirmed that in ABM "Sign in with Apple" feature is enabled with "Allowed apps": "All apps". We have also confirmed that the Managed AppleIDs created in ABM have no field to provide the birthday of the user and therefore ruling out age restrictions for "Sign in with Apple". Is "Sign in with Apple" supported in MDM managed iPADs with Shared iPad enabled and managed AppleIDs? If it is supported, do we know what other configurations we need to get it to work? Do we know why "Sign in with Apple" would error out with Authorization failed: Error Domain=AKAuthenticationError Code=-7027 "(null)" UserInfo={AKClientBundleID=com.sampleapp.test2} LaunchServices: store (null) or url (null) was nil: Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={NSDebugDescription=process may not map database, _LSLine=72, Environment: • iPadOS version: IPadOS Version 18.7 • Xcode version: Version 26.0 (17A324) • Device type: iPad Air 11-inch (M3) in Shared iPad mode • Account type: Managed Apple ID created in ABM enrolled with Intune MDM) Thank you

Is there a way (in code or on the OAuth2 server/webpage) to specify the desired window size when using ASWebAuthenticationSession on macOS? I haven't found anything, and we would prefer the window to be narrower. For one of our users, the window is even stretched to the full screen width which looks completely broken…

"Our app has absolutely no integration with DiDi login. We only integrate WeChat, QQ, carrier, and Apple ID login, and all related login entry icons are local resources. On an iPhone 16 Pro Max device with iOS system version 18.7, there was one isolated incident where the Apple ID login entry icon mysteriously changed to the DiDi app icon. What could be the possible iOS system-level causes for this?"

this is my monitor image that shows DeviceCheck api responding very slowly.

We have been sending emails through Sparkpost via Braze inc. to the Apple Private Relay users with "@privaterelay.appleid.com" starting from around June 20th or so. Upon August 9th 06:00 UTC, we have noticed a sudden increase of "Hard Bounce" for nearly 20,000 users using the Apple's private relay email address, rendering the email sending useless for these customers. We have been constantly been able to send them emails, including just before this timeframe (e.g. August 9th 03:00 UTC), so it was a very sudden purge of the user data that has been done without our consent. From a business perspective, this hurts a lot for the un-sendable users since we have no way of contacting them if not for the private address. We are desperate to know what has happened for these customers that has been "hard bounced". We are suspecting that it should be tied to the private email and the users primary email (or user data's) tie in the Apple server being gone, but not sure enough since there is no such documentation nor any way to acknowledge what has happened anywhere. We will provide any information possible for resolving. Thank you.

Hi, Xcode Instruments shows multiple Points of Interest with the information that the framework is not listed in my Privacy Manifest. However, I have already included them in the Privacy Manifest under the privacy tracking domains. I have this problem with every tracking domain i listed in the Privacy Manifest's Privacy Tracking Domains. Did I make a mistake in my Privacy Manifest declaration?

I am trying to integrate those into my app, stuck on it would not transfer to view that inside app, can someone help? Scott

Could you tell me about account security and passkeys? Our service is considering implementing passkeys, and these questions are to understand how Apple protects accounts from third parties. ① Apple website states that two-factor authentication is mandatory for newly created Apple Accounts. When did this requirement come into effect? What are the conditions for users who do not have two-factor authentication enabled? ② Apple website mentions that a verification code may be required when signing into an Apple Account from a new device or browser. Is my understanding of the situations where a verification code is requested accurate, as listed below? Are there any other situations? Completely signing out of the Apple Account on that device. Erasing the device. Needing to change the password for security reasons. ③ If a user is already using a passkey on an Apple device, and then upgrades to a new device, will additional authentication, such as entering a PIN code, be required to use the passkey on the new device?

I'm developing a passkey manager using ASCredentialProviderViewController. I've set a custom AAGUID in the attestation object during registration: let aaguid = Data([ 0xec, 0x78, 0xfa, 0xe8, 0xb2, 0xe0, 0x56, 0x97, 0x8e, 0x94, 0x7c, 0x77, 0x28, 0xc3, 0x95, 0x00 ]) However, when I test on webauthn.io, the relying party receives: AAGUID: 00000000-0000-0000-0000-000000000000 Provider Name: "iCloud Keychain" It appears that macOS overwrites the AAGUID to all zeros for third-party Credential Provider Extensions. This makes it impossible for relying parties to distinguish between different passkey providers, which is one of the key purposes of AAGUID in the WebAuthn specification. Is this expected behavior? Is there a way for third-party Credential Provider Extensions to use their own registered AAGUID? Environment: macOS 26.2 Xcode 26.2