Hi, We're encountering an intermittent issue where certain users are unexpectedly logged out of our app and unable to log in again. We believe we've narrrowed down the issue to the Keychain due to the following reasons: We use a keychain item to determine if the member is logged in or not. Failure to retrieve the value leads the app to believe the member is logged out. API error logs on the server show 3 missing values in fields that are each populated from items stored in the keychain. Additional Notes: The issue is hard to reproduce and seems to affect only a subset of users. In some cases, uninstalling and reinstalling the app temporarily resolves the problem, but the issue recurs after a period of time. The behavior appears to have coincided with the release of iOS 18. We’re using the “kSecAttrAccessibleWhenUnlocked” accessibility attribute. Given that our app doesn’t perform background operations, we wouldn’t expect this to be an issue. We’re also considering changing this to "kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly" to see if this might resolve the issue. We're the keychain-swift library to interact with the keychain. We are currently adding extensive logging around our keychain implementation to confirm our findings but are looking for any additional input. Questions: Has anyone encountered similar keychain behavior on iOS 18? Are there known changes or stability issues with the keychain in iOS 18 that might lead to such intermittent “item not found” errors? Any recommended workarounds or troubleshooting steps that could help isolate the problem further? Thanks for any help you can provide.

Is there a way to unlock login keychain without using password and with any other authentication factor supported by 3rd party MFA options?

I'm working on replacing an AppKit-based Mac app with one built on Catalyst, and the Catalyst app doesn't seem to be able to read the keychain item that was saved by the old app. Both apps are using the same bundle ID. The old app uses the old SecKeychain APIs - SecKeychainFindGenericPassword and friends - and the Catalyst app uses the newer SecItemCopyMatching and such. When I try using the new API in the old app to search for the entry, it works, but the exact same code in Catalyst fails. Here's how I save an item in the old app: NSString *strItemId = @"my_item_id; NSString *username = @"user"; const char *userPointer = [username UTF8String]; NSString *password = @"password"; const char *pwPointer = [password UTF8String]; SecKeychainItemRef ref = NULL; OSStatus status = SecKeychainFindGenericPassword(0, (UInt32)strlen(strItemId.UTF8String), strItemId.UTF8String, 0, NULL, NULL, NULL, &ref); if (status == errSecSuccess && ref != NULL) { //update existing item SecKeychainAttribute attr; attr.length = (UInt32)strlen(userPointer); attr.data = (void *)userPointer; attr.tag = kSecAccountItemAttr; SecKeychainAttributeList list; list.count = 1; list.attr = &attr; OSStatus writeStatus = SecKeychainItemModifyAttributesAndData(ref, &list, (UInt32)strlen(pwPointer), pwPointer); } else { status = SecKeychainAddGenericPassword(NULL, (UInt32)strlen(strItemId.UTF8String), strItemId.UTF8String, (UInt32)strlen(userPointer), userPointer, (UInt32)strlen(pwPointer), pwPointer, NULL); } And here's the query code that works in the old app but returns errSecItemNotFound in Catalyst: NSMutableDictionary *queryDict = [[[NSMutableDictionary alloc]init]autorelease]; [queryDict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id)kSecClass]; [queryDict setObject:(@"my_item_id") forKey:(__bridge id)kSecAttrService]; [queryDict setObject:(__bridge id)kSecMatchLimitOne forKey:(__bridge id)kSecMatchLimit]; [queryDict setObject:(__bridge id)kCFBooleanTrue forKey:(__bridge id)kSecReturnAttributes]; CFMutableDictionaryRef outDictionary = nil; OSStatus err = SecItemCopyMatching((__bridge CFDictionaryRef)queryDict, (CFTypeRef *)&outDictionary); I tried creating a new blank AppKit-based Mac app project in Xcode and gave it the old Mac app's bundle ID, and the SecItemCopyMatching query code above works there. Then I created a new iOS target with Catalyst enabled, also with the same bundle ID, and the query code running there under Catalyst returned errSecItemNotFound. So maybe the issue is something specific to Catalyst? Is there something I need to do with the Catalyst app to give it access to the old app's keychain entry, besides setting its bundle ID to match the old app?

