NSURLCredentialPersistencePermanent lacks built‑in client‑side expiration

Answer first

Foundation does not add a TTL or automatic purge to a credential saved with NSURLCredentialPersistencePermanent. The credential is written to the user Keychain and remains there until you explicitly remove it, the user deletes it, or you overwrite it. NSURLCredential does not expose creation or modification dates through the URL Loading System API, so client-side expiry cannot be enforced with Foundation alone.

The URL Loading System will replay a stored Permanent credential for matching protection spaces on subsequent challenges. Removal with removeCredential:forProtectionSpace: prevents future reuse but does not abort in-flight connections that already captured the credential.

Timely invalidation without a custom timestamp store

Confirmed fact: there is no built-in client-side expiration. A server-driven pattern is the only Foundation-native option.

1. Keep the delegate challenge handler as the invalidation point. When a 401 or 403 is received for a protection space that previously used a Permanent credential, do not return the stored credential again.
2. Call [[NSURLCredentialStorage sharedCredentialStorage] removeCredential:forProtectionSpace:] for that protection space immediately in the challenge handler, then return a new credential or cancel.
3. Avoid Permanent persistence if proactive expiry is required. Use NSURLCredentialPersistenceForSession for session-only lifetime, or use short-lived tokens with server-issued expiry and re-authenticate on 401. This is a likely explanation for why teams move away from Permanent when client-side TTL matters.

This pattern is reactive, not proactive. In-flight requests may still be sent with the stale credential until they fail.

Coordinating removal across processes sharing a protection space

Confirmed fact: apps in the same Keychain Access Group share the same keychain items. Removal is visible only on the next keychain query.

Steps for this case:

• Ensure all processes use the same Keychain Access Group entitlement and the same protection space identifier.
• Perform removal via the shared NSURLCredentialStorage singleton or SecItemDelete with matching query attributes. Peer processes will see the deletion the next time they query [[NSURLCredentialStorage sharedCredentialStorage] credentialsForProtectionSpace:] or SecItemCopyMatching.
• Because there is no push invalidation, add an explicit cross-process signal for timely coordination. A Darwin notification, distributed notification, or an App Group NSUserDefaults flag can be posted by the process that performed removal so peers can proactively clear caches and avoid using a stale credential on the next request.

App Sandbox and matching App ID prefix/team ID are required for the group to be readable across processes.

OS-level notifications for Keychain changes

Confirmed fact on macOS: SecKeychainAddCallback and SecKeychainRegisterCallback exist for keychain change notifications. These are macOS-specific and behavior is not guaranteed to be identical on iOS, macOS Catalyst, or future OS versions.

Likely explanation for iOS: there is no documented public cross-process Keychain change notification. Refresh triggering on iOS must rely on app-level signaling or re-challenge on next use.

Verification you can run locally: inspect credentialsForProtectionSpace before and after a 401 to confirm Permanent survives until explicit removal; remove mid-challenge and observe an already started URLSessionDataTask still transmits the old credential on retry; from two apps in a shared group delete the item in one and query in the other to confirm visibility only on next query; on macOS register a SecKeychain callback, delete the item, and confirm the callback fires.

One diagnostic detail that changes the recommendation: are you targeting iOS only or macOS as well? The availability of SecKeychain callbacks and the choice of cross-process signaling depends on that.