Native SSO for Android and iOS Apps – Secure by Design

By |2018-10-21T16:00:55+00:00June 8th, 2018|

Native SSO for all Mobile Apps

We recently announced Appdome for SSO+, a new service available on Appdome’s no-code mobile integration platform which enables enterprises to add cloud SSO to any mobile app – instantly, without coding. We debuted 2 new partners and integrations as part of that same announcement –  Okta SSO and Microsoft Azure AD, both of which enterprises can add to any mobile app in a single click using Appdome. If you missed that announcement, you can read about it in my previous blog. 

In this blog I’ll dive a bit deeper into the security aspects of mobile SSO. In particular, I’ll bust some common myths about SSO and underlying standards like SAML & OAuth, and hopefully deliver some useful information you can apply to keeping your enterprise mobile apps safe in an increasingly hostile environment. Finally, I’ll cover several unique features of Appdome for SSO+ which will enable you to improve your security posture immediately, AND boost usability at the same time!

Enterprise Authentication which is Secure by Design

SSO is a foundational element of enterprise mobility and security. SSO is all about providing end-users simple and secure access to enterprise resources thru apps, whereby a single set of credentials can be used to access all resources, and where multiple logins are minimized or eliminated thru federation. At this point, true SSO is purely utopian. It doesn’t yet exist in the real world. Appdome is on a mission to change that.

Enabling SSO inside mobile apps in a secure manner without destroying the user-experience has proven to be much harder than it initially seemed. Yet it must be done (if you want your end-users to actually use your mobile apps).

appdome frustrated mobile app user

Whether you’re talking about the “Zero Trust” philosophy of Centrify, or Okta’s “Identity is the new perimeter” mantra, there’s no question that security is a fundamental requirement in enterprise SSO (at Appdome we agree). However, almost all implementations of SSO in  enterprise mobile apps require manual coding. And with manual coding, everything is harder than it needs to be, even when it comes to adding a single service, such as a modern authentication protocol like SAML or OpenID Connect. Now try delivering mobile security + SSO + MFA. And make it all work seamlessly within your existing enterprise infrastructure – all without completely trashing the user experience. Not to mention dealing with 12 different mobile app framework dependencies, while maintaining SAML or OIDC version compatibility among the IdP, app maker, service provider, broker or relying party. Given all that mess, it’s easy to understand why we don’t see too many large mobile SSO deployments in the Enterprise.

Well Appdome is on a mission to change those dynamics, by delivering a mobile integration platform which does all the hard work for you. Appdome not only makes mobile SSO integrations fast and easy for you, but also “Secure by Design”. Allow me to elaborate.

SSO Standards are Just a Start

Because SSO in mobile is still in the early days, the industry is still working through how to secure the SSO experience. SAML, OAuth, OpenID Connect, and other modern authentication standards are necessary elements in achieving mobile SSO in the enterprise. Yet they are not ‘prescriptive’  by nature. In other words, the standards don’t tell developers how certain components should be implemented. Most implementation and security details are left to the discretion of the implementer/developer, and there’s lots of room for interpretation and variance. Implementing SAML or OIDC inside your app does not necessarily mean that your implementation is secure. Not understanding this can get you into trouble. Here are a few examples:

SAML/OIDC don’t ensure authenticity of public brokers

Standards like SAML, OAuth and OIDC allow for the use of public identity brokers to assist in establishing trust relationships between the endpoint and the service provider via the IdP. However, ensuring the validity or authenticity of these brokers is outside the scope of the standard (ie: it’s the implementer/developer’s responsibility). Duo Security recently published some information that illustrates how SAML assertions can easily be intercepted and modified, allowing hackers to masquerade as a ‘trusted party’ in the ID brokering process. The techniques described in the Duo article leverage ordinary ‘man in the middle’ attacks mixed with a bit of old school forgery – not particularly hard to pull off.

Standards don’t equal security

