This article is contributed. See the original author and article here.
Hey everyone, this work comes to you from @timcappalli, who joined our Identity Standards team in March. Enjoy!
Shared devices for Firstline Workers present an interesting challenge for companies. How do workers seamlessly and securely access multiple apps and services on a device designed for a single user? Ideally, when a Firstline Worker starts their shift, they should simply grab any available device from the pool, sign in with their work credentials, and seamlessly access work resources across mobile apps and browser sessions on the device. The idea sounds great – but how can identity administrators support this kind of authentication pattern?
Today many companies use less ideal methods to provide app access to employees on shared devices. Some use a “shared PIN” and a shared username/password to allow employees easy access to business applications. This results in lack of accountability and inability to audit usage. Other businesses “sign out” employees from these devices after every transaction which results in frustration and unhappy customers.
Luckily, there are new options available: As of iOS and iPadOS version 13, Apple offers an extensible enterprise SSO capability built into the operating system. This capability makes a seamless sign in experience across apps and browser-based applications possible on iPhones and iPads. Leveraging that technology, Microsoft built a standards-based plugin called the Microsoft Enterprise SSO plug-in that can provide multi-user support on iPads and iPhones in supported applications with only one sign-in and one sign-out required per user shift. What this means is that mobile applications know when an employee signs out of the device and can clean all important information from the device preparing it for the next employee. This experience is better for workers, but also great for organizations, as it follows best practices for corporate management of data.
If you’re a mobile application developer and are interested in how the various components needed for the Microsoft Enterprise SSO plug-in interact, the rest of this blog detail the different steps and dive into the detail of how OpenID Connect (OIDC), OAuth 2.0 and SAML 2.0 play parts in one specific instance of an implementation. This blog entry is not meant to replace actual install instructions but instead to give you a high-level sense of how the plug-in works. Please refer to the online official documentation to get step-by-step instructions.
To enable this experience on an iPhone or iPad, the administrator must:
- Push the Microsoft Authenticator app to the shared device
- Push a Single Sign-on app extension profile is pushed to the device with tells iOS and iPadOS that the Authenticator app should handle all authentication requests for apps and sites that are capable.
- Set the device in to shared device mode in the MDM config file.
Any MDM can set this configuration – our examples here use Microsoft Endpoint Manager.
Setting the Shared Device Mode:
Making a preset extension type available which automatically includes all the required redirect URIs.
Once the device has the Microsoft Enterprise SSO plug-in for Apple devices installed and is in Shared Device mode, it is ready to be used by employees.
Let us dive into what happens when an app needs to acquire an access token for resource access. This would happen if an employee launched a new application to begin a new customer service request. In the sequence diagrams below, there are two different apps using the latest Microsoft Authentication Library (MSAL) accessing two different cloud backends (resource servers). The Microsoft Authenticator app contains the Microsoft Enterprise SSO plug-in for Apple devices which enables SSO across apps and browser sessions in iOS. The plug-in is invoked using a redirect extension capability that listens for certain redirects at the network level. These redirect URLs are what were defined in the MDM configuration. OpenID Connect (OIDC) and OAuth 2.0 are used for authentication and authorization. For the purposes of this example flow, a user has already logged into the Authenticator app when they checked out a device at the start of their shift.
To start, MSAL is used by the app (“App 1”) to invoke a system level authorization request (ASAuthorizationSingleSignOnRequest). Based on the MDM-defined SSO extension configuration, iOS knows to redirect requests for login.microsoftonline.com (amongst others URL variations) to the Microsoft Enterprise SSO plug-in for Apple devices for identity and token handling.
Since the Microsoft Enterprise SSO plug-in for Apple devices is acting as a token broker for the device, a primary refresh token (PRT) was granted after the user’s successful authentication at the start of their shift. The plug-in retrieves the refresh token (“rt-a”) from Keychain and initiates an OAuth 2.0 request using the refresh token grant. The “openid” scope is also included in the request to acquire a fresh ID Token.
If the request is successful, a JWT access token (“at-1”), ID Token and new refresh token (“rt-b”) are issued. The SSO Plug-In securely stores the new refresh token (“rt-b”) in Keychain and the access token (“at-1”) is returned to the app. The app can now attempt to access its cloud backend (resource server) using the newly acquired access token (“at-1”).
When the user launches “App 2”, the same process is followed again. This time, “rt-b” is exchanged for a new access token (“at-2”) for the “App 2” resource server and a new refresh token is stored (“rt-c”).
This continues until the user logs out in any application that supports Shared Device mode.
For additional details and requirements, see Microsoft Enterprise SSO plug-in for Apple devices (Preview).
Microsoft Authentication Library (MSAL): https://docs.microsoft.com/en-us/azure/active-directory/develop/msal-overview
Apple Developer: https://developer.apple.com/videos/play/tech-talks/301/
Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.