Greetings! I want to add my pre-compiled binary of v2ray to my application so I can activate it in background as a proxy and run stuff through it. I've codesigned it via: codesign -s - -i production.myproject.v2ray -o runtime --entitlements v2ray.entitlements -f v2ray Contents of entitlements file: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.security.app-sandbox</key> <true/> <key>com.apple.security.files.downloads.read-write</key> <true/> <key>com.apple.security.files.user-selected.read-write</key> <true/> <key>com.apple.security.network.client</key> <true/> <key>com.apple.security.network.server</key> <true/> </dict> </plist> Originally I ran it like this without sandboxing from my main target app: guard let v2rayPath = Bundle.main.path(forResource: "v2ray", ofType: nil) else { throw NSError(domain: "ProxyController", code: 1, userInfo: [NSLocalizedDescriptionKey: "V2Ray binary not found in bundle"]) } let task = Process() task.executableURL = URL(fileURLWithPath: v2rayPath) task.arguments = ["-config", configURL.path] // Redirect output for debugging let pipe = Pipe() task.standardOutput = pipe task.standardError = pipe``` And it ran flawlessly. Now it refuses to start. Any help, pointers or examples of such usage will be greatly appreciated

Trying to validate external reference identifiers with SecTrustEvaluateWithError Method by setting reference Ids to SecPolicyCreateSSL() & SecPolicyCreateWithProperties() But two concerns are - Validates for correct reference IDs but gives error for combination of wrong & correct reference Ids 398 days validity works mandatorily before reference Ids check. Is there any other to validate external reference Ids?, which give flexibility To pass multiple combinations of reference IDs string (wrong, correct, IP, DNS) To validate reference ID without days validity of 398. Please suggest. Any help here is highly appreciated.

I was referred to here, #102484182418 I'm trying to setup apple login on my community site but I'm having a hard time getting it to work. I keep getting "invalid_request​ Invalid client id or web redirect url." The last tech said she thanks its setup right but we could not get it to work. Here are my steps https://xenforo.com/docs/xf2/connected-account-apple/ I just someone to look at my Certificates, Identifiers &amp; Profiles and make sure I have them setup right.

Quinn, in your post "App Groups: macOS vs iOS: Fight!", you mention that an app must meet at least one of four criteria to access an app group container without user intervention: Your app is deployed via the Mac App Store (A). Or via TestFlight when running on macOS 15.1 or later (B). Or the app group ID starts with your app’s Team ID (C). Or your app’s claim to the app group is authorised by a provisioning profile embedded in the app (D) [1]. Our app is distributed directly (Developer ID), so it doesn't meet the first two criteria. We already had the app group ID set up to match the iOS ID (without our Team ID) and changing it now would affect our users already-stored data, so criteria C isn't really an option either. That brings us to criteria D. We've added the App Groups Capability to our App ID on the Developer site and creating a Developer ID provisioning profile with this App ID. However, for some reason the App Group Capability is not included in the provisioning profile. How then do we go about satisfying criteria D ("your app’s claim to the app group is authorised by a provisioning profile embedded in the app (D)")? If this is impossible, how can we migrate our user's data away from the affected container?

Hi, I've been working to build Apple sign in into my application using a low code tool called GeneXus. The instructions seem pretty straight forward however it's not working when I try signing in from the app. See GeneXus instructions here: https://wiki.genexus.com/commwiki/wiki?44478,GAM+-+Apple+Authentication+type The only section that I didn't do was to verify the domain which according to the instructions is required for apple sign in to work. This was backed up by the GeneXus support team. I can't find how to verify the domain though? The support team seem to think Apple will send me the domain association file detailed in the link below and I simply add that to the server: https://developer.apple.com/documentation/xcode/supporting-associated-domains#Add-the-associated-domains-entitlement-to-your-app However I can't find where this file would be generated? I also can't see the button to register the domain in the first place!

