Single Sign-on security
iOS, iPadOS, macOS and visionOS support authentication to enterprise networks through Single Sign-on (SSO). SSO works with an identity provider (IdP) to authenticate users to services they are authorized to access. SSO can be used for a range of network activities, from secure Safari sessions to third-party apps.
iOS, iPadOS, macOS, and visionOS include a built-in Kerberos SSO extension. App developers can also provide their own Single Sign-on implementations using SSO extensions.
Kerberos Single Sign-on
iOS, iPadOS, macOS, and visionOS support authentication to enterprise networks using Kerberos. SSO support is based on the open source Heimdal project and uses SPNEGO tokens and the HTTP Negotiate protocol to work with Kerberos-based authentication gateways and Windows Integrated Authentication systems that support Kerberos tickets. Certificate-based authentication such as PKINIT is also supported.
The Kerberos SSO extension supports the following encryption types:
AES-128-CTS-HMAC-SHA1-96
AES-256-CTS-HMAC-SHA1-96
iOS, iPadOS, and visionOS provide flexible support for SSO to any app that uses the class NSURLSession or URLSession to manage network connections and authentication. Apple provides all developers with these classes to seamlessly integrate network connections within their apps.
Any Mac app that supports Kerberos authentication works with SSO. This includes many of the apps built into macOS, such as Calendar, Mail, and Safari, and includes services like file sharing, screen sharing, and secure shell (SSH). Many third-party apps also support Kerberos.
To configure SSO, a configuration allows a device management service to push the necessary settings to the device. This includes setting the user principal name (the Active Directory user account) and Kerberos realm settings, as well as configuring which apps and Safari web URLs should be allowed to use SSO.
Extensible Single Sign-on
App developers can provide their own Single Sign-on implementation using SSO extensions for iOS, iPadOS, macOS, and visionOS. SSO extensions are invoked when a native or web app needs to use an IdP for user authentication. Developers can provide two types of extensions:
Redirect extensions, which redirect to HTTPS
Challenge/response extensions, such as Kerberos
This allows Open ID Connect (OIDC), OAuth, SAML 2.0, and Kerberos authentication schemes to be supported by extensible Single Sign-on. SSO extensions may also support authentication at the FileVault and Login Window on macOS by adopting Platform SSO, which allows the Mac to retrieve SSO tokens during login.
To use a Single Sign-on extension, an app can either use the AuthenticationServices API or can rely on the URL interception mechanism offered by the operating system. WebKit and CFNetwork provide an interception layer that permits seamless support of Single Sign-on for any native or WebKit app. For a Single Sign-on extension to be invoked, a configuration must be installed through a device management service. In addition, redirect type extensions must use Associated Domains to prove that the IdP they support is aware of their existence.
Platform Single Sign-on
With Platform Single Sign-on (Platform SSO), developers can build SSO extensions for macOS that extend to the macOS FileVault and Login Window. Platform SSO supports different authentication mechanisms with an IdP:
Password
Password authentication supports WS-Trust. This allows a user to authenticate even when the IdP managing their account is federated.
Optionally, users can also synchronize their local account credentials with an IdP. The local account password is automatically kept in sync with the password of their IdP account.
Secure Enclave Key
A key is created and stored in the Secure Enclave during the user registration process and used to authenticate with the IdP without a password.
Smart card
A smart card is used to authenticate with the IdP.
Access Key
A pass stored in Apple Wallet is used to authenticate with the IdP.
Registration
To use Platform SSO, the Mac and each user register with the IdP. Depending on IdP support and the applied configuration, the Mac can perform device registration silently in the background using:
A registration token provided in the device management configuration.
An attestation, which provides a strong assurance about device identifiers (UDID and serial number).
After a successful device registration, the user registers (unless the user account is using Authenticated Guest Mode). If the IdP requires it, user registration can involve prompting the user to confirm their registration. For local user accounts that Platform SSO creates on demand, user registration happens automatically in the background.
During the registration process, the Mac creates two keys: a device signing key, and a device encryption key. Depending on the SSO extension, the keys can use the following:
NIST P-256 ECDH-ES
HKPE with NIST P-256, NIST P-384, or X25519
These maintain a trusted connection with the IdP independent of the user, Platform SSO supports shared device keys. This enables features like Platform SSO during Automated Device Enrollment, on-demand creation of user accounts based on information from the IdP, network authorization, and Authenticated Guest Mode and uses the same signing and encryption key for all users on a specific device.
Note: The SSO extension needs to support the requested method to perform the registration. Switching methods is also supported. For example, when creating a new user account with a user name and password during login, that account can then switch to use a Secure Enclave-backed key or smart card after the login is successful.
Token retrieval and refresh
To authenticate the user to their apps and websites as needed, the SSO extension uses SSO tokens. To help ensure the SSO extension is always ready to perform an authentication, Platform SSO attempts to refresh or retrieve new tokens from the IdP if the tokens are:
Missing
Expired
More than four hours old
To request or renew tokens from the IdP, a JSON Web Token (JWT) login or refresh request is sent and—depending on the method defined by the SSO extension—signed with the device signing key using ES256, ES384, or Ed25519. The created tokens are part of the response payload which is AES-GCM 256 encrypted using the public key of the device encryption key.
If password encryption is requested by the SSO extension, the password isn’t sent in the login request and replaced by an AES-GCM 256 encrypted embedded assertion containing the password. The associated encryption key is then created (as defined by the SSO extension using one of the mechanisms also available for the device encryption key).
When the authentication mechanism requires a digital signature, Platform SSO uses an embedded JWT assertion for Secure Enclave Key and smart card authentication. The assertion is either:
Signed with the authenticator when using a smart card.
Encrypted using ES256, ES384, or Ed25519 when using a Secure Enclave Key as defined by the SSO extension.
Regardless of the authentication method, SSO tokens are:
Stored in the keychain using the keychain data protection attribute
kSecAttrAccessibleAfterFirstUnlockThisDeviceOnlyShared only with the SSO extension
Nonmigratory