How to Use Enterprise Authentication (SSO) in Mobile Apps

Single Sign-On (SSO) is an authentication method that allows a user to sign in to multiple applications with a single login credential.

This Knowledge Base article provides step-by-step instructions for how to use Enterprise Authentication (SSO) in Mobile apps using Appdome. We hope you find this knowledge base useful and enjoy using Appdome!

How to Use Enterprise Authentication (SSO) in Mobile Apps

Appdome is a no-code mobile app security platform designed to add security features in mobile apps.

Appdome’s no-code mobile app security platform offers mobile developers, DevSec and security professionals a convenient and reliable way to protect Android and iOS apps without coding. When a user clicks “Build My App,” Appdome leverages a microservice architecture filled with 1000s of security plugins, and an adaptive code generation engine that matches the correct required plugins to the development environment, frameworks, and methods in each app.

Using Appdome, there are no development or coding prerequisites to build secured apps. There is no SDK and no library to manually code or implement in the app. The Appdome technology adds the relevant standards, frameworks, stores, and logic to the app automatically, with no manual development work at all.

Likewise, there are no required infrastructure changes and no dependency on SAML, OAuth, OpenID Connect or any other authentication standard inside the app. The Appdome technology adds any 3rd SSO service and relevant standards, frameworks and more to the app automatically, with no manual development work at all. Using Appdome, mobile apps will use the SSO service you selected to authenticate users as if the SSO service was natively coded to the app.

Key Definitions to Know Before Getting Started With Appdome for SSO

A protected resource is any network resource that requires a mean of authentication in order to gain access. An app may try to access multiple resources which are governed by different authentication providers. To ensure seamless access, the SSO configuration allows to create a profile for each authentication provider profile and associate the protected resources it governs.

Once the app tries to access a protected resource, Appdome Single Sign-On will verify that the application is authorized. The application’s requests are considered unauthorized if the HTTP status code in the response from the protected resource differs from 200 (the standard HTTP code for success). If the request is unauthorized until the authentication process has completed all subsequent calls to the protected resource by the application will be stopped. This course of action maintains a good user experience since not all applications are equipped to handle unauthorized responses from protected resources (such as HTTP status code 401).

When the authentication process initiates, a browser will launch automatically navigating to Hub URL. The user will be asked to enter credentials and upon successful authentication, the authentication provider will redirect the user to a predefined Authentication Successful URI. At this point, the authentication provider will supply a token that will be used later to access the protected resource. The token’s format may vary between authentication providers and methods, such as HTTP cookies, OpenID or proprietary formats.

Appdome’s Session Management will add the authentication result, proof that the user is authorized to access the resource, to the application’s requests when needed to ensure that all requests are authenticated and able to access the protected resource. In addition, any event of authentication token or cookies expiration, Appdome Single Sign-On will kick into action to either extend the token expiration if possible or initiate the authentication browser again.

Prerequisites for Using Appdome for SSO

In order to use Appdome’s no code implementation of SSO on Appdome, you’ll need:

• Appdome account
• Mobile App (.ipa for iOS, or .apk or .aab for Android)
• The Hub URL for the SSO Service
• The Authentication Successful URI for the SSO Service
• The Triggering URI for the SSO Service
• Any Other SSO Service-specific information (see below)
• Signing Credentials (e.g., signing certificates and provisioning profile)

The Easy Steps to Use Enterprise Authentication (SSO) in Mobile Apps

Follow these step-by-step instructions to add SSO to Any Mobile App:

Upload a Mobile App to Your Account

Please follow these steps to add a mobile app to your Appdome account.
If you don’t have an Appdome account, click here to create an account.

From the “Build” tab, Enable Appdome for Single Sign-On

Select the Build Tab. Note: a blue underline will appear showing the step is active
Beneath the Build Tab, you will find several service options. Select Identity. Note: a blue highlight will appear showing the category is active. 

• Click on the toggle to enable Mobile Enterprise Authentication
• Choose an authentication provider from the list of predefined Cloud Identity authentication schemes or Authentication Profiles under Appdome for Single Sign-On

• You can add multiple profiles configuring different authentication methods to different sets of resources. To learn more about Multiple Authentication Profiles, please refer to this knowledge base article.
• Configure the SSO service parameters:
• Hub URL: The URL to the authentication provider for the protected resource
  • For OpenID authentication, enter the service Authorization Endpoint
  • Otherwise, enter the SSO service authentication portal URL
• Authentication Successful URI: The URI that indicates that authentication is complete
  • For OpenID authentication, this URI should be configured as one of the valid redirect URIs in the application profile.
  • Otherwise, enter the return URI that the user will be redirected to, from the authentication portal, at the end of the authentication process.
• Protected Resource: Add the list of URLs that needs authentication to be accessed (commonly, the URL for the service the app accesses). Appdome for Single Sign-On will kick into action only when a protected resource is not accessible due to unauthorized requests. You can add multiple URLs and the URLs support * as a wildcard.
• OpenID Authentication: When toggling on OpenID authentication, the following fields will be revealed:
  • Client ID: This is used to identify the application trying to authenticate against the SSO vendor’s service. This value is generated by the authentication party after creating an application profile.
  • Token URL: The URL for the token request can be configured in case it was overridden (this will appear in the Token Endpoint field in the application configuration) or doesn’t comply with the following format https://my.hub.com/oauth/token. Otherwise, Appdome for Single Sign-On will set the correct URL according to the authentication party.
  • Client Secret: If the client in the service uses a secret/key, enter it here.
  • Scopes: This states the different services that the application will request access to with the token returned from the authentication process. The value supplied in this field should be a subset of the scopes configured in the application configuration in the authentication provider. If this value is omitted the default setting will be set according to the chosen authentication party.
