Lipika Gupta

Single sign on solutions in Mobile for Native Applications

What is single sign-on (SSO)?

Single sign-on (SSO) is an authentication process that allows a user to access multiple applications with a single set of credentials which means that the user will have a single federated identity for all applications. It eliminates the need for users to remember and manage credentials for different applications.

single sign on

Before starting the blog, there are a few terms you should be familiar with.

AD – Active Directory is a directory service developed by Microsoft for Windows domain networks.

LDAP – Lightweight Directory Access Protocol is an open, vendor-neutral industry standard application protocol used for accessing and maintaining the distributed directory information services over an Internet Protocol (IP) network.

SAML – Security Assertion Markup Language is an XML-based, open standard data exchange format for exchanging authentication and authorization data between two parties (an identity provider and a service provider).

JWT – JSON Web Tokens is a JSON based open industry standard method for representing claims securely between two parties. It is used to generate access tokens that assert some claims.

MFA – Multi-factor authentication is a method of computer access control in which a user is granted access only after successfully completing multiple levels of authentication. It’s a security system requiring more than one method of authentication from independent categories of credentials to allow the user to login.

OAuth – OAuth is an open standard for authorization, which is commonly used as a way for users to authorize applications to access their information on other applications without giving them their passwords.

OpenID – OpenID extends the features of OAuth 2.0 protocol by including an ID token which provides certain information regarding the identity and the authentication of that identity to the application.

SCIM – System for Cross-domain Identity Management is an open standard used to automate the exchange of user identity information between identity domains or IT systems.

WS-Security – Web Service Security is an extension of SOAP which is used for applying security to web services.

WS-Trust – Web Service Trust is an extension to Web Service Security that deals with issuing, renewing and validating security tokens. It also deals with ways to establish, assess the presence of, and broker a trust relationship between participants of a secure message exchange.

WS-Federation – Web Service Federation defines mechanisms to allow different security realms used to broker identity information, identity attributes and authentication information.

AS – OAuth Authorization Server allows a resource owner to grant authorization to a client that is requesting access to a resource that is protected by a resource server. The AS issues tokens to the client on behalf of a resource and this token is used by the client in authenticating subsequent API calls.

NAPPS – Native Applications SSO is a standard protocol for mobile devices that provides SSO with the help of a token agent thus enabling native mobile applications to authenticate users more easily.

PKCE – Proof Key for Code Exchange is a security extension to OAuth 2.0 for public clients on mobile devices that is designed to prevent interception of the authorization code by any malicious application on the same device.

Achieving single sign on a native mobile application is very challenging as there is no defined standard or a given best practice that would make it easy for a developer to decide which SSO solution to go with while trying to achieve single sign-on for native applications.

Most mobile applications do not support Security Assertion Markup Language for SSO, because of which the user has to manually enter the application password which can be a challenge on mobile devices as the keyboard size is small. Also, for the applications that do support Security Assertion Markup Language for SSO, the authentication experience is poor and as the sessions are not frequently revalidated, it weakens the security. Also making users re-enter password degrades the usability of the application.

The industry is looking to solve this problem with the introduction of Native Applications SSO. The user experience and security challenges are addressed with a mobile identity and authentication infrastructure that is tied to native mobile applications.

OAuth 2.0 has emerged as an important, standardized protocol for enabling this very pattern of native applications authentication and authorization.

The default pattern for OAuth is to deal with each native application individually, i.e. they are individually authorized and receive the OAuth tokens required to make subsequent API calls.

The standard flow for this is to open the browser to an OAuth (Authorization Server) and authenticate to the OAuth Authorization Server in this browser. There might be cases, in which users might be asked to give consent to the native application to make API calls on their behalf.
This authentication and authorization results in the issuance of an access token down to the native application. This token is saved by the native application and is then used to authenticate any subsequent API calls.

Using Native Applications SSO, the tokens for various native applications are managed by a single application that acts as a token agent.

We will be understanding Native Applications SSO in more detail, later in this blog.

