Recommendation for Authentication for the Enterprise with Identity Provider.

For enterprise with MDM, the answer is clear: ASWebAuthenticationSession + SSO Extension is the right stack, and MDM makes it cleaner not harder.

The SSO Extension (ASAuthorizationSingleSignOnProvider) is exactly built for your use case — MDM can deploy the extension silently across all managed devices, and once it's in place, every app and Safari get SSO automatically without any per-app authentication code. That's your "stop implementing custom auth frameworks" goal solved.

The key thing that trips people up with SSO Extension in enterprise: the extension must be installed on the device before your app tries to use it. With MDM this is straightforward — push the extension as a managed app first. Without MDM it's fragile.

For the WKWebView history: Apple has been clear that WKWebView and UIWebView are wrong for auth flows because they can't share cookies with Safari or other apps.

ASWebAuthenticationSession is the only correct approach for OAuth/OIDC flows — it shares the system cookie store and gets the SSO benefit automatically. Practical path forward:

• Use ASWebAuthenticationSession for any OAuth/OIDC flows
• Implement ASAuthorizationSingleSignOnProvider via your IdP's SSO extension
• Use MDM to deploy and configure the extension fleet-wide
• Most major IdPs (Okta, Azure AD, Ping) already ship SSO extensions — check if yours does before building custom

What IdP are you using? That changes the specifics significantly. — Divya Ravi, Senior iOS Engineer

Thanks for the reply. We are using Ping at this moment and are in a project to move to PingONE (instead of onprem) For MDM provider, we make use of Workspace One from Omnissa but there's a running project to move to Intune. Great to have multiple transitions at the same time....

The ASWebAuthenticationSession option is working for us once 'persistent cookies' are enabled. But once only session cookies are allowed, the SSO experience is not given. Can you tell why that's the case?

Also, is there any resource available that explains how to set up the SSO Extension on MDM side and how would it change the experience compared to what we have now (with just ASWebAuthenticationSession).

To elucidate, we've implemented login now with ASWebAuthenticationSession. Our custom framework deals with obtaining the accesstoken/idtoken etc. once receiving the authorizationcode from ASWebAuthenticationSession. We stopped with the UIWebView/WKWebView some time ago as there were also some CVE restrictions as I recall.

Also, once we implement the SSO behavior for this identity provider, we want to grant longer sessionlifetime once a device is managed by our MDM. A few years ago I did a sample as well that used (yet another) certificate, which the app could present to a website (using mTLS). We noticed a popup from Apple showing up, asking the user for permission and selecting a given certificate. Can you tell if there can be set a default option, so the user is not confronted with this popup anymore and device integrity can be checked pro-actively?

Great context. Three things:

Session cookies breaking SSO: The issue is ASWebAuthenticationSession relies on the system cookie store for session continuity. Session-only cookies don't persist between invocations, so each call looks like a fresh login to PingOne. Fix: move session state out of cookies entirely. Store the refresh token in Keychain with kSecAttrAccessibleAfterFirstUnlock and silently refresh without re-presenting the browser. Your custom framework already does the token exchange — just persist the refresh token there.

SSO Extension with Intune: Microsoft ships an Enterprise SSO plugin that works with PingOne out of the box. Configure via MDM using the com.apple.extensiblesso payload — once deployed, every app gets silent SSO with no per-app code changes. Users authenticate once, all subsequent launches are silent. Workspace One supports the same via Hub integration, so you can pilot before the Intune migration completes.

mTLS certificate popup: You can't suppress it on unmanaged devices — iOS requires explicit consent by design. On MDM-managed devices: provision the certificate via com.apple.security.pkcs12 MDM payload instead of bundling it in the app. MDM-provisioned certificates match domains silently without the selection UI.

For proactive device integrity + longer session lifetime: combine with DCAppAttestService, pass the attestation result as a custom claim in your PingOne token exchange, and gate extended sessions on valid attestation rather than certificate presence alone. — Divya Ravi, Senior iOS Engineer

Thanks, that seems to be some great pointers to further look into.

For setting up the SSO extension, did you find any other Apple documentation that helped you configure and debug it?

For the cookies subject; Did you get any meaningful instructions from Apple that resolve around storing the refreshtoken this way?

For Intune, we did managed to see some EntraID behavior around sso extension, but as this is Microsoft I expect the configuration to be easy. Did you find the same with Ping (as you say 'supported from out of the box')? Unfortunately, I could not manage to get this tested. The SSO Extension is pushed to my test device, but it's unclear what details I needed to provide. I believe only the domains of the identity provider are specified here.

To conclude, I'm hoping to get some more guidance on this implemention. Even both Omnissa and Ping are actually not able to offer much support on this so was hoping Apple has some more documentation to look into. But for sure this is food for thought!

During my investigation I could only find this video of wwdc in relation to setting up a single sign on extension.

https://developer.apple.com/videos/play/tech-talks/301/

Perhaps you have more updated material which is useful. Any help is greatly appreciated.