Hi everyone, I’m working on an iOS app that uses biometric authentication to access secure keychain items and private keys stored in the Secure Enclave with some data encryption/decryption with those keys. My goal is to minimize the number of biometric prompts by reusing the authentication result within a short time window. I have the following setup: When writing the biometry-restricted keychain items and Secure Enclave keys, I use LAContext with the property LATouchIDAuthenticationMaximumAllowableReuseDuration = 1 minute, and I pass this context as the kSecUseAuthenticationContext field in the query. When retrieving these items later (in a synchronous sequence upon app launch), I pass the same instance of LAContext as the kSecUseAuthenticationContext field. The issue: If I unlock my device and the biometric reuse time has not expired (i.e., less than 1 minute), the first two actions (keychain item retrieval and Secure Enclave key retrieval) do not prompt for Face ID. However, when I attempt to decrypt data with the private key using SecKeyCreateDecryptedData, I’m prompted for Face ID even if the biometric reuse time is still valid. If the biometric reuse time has expired (more than 1 minute since last authentication), I get prompted for Face ID on the first action (keychain retrieval), and subsequent actions (including data decryption) reuse that biometric result. Question: Does this behavior mean that SecKeyCreateDecryptedData ignore the LATouchIDAuthenticationMaximumAllowableReuseDuration property of LAContext, causing an additional biometric prompt during decryption with the private key? Or is there another reason for this behavior? Is there a way to make the biometric result reusable across all these actions, including decryption? Thank you!

I am working on adding RFC4217 Secure FTP with TLS by extending Mike Gleason's classic libncftp client library. I refactored the code to include an FTP channel abstraction with FTP channel abstraction types for TCP, TLS, and TCP with Opportunistic TLS types. The first implementation of those included BSD sockets that libncftp has always supported with the clear TCP channel type. I first embarked on extending the sockets implementation by adding TCP, TLS, and TCP with Opportunistic TLS channel abstraction types against the new, modern Network.framework C-based APIs, including using the “tricky” framer technique to employ a TCP with Opportunistic TLS FTP channel abstraction type to support explicit FTPS as specified by RFC4217 where you have to connect first in the clear with TCP, request AUTH TLS, and then start TLS after receiving positive confirmation. That all worked great. Unfortunately, at the end of that effort, I discovered that many modern FTPS server implementations (vsftpd, pure-ftpd, proftpd) mandate TLS session reuse / resumption across the control and data channels, specifying the identical session ID and cipher suites across the control and data channels. Since Network.framework lacked a necessary and equivalent to the Secure Transport SSLSetPeerID, I retrenched and rewrote the necessary TLS and TCP with Opportunistic TLS FTP channel abstraction types using the now-deprecated Secure Transport APIs atop the Network.framework-based TCP clear FTP channel type abstraction I had just written. Using the canonical test server I had been using throughout development, test.rebex.net, this Secure Transport solution seemed to work perfectly, working in clear, secure-control-only, and secure-control+data explicit FTPS operation. I then proceeded to expand testing to include a broad set of Microsoft FTP Service, pure-ftpd, vsftpd, proftpd, and other FTP servers identified on the Internet (a subset from this list: https://gist.github.com/mnjstwins/85ac8348d6faeb32b25908d447943300). In doing that testing, beyond test.rebex.net, I was unable to identify a single (among hundreds), that successfully work with secure-control+data explicit FTPS operation even though nearly all of them work with secure-control-only explicit FTPS operation. So, I started regressing my libncftp + Network.framework + Secure Transport implementation against curl 8.7.1 on macOS 14.7.2 “Sonoma": % which curl; `which curl` --version /usr/bin/curl curl 8.7.1 (x86_64-apple-darwin23.0) libcurl/8.7.1 (SecureTransport) LibreSSL/3.3.6 zlib/1.2.12 nghttp2/1.61.0 Release-Date: 2024-03-27 Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp Features: alt-svc AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz MultiSSL NTLM SPNEGO SSL threadsafe UnixSockets I find that curl (also apparently written against Secure Transport) works in almost all of the cases my libncftp does not. This is a representative example: % ./samples/misc/ncftpgetbytes -d stderr --secure --explicit --secure-both ftps://ftp.sjtu.edu.cn:21/pub/README.NetInstall which fails in the secure-control+data case with errSSLClosedAbort on the data channel TLS handshake, just after ClientHello, attempts whereas: % curl -4 --verbose --ftp-pasv --ftp-ssl-reqd ftp://ftp.sjtu.edu.cn:21/pub/README.NetInstall succeeds. I took an in-depth look at the implementation of github.com/apple-oss-distributions/curl/ and git/github.com/apple-oss-distributions/Security/ to identify areas where my implementation was, perhaps, deficient relative to curl and its curl/lib/vtls/sectransp.c Secure Transport implementation. As far as I can tell, I am doing everything consistently with what the Apple OSS implementation of curl is doing. The analysis included: SSLSetALPNProtocols Not applicable for FTP; only used for HTTP/2 and HTTP/3. SSLSetCertificate Should only be relevant when a custom, non-Keychain-based certificate is used. SSLSetEnabledCiphers This could be an issue; however, the cipher suite used for the data channel should be the same as that used for the control channel. curl talks about disabling "weak" cipher suites that are known-insecure even though the default suites macOS enables are unlikely to enable them. SSLSetProtocolVersionEnabled We do not appear to be getting a protocol version negotiation error, so this seems unlikely, but possible. SSLSetProtocolVersionMax We do not appear to be getting a protocol version negotiation error, so this seems unlikely, but possible. SSLSetProtocolVersionMin We do not appear to be getting a protocol version negotiation error, so this seems unlikely, but possible. SSLSetSessionOption( , kSSLSessionOptionFalseStart) curl does seem to enable this for certain versions of macOS and disables it for others. Possible. Running curl with the --false-start option does not seem to make a difference. SSLSetSessionOption( , kSSLSessionOptionSendOneByteRecord) Corresponds to "*****" which seems defaulted and is related to an SSL security flaw when using CBC-based block encryption ciphers, which is not applicable here. Based on that, further experiments I attempted included: Disable use of kSSLSessionOptionBreakOnServerAuth: No impact Assert use of kSSLSessionOptionFalseStart: No impact Assert use of kSSLSessionOptionSendOneByteRecord: No impact Use SSLSetProtocolVersionMin and SSLSetProtocolVersionMax in various combinations: No impact Use SSLSetProtocolVersionEnabled in various combinations: No impact Forcibly set a single cipher suite (TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, known to work with a given server): No impact Employ a SetDefaultCipherSuites function similar to what curl does (filtering out “weak” cipher suites): No impact Notably, I can never coax a similar set of cipher suites that macOS curl does with that technique. In fact, it publishes ciphers that aren’t even in &lt;Security/CipherSuite.h&gt; nor referenced by github.com/apple-oss-distributions/curl/curl/lib/vtls/sectransp.c. Assert use of kSSLSessionOptionAllowRenegotiation: No impact Assert use of kSSLSessionOptionEnableSessionTickets: No impact Looking at Wireshark, my ClientHello includes status_request, signed_certificate_timestamp, and extended_master_secret extensions whereas macOS curl's never do--same Secure Transport APIs. None of the above API experiments seem to influence the inclusion / exclusion of those three ClientHello additions. Any suggestions are welcomed that might shine a light on what native curl has access to that allows it to work with ST for these FTP secure-control+data use cases.

