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.

  • Using NAPPS

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

  • 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.

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

  • 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.




    Type of View


    System Browser

    Safari, chrome

    Custom Chrome tab

    Web View Component

    WKWebView or android webview

    IOS safari view controller


    Authentication Session sharing




    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 x509




    Developer has to handle it


    Application control on view


    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 Experience

    Not Great

    User is bounced over to browser and application

    Seamless and Rich

    Seamless and Rich

    Seamless 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.


    • https;//—cms-24260



    How To-Best Practice
    Comment List