Over the past few years, Single Sign-On (SSO) has really become a buzzword in both the consumer and enterprise spaces. This is partly driven due to consumerization of enterprise software, as well as rapid mobile adoption across enterprises. Several standards have also emerged to address these needs as well. In this article, let’s take a look at:
- What SSO means and popular standards available today
- How Software Vendors are adding support for SSO in native applications
- Pros and cons for this approach and finally
- What an ideal solution which can offer SSO across all native mobile applications would be like?
What is SSO and the popular standards:
SSO means ability to log into an application (SaaS or native mobile application) every time using one single/federated identity. This identity can either be your Social Identity i.e., Facebook/Twitter/Google or Enterprise Identity (often Active Directory ID). With this approach, end users are relieved of having to remember complex password for each app, or worse, use easily-remembered weak or common passwords. It also increases both user productivity and corporate application security.
With that, let’s move towards standards. The one which is popular in the enterprise space is SAML 2.0 and OAuth 2.0/OpenID 2.0 in consumer space. If you are not familiar with any of these standards, you might want to read about them on Wikipedia. Additionally, for SAML, you can read the blog article by our CTO: What is SAML? For the rest of this blog, I’ll discuss SAML 2.0 because of the enterprise focus. Before moving further, let’s take a look at typical SAML flow:
As you can see, there are many redirects between the Service Provider (SP), Identity Provider (IdP) and User Agent(typically a browser). The reason for this is because when SAML 2.0 was built, it was built with the assumption of the client being a web browser from desktops/laptops. Unfortunately because of this presumption it doesn’t adapt well into the mobile application ecosystem. So in order to add support for SAML 2.0 into mobile applications, app developers are taking approaches which are not very elegant from end user perspective. Let’s take a look.
How Enterprise Software Vendors are adding support for SSO in native applications:
The mobile applications are a mix of applications developed using native platform language and hybrids which is mix of HTML5 & native language. In the case of HTML5 apps, implementing SAML flow is easier but with native development – it is difficult. App developers, embed web view into the login UIs. A typical flow would be:
- User launches mobile app
- App displays a link “Are you a Single Sign-On User?”
- User click on it and is required to enter email address/domain/company wide pin code
- App connects to its own backend service, to determine which IdP to redirect to
- Web view is presented and IdP login screen is rendered in there
- User is required again to enter their company user credentials
- IdP authenticates the user, generates SAML assertion and hands it back to application
There can be a better flow than that – don’t you agree?
Pros and Cons for the above approach:
Pros include that the application vendor can claim support for SAML SSO, and IT organization can control and shut off access to applications from an identity store. Cons wise, this approach can be very taxing for the end-user. As webviews do not have cookie space, every time an application is killed or the SAML cookie expires, the user will have to go through the above flow. Just to put this into perspective, on a day-to-day basis, we use five or six enterprise applications – having to go through this login flow every time leads to a very poor end-user experience.
Ideal Solution/Authentication Nirvana:
For a second, let’s conceptualize this scenario. The user launches an app and they are taken right into it without the need for entering any credentials. This can only be possible, if there was a native application provided by an identity provider which can fetch the SAML token from IdP as long as you are logged into the IdP’s native application. The mobile application can interact with IdP’s native application via SDKs.
The icing on the cake would be if this native application provided by IdP can be token (SAML or oAuth or OpenID Connect) agnostic as well as IdP agnostic. If you are app developer and looking to add SAML support, think twice before taking the webview approach and focus on providing best user experience.
In my next blog article, I will discuss about how Centrify SDKs addresses SSO across native mobile applications. If you can’t wait until then, feel free to head out to http://developers.centrify.com for an early start.