Hi, We came accross with 2 devices, iPhone 12 and iphone16 pro. the both have same device code. Both the devices have same apple id and belongs to same user I had understanding that device codes are unique to device. How this can happen? Any remediation? Thanks, Veena

Why does the following code generate a public key that can't be parsed by openssl? import Security import CryptoKit func generateKeys() throws -> (privateKey: SecKey, publicKey: SecKey) { let query: [String: Any] = [ kSecAttrKeyType as String: kSecAttrKeyTypeECSECPrimeRandom, kSecAttrKeySizeInBits as String: 256, kSecAttrIsPermanent as String: false ] var error: Unmanaged<CFError>? guard let privateKey = SecKeyCreateRandomKey(query as CFDictionary, &error) else { throw error!.takeRetainedValue() } let publicKey = SecKeyCopyPublicKey(privateKey)! return (privateKey, publicKey) } extension SecKey { func exportBase64EncodedKey() -> String { var error: Unmanaged<CFError>? guard let data = SecKeyCopyExternalRepresentation(self, &error) else { fatalError("Failed to export key: \(error!.takeRetainedValue())") } return (data as Data).base64EncodedString(options: [.lineLength64Characters]) } } func printPublicKey() { let keyPair = try! generateKeys() let encodedPublicKey = keyPair.publicKey.exportBase64EncodedKey() var header = "-----BEGIN PUBLIC KEY-----" var footer = "-----END PUBLIC KEY-----" var pemKey = "\(header)\n\(encodedPublicKey)\n\(footer)\n" print(pemKey) } printPublicKey() when parsing the key I get this: openssl pkey -pubin -in new_public_key.pem -text -noout Could not find private key of Public Key from new_public_key.pem 404278EC01000000:error:1E08010C:DECODER routines:OSSL_DECODER_from_bio:unsupported:crypto/encode_decode/decoder_lib.c:102:No supported data to decode. Replacing kSecAttrKeyTypeECSECPrimeRandom with kSecAttrKeyTypeRSA and a bigger key size (e.g. 2048) gives me a working public key that can be parsed by Openssl. Thanks!