There are quite a few solutions available in the market that can be used to achieve single sign-on depending on your application’s requirement. Here in this blog, I will be highlighting some of the solutions I came across.

1. Bitium

Bitium provides a secure, flexible and easy-to-use identity solution that allows organizations to federate employee identity across cloud and web-based applications. It can also be integrated with an organization’s internal web-based applications.

It allows an organization to use leading, standard-based authentication methods such as Security Assertion Markup Language, OpenID Connect and JSON Web Tokens. The user authentication can be further secured using standards like Security Assertion Markup Language and Multi-Factor Authentication.

It supports the user directory to be integrated using Active Directory, Google Apps, HR management system, Lightweight Directory Access Protocol.

The users in Bitium can be provisioned based on different roles and groups.

Also, an access to an application can be restricted by IP addresses as well, i.e. if an application can only be accessible from the organization’s premises, then the IP address of the organization can be whitelisted. When a user tries to access this application from any other IP address, access to the application would be denied.

It also supports the use of a Bitium Vault which can be used by the organization to store certain confidential information.

2. Centrify

Centrify provides single sign-on for cloud and mobile applications. It lets you deploy browser-based apps, native mobile apps as well as custom apps, all using a single username and password, controlled by IT, and using leading industry standards such as Security Assertion Markup Language and OpenID. It also enforces security by implementing policies per application and using Multi-Factor Authentication to access them.

It allows you to maintain your Active Directory, Lightweight Directory Access Protocol, or Google Directory as the source of data for authentication. It also lets you use the Centrify cloud directory for contractors.

It allows you to control access to the cloud and mobile applications and also lets you manage the devices that can access these applications. This can be done by creating user access policies.

It allows social login from Facebook, Google, LinkedIn, and Microsoft for customers giving them a consistent login experience throughout your brand.

Using Centrify, you can give access to only certain resources to your partners thus securing other data. It also lets your partners manage their own identities.

3. Ping Identity

Ping Identity provides a comprehensive federated identity management and flexible SSO solutions allowing you to manage all identities and enforce policies from any directory thus avoiding duplicating user directories. It lets you establish a secure single-click access between identity and service providers. It also provides additional security using Multi-Factor Authentication and protects web applications and APIs with identity standards.

It supports Security Assertion Markup Language, OpenID Connect, OAuth 2.0, Web Service Federation and Web Service Trust for SSO. It uses Security Assertion Markup Language, OpenID and System for Cross-domain Identity Management to securely transmit user access and provisioning information. It uses OAuth and OpenID Connect to safeguard web, mobile and API’s. It recommends the use of Chrome Custom Tabs (Android) and SFSafariViewController (iOS) for SSO which allows the user browser session to be shared across applications.

The diagram below shows the OpenID Connect flow for a mobile application-

OpenID Connect flow for a mobile application
Image credits-https://developer.pingidentity.com/en/resources/napps-native-app-sso.html

 

Now, we will be seeing how Ping Identity proposes the use of Native Applications SSO.

The diagram below represents how OAuth works when there are two separate native applications installed on the device, each of which has a corresponding server endpoint, behind which sits the business data. Both applications will obtain tokens from the Authorization Server and use them to make API calls to their corresponding endpoints.

how OAuth works
Image Credits- http://pingidentity.com/

 

Now, let’s see how the Native Applications SSO model works. The Native Applications SSO model introduces a token agent (TA), which is any application on the device that manages the OAuth tokens for the native applications. It removes the burden of directly interacting with an Authorization Server to obtain the OAuth token required to make API calls from the individual applications.

Rather than individually authenticating and authorizing each native application as shown in the previous diagram, the application only goes through the process of authenticating and authorizing to the TA. Once the TA has been authenticated and authorized and has been issued tokens, it’s able to use its own primary token to obtain secondary access tokens for the native applications. Once the native applications receive the secondary access token from the TA, it can use this token to make API calls.

This scenario can be seen in the following diagrams. The diagram below shows how the TA obtains the primary token from the Authorization Server-