Another fundamental issue is handling the credential data after authentication. In mobile, it’s a common practice to cache tokens or other credential matter inside the app to improve the user experience. The practice is not necessarily a bad thing, per se (unless you don’t implement these features securely). Failing to provide security for cached data can quickly lead to very bad things. Here’s why: most mobile apps include many 3rd party SDKs, libraries, or plug-ins. If fact, the average # of 3rd party SDKs in a typical mobile app is somewhere around 18, according to data published by SafeDK). Those services may have access token, credential material, or other sensitive data inside the app. How?

Store sensitive data securely at all times

If cookies or tokens are stored ‘in the clear’ inside the app’s shared storage, then any other service or SDK sharing the same space could have unfettered access to the data. If you’re a mobile service or identity provider, many critical security elements of the implementation outside of your control, for reasons stated earlier.  Developers or ISVs are responsible for the SAML, OAuth, or OIDC implementation, so how do you know if the implementation is secure?  You don’t. If specific measures are not taken to protect the stored or cached data, then any other service or SDK inside that app could have unfettered access to the stored data. Mobile advertising SDKs are facing scrutiny in the wake of the Facebook privacy fiasco.

social login twitterEven Twitter recently dealt with a pretty broad security breach and as a result they issued a preemptive disclosure just to be safe. Note that in the Twitter example, there could be downstream implications to many other connected services if the user connected their Twitter to 3rd party sites via social login mechanisms.

It’s not my intent to pick on any specific standard here. Standards play a crucial role in every area of development, including SSO. My intent is to simply draw attention to common misconceptions about what these standards do (and what they DON’T do). Because overlooking the nuances can have some rather dangerous implications. Bottom line, don’t rely on the standard to provide security – it doesn’t.

Why is Appdome different?

With Appdome’s mobile identity solutions, adding SSO to any app is simple, instant, automated and requires no coding. On top of that, security is built into the core fabric of Appdome’s architecture and product set. For every integration customers complete on Appdome, whether for Okta, Azure AD, Ping, Centrify or others, customers get an on-demand and consistent implementation of their SSO or enterprise authentication service of choice, into any iOS or Android app. There’s no coding, no framework, platform or development dependencies, and nobody else’s roadmap standing in the way of your own mobile integration use case. Finally, an Appdome implementation of SSO into a mobile app is  secure by design – every single time, guaranteed and directly verifiable.

Here’s a few of the key highlights of how Appdome makes mobile SSO easy and secure by design:

  • SSO Session Management: Appdome automatically and securely implements the underlying authentication standard or protocol supported by the identity provider – on demand. So you don’t need to hard-wire your app to a standard which may change or may not gain widespread adoption. Never implement SAML, OAuth, or OpenID Connect again!
  • Direct ID brokering: This optional service enables you to connect apps directly the identity provider, eliminating the need and use of public identity brokers – thus avoiding Man-in-the-middle or credential hi-jacking attacks like the one uncovered by our friends at Duo.
  • In-App Secure ID: Appdome securely encrypts any mobile app credentials, cookies, and identity data that is stored/cached in a private vault. This prevents unauthorized services from accessing sensitive data. This optional feature lets you choose convenience without compromising security.
  • Cross-App ID: Fused apps can securely share authentication state for Single Sign-On, whereby a successful authentication to one app automatically enables access for all other apps in the federation.
  • ONEShield by Appdome: Appdome’s unique app hardening solution secures the app, the data, all SDKs and any services integrated with the app – it’s automatic with every Fusion!  Key features include obfuscation, anti-tampering, anti-reversing, app structure and integrity validation, and encryption of strings and preferences.

The net result: simple, instant, native SSO for any mobile app that is secure by design (minus the work, risk and complexity!)

Check out this video to see how easy it is to connect a 3rd party mobile app to Azure AD –  for on-demand, secure, native SSO in under a minute!

About the Author:

WordPress Video Lightbox Plugin