Extensible Single Sign-On on iOS
TL;DR interesting for only a few enterprise app developers
In this blog post, I'll cover Extensible Single Sign-On, also commonly referred to as SSO extension. I'll check if such is interesting for you as an iOS developer. I'll focus on a specific type of SSO extension (redirect), and I'll also share the best reference material I could find for your exploration.
Do you need to care?
Are you a developer working on consumer-facing iOS apps? Then you can stop reading (unless you are extremely curious), and I recommend that you should instead look into Sign in with Apple.
If you are an enterprise developer and you or your customers/clients do not use a Mobile Device Management (MDM) solution, then you are out, too. MDM is required.
Extensible Single Sign-On in a nutshell
If you are still with me, here is a short recap. In WWDC 2019 the topic was introduced as part of the "What’s New in Managing Apple Devices" session. The content was re-published as a Tech Talk Introducing Extensible Enterprise Single Sign-On and it covered:
- an overview of single sign-on
- discussed how to create extensions
- how to use such extensions in your apps and
- how to deploy themSSO extensions were introduced last year in iPadOS, iOS 13 and macOS Catalina.
There are many moving parts, but in the center of it all is the SSO extension, an app extension, and therefore runs as part of a hosting native application.
The SSO extension enables other native apps and Safari (WebKit) to provide a more seamless single sign-on experience. As previously stated an SSO extension is configured via Mobile Device Management and can provide a native UI, Web UI, or a transparent authentication experience to the user.
The reason why MDM is required
A specific payload needs to be deployed with an MDM solution.
| Payload | Operating system | Supported enrollment type | Interaction | Duplicates |
| Extensible Single Sign-On | iOS iPadOS Shared iPad user macOS device macOS user | User Device Automated Device | Exclusive | Single |
Note: Not all payloads and their respective settings are available in all MDM solutions. Consult your MDM vendor's documentation to learn which MDM payloads can be deployed.
Who is implementing an SSO extension?
Apple uses an SSO extension internally for their own single sign-on against their own identity management system. Large identity providers like Microsoft and Okta shipped SSO extensions as well.
What's the job of a person who implements such an extension?
The extension developer is responsible for completing the authentication process with the identity provider (idP).
IdP specific features can be implemented in the extension. For example, multi-factors can be requested, device-specific keys can be generated on the Secure Enclave or authentication requests can be supplemented with a trust score.
Hence you should rarely need to implement an SSO extension by yourself. Check with your IdP if such support exists.
Focus on Redirect SSO extensions
Anyway, if you have to look into SSO app extensions then you will find out that there are two types
| Type | Purpose | Orchestration |
| Redirect | intended for modern authentication OpenID Connect, OAuth, SAML | Request is redirected directly to extension |
| Credential | Intended for challenge/response authentication (supports custom challenges) | Request is send to respective webserver, extension will handle authorization challenge issued by web server |
I'll focus on redirect SSO extensions for the rest of my blog post.
Safari or native apps will trigger the app extension to redirect specific URLs. Those URLs are part of the payload pushed from the MDM solution to the device.
For security reasons it would be catastrophic if Apple would redirect any traffic to arbitrary extensions. That's why Associated Domains are needed.
Associated domains are required to prove that you or your identity providers own the traffic that is being redirected.
The web server with those endpoints needs an apple-app-site-association file and signature and Associated Domains need to match.
So the SSO app extension requires
- Associated Domains capability
- Entitlement
com.apple.developer.associated-domains.mdm-managed
The list of associated domains can be bundled as part of the SSO extension or the list can be passed through MDM.
| Entities in MDM | Content | Required ? |
| Payload | Type: Redirect Extension Bundle Identifier Team Identifier URLs to redirect ... | Yes |
| Managed App Config | can contain associated domains (as an alternative to declare them in the extension) | No |
Implementation
The Authentication Services framework has the required APIs, especially ASAuthorizationProviderExtensionAuthorizationRequestHandler
Joel Rennich, as part of his MacDevOpsYVR20 presentation, shared an example of a working SSO Extension for macOS.
Further info
Here is the presentation of Joel Rennich at MacDevOpsYVR20. Top-notch!
Right when Extensible Single Sign-On came out, he gave an equally great presentation on SSO extension at MacSysAdmin 2019. Here is the video as well as the corresponding slides.
If you worked on an SSO app extension I would like to hear more about it. Reach out to me on Twitter with @MarcoEidinger.