5 Ways to Implement SSO with Mobile Applications

Identity management solutions like single sign-on (SSO) can keep users protected on any of their mobile applications. In this blog post, I’ll explain five options to consider when implementing SSO across integrated and standalone mobile applications.

Increase Security and Ease of Access

By now, we all have encountered single sign-on at least once in our lives. But in case you haven’t, single sign-on (SSO) is an identification technology that offers users the ability to log in once, with a single set of credentials that grants them access to all applications, data, and websites that user object is configured for. This eliminates over-using passwords or having to remember multiple different ones. This will also increase identity protection as well and let you access applications in a fraction of the time.

SSO has been around for several years now. There are several standard tools, techniques, and solutions for implementing SSO in web-based systems. For instance, a solution such as Okta, provides out-of-the-box identity management and access services for nearly any platform. However, there are many other ways of implementing a single sign-on solution.

Based on our interactions with customers over the past couple of years, I noticed that there is a lot of confusion around the options available for implementing an SSO solution for mobile applications. Here we will go over a few ways that you implement SSO with integrated and standalone mobile applications.

View our Oracle Partnership
View our Okta Partnership

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.

Option 1:  

  • Enable LDAP support in JD Edwards EnterpriseOne
  • Configure the mobile application to access JD Edwards via AIS Server
  • Securely pass user credentials to AIS server, which authenticates the user against LDAP server

The following graphic illustrates this option at a very high level:

Single Sign On Mobile Applications

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.

Single Sign On Mobile Applications

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.

Single Sign On Mobile Applications

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.

Looking for more on systems modernization?

Explore more insights and expertise at smartbridge.com/modernization

There’s more to explore at Smartbridge.com!

Sign up to be notified when we publish articles, news, videos and more!