SSO Options for Integrated Mobile Applications
Several mobile applications integrate with back-end enterprise systems. Simply put, these mobile applications read, write, and modify the data in the back-end enterprise system. The access to the back-end system and data is controlled by the level of access the user has to the back-end system functionality and data. The mobile application has to use the same user security model to access the back-end system.
In this scenario, the recommended approach for SSO implementation is to rely on a back-end system such as JD Edwards for user authentication. The mobile application securely passes user credentials to a Web API exposed by the back-end system, which then takes the responsibility of authenticating the user against a user repository such as Active Directory. In addition to authenticating the user, the back-end system would also authorize the user against its security model before returning role-based permissions back to the calling mobile application. The complexity of user security administration is abstracted from the mobile application in this scenario.
Here are the two most common implementation options specific to JD Edwards.
The following graphic illustrates this option at a very high level:
Option 2: Implement JD Edwards SSO using an Enterprise-wide or JD Edwards specific SSO platform
Configure the mobile application to access JD Edwards via the SSO system, which authenticates the user.
The following graphic illustrates this option. Mobile application implementation via this option is very similar to Option 1. However, the back-end server in this case depends on a dedicated identity provider for SSO implementation.
SSO Options for Standalone Mobile Applications
Not all mobile applications have a back-end enterprise system that controls user security. Several mobile applications will be responsible for implementing their own user security model. Consider, for example, a complaint reporting application of a services company that stores all complaints reported to an on-premise database without directly interfacing with an enterprise system.
For standalone applications, there are a variety of SSO implementation options available. The following 3 are the most common options:
Option 3: Custom Integration with an enterprise identity provider
If your company uses enterprise-wide identity providers (IDP) such as Okta, mobile SSO can be implemented using SAML protocol. This can be achieved by using an embedded browser (web view) within the application for implementing authentication logic.
The following graphic illustrates this option. In this case, Okta is integrated with the mobile application via SAML protocol. Once the user is successfully authenticated, the application would use an access token access the Web API on behalf of the user. In this scenario, user authorization & role permission logic must be implemented within the mobile application and/or custom Web API.
Option 4: Leverage built-in integrations with Enterprise Identity Provider
Some enterprise identity providers, such as Okta, provide a common mobile application that can be downloaded to mobile devices. The user is authenticated once by the common mobile app and then will be allowed to launch other integrated applications without additional authentication. This works well for standard mobile applications such as Salesforce that are available on app stores because they have pre-established integrations with IDPs.
Option 5: Leverage an EMM solution
Enterprise mobility management (EMM) solutions such as MobileIron, IBM MaaS360, and AirWatch secure mobile devices in multiple ways. Each EMM provider has a unique way of implementing user authentication and SSO for mobile applications as long as the EMM software is installed on the device.
This blog post is intended to familiarize readers with a few popular SSO options available for different implementation scenarios. You are not limited to these 5 options by any means. Depending on the tools and platforms available at your disposal, you can come up with a variety of other options. For example, if you have multiple standalone applications, you can use a mobile back-end service such as Oracle Mobile Cloud Services (MCS) or implement Azure’s common user authentication logic for all of your mobile applications, rather than implementing an SSO solution for each mobile application.