How to do SSO into your Mobile Applications

How to do SSO into your Mobile Applications


This cool solution provides information for various methods used in the mobile application development world. This is all about how the application will authenticate the user and how this information is shared with other applications without compromising credentials.

Using a Web View

Web view is used to manipulate web content by mobile native application developers. Using a web view is the most common solution to SSO on Mobile. The application renders the SSO login page and handles authentication similar to browser based authentication experience. In case of OAuth2 or OpenID connect, web view handles authentication and hands over the Authorization token to the application. The application will make a direct connection to IDP and get the Oauth2 token and additional tokens in exchange of the Authorization token.


  • User experience is better because authentication happens within the application.

  • User authentication session belongs to the application and not shared across applications.


  • Rendering login pages would be an issue if they are complex in nature, the application developer has to do many workarounds to overcome the issues of rendering and JavaScript actions.

  • Web views don’t use regular cookie storage and the user is forced to authenticate every time the app is accessed.

  • User authenticated session is not shared with other applications, without doing a workaround like writing shared key to shared storage location, for example, keychain in IOS.

  • Cert based authentication, HTTP Basic, Kerberos authentication, are not supported with web view, the developer has to handle authentication types.

Using a System Browser

Some mobile applications use system browser to handle the login process. Native application launches system browser with the login url, the browser completes the authentication process and on successful authentication, redirect URI sent from server will open the application to hand over the authorization token. After receiving the Authorization token, the application contacts the server for Oauth2 token and refresh token etc., in exchange of Authorization token with OAuth2 provider.


  • This solves the web view short comings, like handling complex login pages.

  • Cookies stored to browser storage, this allows to share across applications, whatever application invokes system browser for authentication.

  • Cert based authentication, HTTP Basic, Kerberos authentication etc., are handled by system browser.


  • User experience won’t be good because of flashing application popups like browser and application.

  • Login failures are not communicated back to the application.

  • Authenticated session stays with the browser, unless an explicit logout call is made in the browser.

  • Custom URI can’t guarantee it represents the right application. Hence there might be a chance the authorization code might be handed over to the wrong application.

Various other Approaches

  1. Sharing access tokens between applications using the system keychain.

    1. This mechanism only works with all applications which are signed by the same developer.

    2. This mechanism won’t work with SaaS or third party applications.

  2. Using NAPPS

    1. Token agent has to be installed on mobile to broker the authentication on behalf of the application.

    2. Application metadata has to be generated as part of authorization between token agent and application. This metadata information is used to decide which application can be served with agent.

    3. All Third party or SaaS applications may not be designed to work with token agent.

  3. New mobile OS in-built features

    1. Android OS offers custom chrome tab, gives more control over the web experience and make transitions between native and web content more seamless without having to resort to Web View.

      1. Some features of custom chrome tab: Simple to implement, UI customization, Navigation awareness, security, Performance optimization, Shared cookie jar, quickly return to app with a single tap, synchronized autocomplete across devices for better from completion.

      2. Provides call back mechanism to application upon external navigation.

    2. IOS 9.0+ offers SFSafariViewController, it includes Safari features.

      1. Some of the features available with controller: Reader, AutoFill, security, shared cookies with safari.

      2. Provides call back mechanism to application.

    3. IOS 9.0+ also offers WKWebView. This provides alternate to web view of older IOS OS,

      1. It has performance booster and rendering of complex pages made easy.

      2. This control provides application to control the view.



Type of View


System Browser

Safari, chrome
Custom Chrome tabWeb View Component

WKWebView or android webview
IOS safari view controller

Authentication Session sharingYES


Cookies are shared between system browser and controller

This is specific to application

Cookies are shared between system browser and controller
Browser based authentication like x509YESYESNO

Developer has to handle it
Application control on viewNO

Only on launch URL can be provided

Only initializing parameters can be passed

Application can manage this controller

Only initializing parameters can be passed
User ExperienceNot Great

User is bounced over to browser and application
Seamless and RichSeamless and RichSeamless and Rich


When the authentication session is shared between view controller and system browser, third party or SaaS applications might achieve SSO with no user credentials, if the application uses the same type of view controller that is used for authentication.

Refresh session can be done using controller running in hidden mode or background mode. It is the application responsibility to refresh session.

Note: This information is more in an abstract manner, the development team might face more challenges in employing SSO into an application, which is out of the scope of this cool solution.


Labels (1)


Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Top Contributors
Version history
Revision #:
3 of 3
Last update:
‎2020-01-31 22:05
Updated by:
Micro Focus Contributor
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.