Standards-based Mobile SSO for Enterprise Apps
Appdome for SSO a is a service available on Appdome’s no-code mobile development and security platform which enables developers and non-developers to implement native standards-based single sign-on (SSO) in any iOS or Android app – instantly, without coding. The best part for developers: implementing SSO in any app is fast and easy, and it works the same way in any app – no matter which framework the developer used to build the app. On top of that, Appdome for SSO doesn’t require changes to their existing app in advance.
With Appdome you don’t need to ‘retrofit’ mobile apps to support a particular authentication standard in advance (such as OAuth2, SAML, or OpenID Connect). The Appdome platform automatically implements the right standard at build-time. This post I’ll be focusing on the security aspects of Appdome SSO. Check out my previous post if you want a primer on Appdome for SSO in general.
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 keep your enterprise mobile apps safe in an increasingly hostile environment. Finally, I’ll cover several unique features of Appdome for SSO that enable improve mobile app security instantly, AND boost usability at the same time!
Enterprise Authentication – 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 through apps, whereby a single set of credentials can be used to access all resources, and where multiple logins are minimized or eliminated through 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).
With Zero Trust security principles, there’s no question that security is a fundamental requirement in enterprise SSO (or at least it should be). 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 SAML2 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 between 3 or 4 different entities (the identity provider, the app maker, the identity broker, and the customer). Given all that complexity, 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 because we built a no-code mobile development and security platform that automates all the hard work for customers and enables anybody to build SSO into apps on demand – all without any coding. Appdome not only makes mobile SSO implementations fast and easy for to implement and use, but also “Secure by Design”. Allow me to elaborate.
In Mobile, SSO Standards are Just a Start
Because Mobile SSO is still in its early stages of evolution, 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. Far from it. Not understanding this can get you into trouble. Here are a few examples:
Standards alone (SAML2, OpenID2 Connect, OAuth) do not provide security
Standards like SAML 2.0, 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. There are also ways to bypass MFA controls by targeting apps that lack modern authentication, as covered in this recent ThreatPost article.
Another fundamental issue is handling the credential data after authentication. When building SSO into mobile apps manually, it’s a common practice to cache tokens or other credential materials 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 tokens, credential material, or other sensitive data inside the app. How?
Store and encrypt sensitive data securely at all times – without development
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.
Even 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. The bottom line, don’t rely on the standard to provide security – because it just doesn’t.
No-code Standards-based SSO in Mobile Apps – instantly
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 – secure by design – every single time, guaranteed and directly verifiable.
Here are some key ways 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 that may change or may not gain widespread adoption. Never manually implement SAML, OAuth, or OpenID Connect again!
- Direct brokering: This optional service enables you to connect apps directly to 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 Security.
- In-App Private ID: Appdome securely encrypts any mobile app credentials, cookies, tokens, 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: securely share authentication state for SSO across multiple apps, whereby a successful authentication to one app automatically enables access for all other apps in the federation.
- Appdome ONEShield: Appdome’s app hardening/ app shielding 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 & integrity validation, and more
The net result: simple, instant, native single sign-on for all mobile apps, which is securely implemented by design (minus the work, risk and complexity!)
Check out this video to see how easy it is to implement Microsoft Azure AD standards-based mobile SSO in a 3rd party app – all in less than a minute!