• Configure Advanced Features: several advanced features are available for finer control of irregular scenarios:
• Header Manipulation:
  • Add Request Headers: A list of header names and values to be added to any outgoing request from the app if the header name doesn’t already exist.
  • Remove Request Headers: An outgoing request header matching any of the header names in this list will be removed before being sent to the server.
  • Override Request Headers: A list of header names and values to be added to any outgoing request from the app. Existing values will be overridden.
  • Add Response Headers: A list of header names and values to be added to any incoming response from the server if the header name doesn’t already exist.
  • Remove Response Headers: An incoming response header matching any of the header names in this list will be removed before reaching the app.
  • Override Response Headers: A list of header names and values to be added to any incoming response from the server. Existing values will be overridden.
• Cookies Groups: A list of domains (allowing the use of the * wildcard) which will be sharing cookies. Any cookies set by the server for domains in the list will be saved regardless of the app’s logic. All cookies saved for the group will be added to outgoing requests matching any of these domains.
• Logout URLs: A list of URLs (allowing use of the * wildcard) that when accessed by the app will cause all saved cookies to be cleared.
• Auto Persist Credentials (iOS only): Persist credentials between sessions for applicable authentication schemes such as NTLM, without the use of cookies or access tokens.
• Reload App Webview (iOS only): Automatically reload the app’s webview after an authentication success to access the desired resource.
• Reauthenticate On Redirect: When enabled, even if the user authenticated himself before, he will be prompted to enter his credentials again on a redirect from a protected resource URL.
• Handle WebView Challenges (Android only): Prompt the user for credentials directly from the app’s webview instead of creating a new authentication-only webview. Only applicable for apps in which a webview accesses the protected resource URLs.

The following KB articles include the details on how to add SSO to any mobile app per identity provider:

• Mobile Enterprise Authentication by Appdome
• OKTA Identity Cloud
• Azure Identity Cloud
• Microsoft Active Directory Authentication Library (ADAL)
• Ping Identity Cloud
• F5 Access Policy Manager

Appdome SSO+ Suite

Once you add Mobile SSO to your iOS or Android app, this set of unique features enables you to further manage and control SSO behavior for the Built app.

1. Session Management (always on): Seamlessly manages and adds authentication cookies and/or tokens to the application’s request to protected resources to ensure successful access.
2. In-App Private ID: Encrypts cached ID information saved locally on the device to protect cookies, credentials and authentication information.
3. Cross-app ID: Enables an enhanced app to share the authentication session with other Built apps. Once an app completes authentication, all other Built apps will be able to access the same protected resource without going through the authentication process.  You can control the scope of the shared ID: Sharing between all the apps Built by the account, or only the apps Built with a specific Fusion Set.
   1. For OpenID, in order to share authentication between enhanced applications, the combination of the protected resource, Hub URL and client ID must be identical
   2. Otherwise, when OpenID is not toggled, only the protected resource and Hub URL need to be identical
4. Conditional Access: Auto populates app initiated traffic with authentication information (cookies and header).
5. Conditional Cookies: Auto-populate authentication traffic with app information (cookies and HTTP headers).
6. Direct Broker: When this feature is toggled on, Appdome for Single Sign-On will track all domains redirected through the authentication browser and compare them to a predefined list of allowed domains. Any attempt to access an unapproved domain will stop the authentication process to ensure the integrity of private user information such as credentials and protected domains. You can specify a list of approved broker domains, to control for unauthorized redirects during authentication.

When finished, click Build My App.

Congratulations! You now have a mobile app fully integrated with Cross-App ID.

Building Custom SSO Workflows Inside Android and iOS Apps

Building Single Sign-On inside Android and iOS apps involves several significant considerations. Perhaps the most significant consideration is “where” and “when” the SSO workflow will take place inside the app. Usually, an SSO workflow is initiated at the start of a login sequence. In this use case, the client and the server are built to handle the basic authentication sequence (User –> launches app –> enters credentials –> credentials verified by the server –> user issued a token or cookie allowing access to the app).

But, what if the app developer hasn’t or doesn’t want to build the app to support basic authentication? Or, what if the app developer wants more than the username and password provided in the basic authentication workflow (e.g., access to user details available in new authentication methods)? In these cases, Appdome-Threat Events provide a framework to pass user details contained in an OpenID and SAML authentication response to the app developer. This framework allows new flexibility to create custom SSO workflows inside an app using industry-standard methods to retrieve and pass user details between authentication services and mobile apps.

Organizations use their Identity Providers (IdPs) like Azure AD, Okta, Ping, etc. These authentication services usually connect on the backend to a store of user data and use SAML or OpenID to handle authentication requests. Using SAML and OpenID, applications have access to all the user and authentication details returned by the server backend (i.e. any data the backend implements).

Read this KB article to learn how to build custom SSO workflows in your apps.

After Adding Enterprise Authentication (SSO) to Mobile Apps

Now that you know how to add SSO to any mobile app on Appdome, there are a few additional steps needed to complete your mobile integration project.