An average enterprise user accesses 6 to 8 password-protected systems every day. If users do not remember their passwords, they will often write them on sticky notes (which poses a major security risk) or call IT support to reset their password (which contributes to increased costs.) With decentralized mobile applications becoming more common, the problem is becoming worse. Single Sign-on (SSO) solves this important issue by centralizing user authentication across a wide range of applications and services. SSO has been around for several years now. There are several standard tools and techniques for implementing SSO in web-based systems. Based on our interactions with customers over the past couple of years, I noticed that there is lot of confusion around the options available for implementing a SSO solution for mobile applications.
Single Sign-on can have different meanings. There are two common interpretations of SSO:
In the case of mobile applications, it is common to implement centralized authentication.
Before we dive into the different SSO options, let us get a better understanding of the enterprise mobile application categories.
Integrated Mobile Applications
Several mobile applications integrate with back-end enterprise systems such as Oracle JD Edwards (JDE) EnterpriseOne. 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. An example of this is the JDE Work Order Management app that reads from and writes to an enterprise resource planning (ERP) system.
Standalone Mobile Applications
Not all mobile applications have a back-end enterprise system that controls the 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.
Now, let us review mobile SSO options for both these categories of mobile applications.
SSO Options for Integrated Mobile Applications
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
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, the OKTA identity provider 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 dentity 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 disposable, 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 a SSO solution for each mobile application.
As always, you can leave a comment below, contact Smartbridge, or send me an email directly if you have any questions.