I am trying to implement a login page in SwiftUI for an idp that relies on passkeys only, following the sample code from the food truck app. The registration of a new passkey works fine but when it comes to signing in, ASAuthorizationPlatformPublicKeyCredentialProvider().createCredentialAssertionRequest returns a signature that cannot be verified by the server. On safari (and other browsers) the signing in&up process works fine and additionally, a passkey registered from the swift app works on the web, which leads me to believe there is an issue in the AuthenticationServices framework as every other steps works without any problem. The verification of the signature happens on the server side (after several validation steps of the other parameters) with WebCrypto.subtle.verify(verifyAlgorithm, key, signature, data); With the data argument being a concat of the clientDataJSON and the authenticatorData and for an apple authenticator, the key argument (which is the public key stored by the server) is an EC2 key with the following verifyAlgorithm argument: verifyAlgorithm = { name: 'ECDSA', hash: { name: SHA-256 }, }; After carefully analyzing multiple responses, coming both from the app and safari, either on iOS or macOS, I can safely say that the ASAuthorizationResult.passkeyAssertion returns the expected values for: rawAuthenticatorData rawClientDataJSON credentialID userID Which all match the expected values during the server-side validation. The only remaining value from the ASAuthorizationResult.passkeyAssertion is the signature, which as mentioned above, is invalid when verified by the server. I already submitted a bug report (FB15113372) as well as a DTS request, but haven’t received any feedback yet. In order to further narrow down the problem, I replicated the signature verification process in a sage notebook. I got the same result: the signature produced in Safari is fine, but the one from the Swift app is invalid. I collected some thoughts of potential issues in this notebook, but I still haven’t been able to draw a clear conclusion on why does this issue occur. Hence if anyone has knowledge of this issue or has a similar problem with signature verification, their advice is most welcomed. Thank you in advance for your help PS: All the recent tests were made on the latest publicly available OS releases (iOS 18.01, macOS 15.0.1) and Xcode 16.0

I am developing a authorization plugin for mac. i am using SFAuthorizationPluginView as i need a webView(WKWebKit) which will perform webAuthn. But the webview is not rendering the requested webpage( i have stable internet connectio). Is it an expected behaviour for a webview in an authorization plugin?

In the macOS 14.0 SDK, environment and library constraints were introduced, which made defense against common attack vectors relatively simple (especially with the LightWeightCodeRequirements framework added in 14.4). Now, the application I'm working on must support macOS 13.0 too, so I was looking into alternatives that do work for those operating systems as well. What I found myself is that the SecCode/SecStaticCode APIs in the Security Framework do offer very similar fashion checks as the LightWeightCodeRequirements framework does: SecCodeCopySigningInformation can return values like signing identifier, team identifier, code requirement string and so on. SecStaticCodeCreateWithPath can return a SecStaticCode object to an executable/app bundle on the file system. Let's say, I would want to protect myself against launchd executable swap. From macOS 14.0 onward, I would use a Spawn Constraint for this, directly in the launchd.plist file. Before macOS 14.0, I would create a SecStaticCode object for the executable path found in the launchd.plist, and then examine its SecCodeCopySigningInformation dictionary. If the expectations are met, only then would I execute the launchd.plist-defined executable or connect to it via XPC. Are these two equivalent? If not, what are the differences?

I have code where we're evaluating SSL certificates in sec_protocol_options_set_verify_block. We have the following code: let secTrust = sec_trust_copy_ref(trust).takeRetainedValue() isValidCertificate = SecTrustEvaluateWithError(secTrust, &amp;error) I'm getting the error that the maximum temporal validity period has been exceeded: Error Domain=NSOSStatusErrorDomain Code=-67901 "“server.com” certificate is not standards compliant" UserInfo={NSLocalizedDescription=“server.com” certificate is not standards compliant, NSUnderlyingError=0x300ddd350 {Error Domain=NSOSStatusErrorDomain Code=-67901 "Certificate 0 “server.com” has errors: Certificate exceeds maximum temporal validity period;" UserInfo={NSLocalizedDescription=Certificate 0 “server.com” has errors: Certificate exceeds maximum temporal validity period;}}} When I inspect the certificate, it's valid for 394 days (4/16/2024 through 5/15/2025) and other than being a wildcard certificate, should be fully trusted. I can't find any information about this specific error. Is Apple requiring SSL certs to be less than 398 days now? Which brings me to the second part - we're OK using this to workaround it var trustFailureExceptions: CFData? = SecTrustCopyExceptions(secTrust) SecTrustSetExceptions(secTrust, trustFailureExceptions) But I haven't found anyway to be able to inspect trustFailureExceptions to ensure it only is this specific error. I'm concerned that otherwise this is going to open up validity exceptions for any certificate problem, which is definitely not what I want to do.