TA obtains the primary token from the Authorization Server
Image Credits- http://pingidentity.com/

 

The diagram below shows how TA facilitates SSO to the native mobile application.

TA facilitates SSO to the native mobile application
Image Credits- http://pingidentity.com/

 

The diagram below shows how the TA facilitates SSO to a third-party native application.

TA facilitates SSO to a third-party native application
Image Credits- http://pingidentity.com/

 

4. OneLogin

OneLogin provides one secure SSO portal for all applications. With it’s SSO portal, the user has to enter just one set of credentials to access all the applications. It’s policy driven password security and Multi-Factor Authentication ensure that sensitive data is accessible to only authorized users. It enforces security using Security Assertion Markup Language and Multi-Factor Authentication. Also, it comes pre-integrated with Duo Security, RSA SecurID and many others.

It allows you to synchronize users with any number of directories, such as Active Directory, Lightweight Directory Access Protocol, Workday, or Google Apps. It also supports the use of custom attributes for users and lets you import custom user attributes from the directory as well. The directory synchronization takes place in real time.

It supports creating multiple logins for the same type of application and gives you access to these multiple accounts with just one click.

It also lets you sign into OneLogin using your Facebook, Google+, LinkedIn and Twitter credentials. This eliminates the need to create an explicit OneLogin password. This feature is useful for external applications used by your customers.

Apart from supporting just the enterprise applications, you can also configure applications for your personal use. To provide a better user experience, it supports up to 21 languages.

It maintains records of all user activities and events which enables you to easily analyze statistics and reports.
Its services can be accessed from any device, anywhere. It also provides a free OTP service that can be used in conjunction with Multi-Factor Authentication.
Using OneLogin, you can quickly onboard or provision new accounts. Also, it provides an effective kill switch to deprovision or off-board accounts that are no longer required, thus preventing the use of secure data by unauthorized personnel.

OneLogin provides API’s for integration that lets you implement SSO in your native mobile application.

The diagram below shows the SSO flow without Multi-Factor Authentication.

SSO flow without Multi-Factor Authentication
Image Credits- http://pingidentity.com/

 

The diagram below shows the SSO flow with Multi-Factor Authentication.

SSO flow with Multi-Factor Authentication
Image Credits- http://pingidentity.com/

 

5. App Auth

AppAuth for Android is a client SDK, supporting Android API 16 (Jellybean) and above, that is used to communicate with OAuth 2.0 and OpenID Connect providers. It strives to directly map the requests and responses of those specifications. Apart from mapping raw protocol flows, it also provides convenience methods to assist with common tasks such as performing an action with fresh tokens.

The library follows the best practices used in OAuth 2.0 for Native Apps which includes using Custom Tabs for the authorization request. For this reason, due to usability and security reasons, the Android WebView is explicitly not supported. Custom Tabs are used for authorization requests when a Custom Tabs implementation is provided by a browser on the device (for example by Chrome). If not, then the default browser is used as a fallback.

The library also supports the Proof Key for Code Exchange extension to OAuth which was created to secure authorization codes in public clients when using custom URI scheme redirects. The library is also friendly to other extensions (standard or otherwise) having the ability to handle additional parameters in all protocol requests and responses.

It works with any Authorization Server supporting native applications, either through custom URI scheme redirects (all supported versions of Android), or App Links (API 23+).

I hope this blog helps you in evaluating the different SSO solutions available and help you decide which solution best suits your needs.

Thank you for reading. 🙂

 

Related Articles

#Tech

NHibernate, Linq and Lazy Collections

For the past few months we have been busy building a services framework for one of our clients so that they can build all of their enterprise web services without ever having to worry about the cross cutting concerns and... Read more
#Tech

Page Redirects using Spring.NET

Who is responsible for page redirects in ASPNET MVP – The View or the Presenter None of the above, it is you :) On a serious note, it is the View as one shouldn’t pollute the Presenter with the page navigation... Read more