Hello, I'm exploring the Secure Enclave APIs, and I'm wondering if it's possible to "cryptographically" determine if a block of data was signed on the Secure Enclave. When I sign a block of data using the Secure Enclave (which implies using a key pair automatically generated by the enclave) and distribute the public key to others, is there any way to verify if the message was encrypted on it / its private key was generated by it? In other words, what I'm trying to achieve is to make sure that the public key hasn't been tampered with until it reaches its destination (including on-device threats, since otherwise I could've used a normal keychain item, perhaps?). For the purpose of this example, I'm not necessarily interested in figuring out if the key was signed on a certain device's enclave, but rather on any Secure Enclave. So, using something derived from the enclave's GID Key (described in the Apple Platform Security guide) would work for this.

Hello. On my game I have Apple Sing In option that is required to keep user high score, show name in game, and for other app functionality. Game is made on Unity. Now when I'm trying to port the game to Vision Pro, Im getting error that Authentication is not supported on this platform. It may be the plugin issue that I'm using(not sure yet). But I also didn't find any documentation for native code ( so I could make plugin that unity game could use). Question: does VisionOS support Apple Sing In in the applications? if yes please give me some resources. if no - is there any plans to add that functionality? Thanks.

Hello everyone, I’m encountering an issue with Sign in with Apple in my watchOS app and would appreciate any guidance. Background: Initially, I did not have the Sign in with Apple capability enabled on my watchOS app. I have since enabled the capability and grouped it with my iOS app. For new user accounts created after this change, everything works perfectly: The credentialState check returns .authorized on both iOS and watchOS. However, for existing user accounts (created before enabling the capability on watchOS): The credentialState check returns not authorized on watchOS. The check still returns .authorized on iOS for these accounts. Error Details: When calling ASAuthorizationAppleIDProvider.credentialState(forUserID:) on watchOS for existing accounts, I receive the following error: Error Domain=AKAuthenticationError Code=-7074 "(null)" My Suspicions: I believe the issue arises because the existing Sign in with Apple tokens are only associated with the iOS app’s bundle identifier and not with the watchOS app’s bundle identifier. Since the capability wasn’t enabled on the watchOS app when these accounts were created, their tokens aren’t valid for the watchOS app. Questions: Is this the correct explanation for why the credentialState check fails on watchOS for existing accounts, resulting in the AKAuthenticationError Code=-7074 error? Can I update or migrate the existing accounts so that their Sign in with Apple tokens are valid for the watchOS app as well? If so, how can this be achieved? Are there any best practices for handling this situation without requiring users to re-authenticate or removing the credentialState check from the watchOS app? Goal: I want to maintain the credentialState check on the watchOS app because it works correctly for new accounts and is important for security. I’m looking for a solution that allows existing users to continue using the app on their Apple Watch without interruption or additional sign-in steps. Any help or suggestions would be greatly appreciated! Thank you!

I'm attempting to make an alternative to the MS Company Portal app. We are looking to implement PSSO in our organization and are not satisfied with the features that Company Portal offers. One example of this is, we don't like what the password reset workflow looks like. We'd like to make it so the reset process is more fluid. Additionally, we want to report the status of the service more readily (not requiring clicking so far into System Settings to locate it). These are just a couple examples of what we're not thrilled with... In light of this, my desire is to create another app, that includes a PSSO extension that is able to connect to Entra. I have scoured the internet, developer portal, and macadmin forum... and have failed to find a comprehensive guide for helping me through this. Currently Using: IDP: Entra Language: SwiftUI Frameworks: MSAL and KeychainAccess Any help would be great... a comprehensive guide would be AMAZING!