In a previous blog I provided a brief intro to Appdome for SSO+, which enables enterprises to add SSO to any mobile app - instantly, without coding. In this blog, I'll zero in on the unique security features of the service which make it even more of a no-brainer to use Appdome to add SSO to all your mobile apps.
'Security is not optional' in SSO
SSO is a foundational element of enterprise mobility. Single sign-on is all about providing simple and secure access to enterprise apps by enabling end-users to use one set of credentials to access all apps. Adding SSO to mobile apps in a secure manner without destroying the user-experience is hard, to say the least. Yet it must be done (if you want your end-users to actually use your mobile apps).
Whether you're talking about Centrify's "Zero Trust" philosophy 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). Manually adding security to a mobile app is hard enough. Try adding security combined with SSO, and making everything work seamlessly is even harder.
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, OIDC, and other modern authentication standards are necessary elements in achieving mobile SSO in the enterprise. Yet they are not ‘prescriptive’ in nature. In other words, the standards don't tell developers how certain components are to 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 or 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.
Standards don't equal security
Another fundamental issue is handling the credential data after authentication. In mobile, it's a common practice to cache identity elements inside the app to improve the user experience. The practice is not necessarily a bad thing, unless you don't implement these features securely. Failing to provide security for cached data leads to very bad things happening. Here's why: most mobile apps have many 3rd party SDKs, libraries, or plug-ins (the average # of SDKs in a mobile app is somewhere around 18, according to data published by SafeDK). Those services may have access to stored data and other resources inside the app, via shared storage areas provided by the OS. Again, this is done to facilitate access to resources that are routinely consumed by multiple services. And if done right, you can achieve a great user experience that is also secure. But the devil is in the details of the implementation. If specific measures are not taken to protect the cached data, then any other service in the app may have unfettered access to this data.
Twitter just dealt with this recently, and as a result issued a pre-emptive disclosure just to be safe. Note that in the Twitter example, there could be downstream implications to other services the user connected to Twitter via ‘social login’.
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, adding SSO is automated and security is built into the design of that automation. In every implementation of SSO you complete on Appdome, whether for Okta or Azure AD, Ping, Auth0 or Centrify, Appdome delivers an instant and consistent implementation of the SSO service of your choice to any mobile app without coding and security by design every single time.
Here's a few of the key highlights:
- SSO Service Mediation: Appdome automatically and securely implements the underlying authentication standard or protocol required 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.
- Direct ID brokering: This optional service enables you to connect apps directly the identity provider, eliminating the use of public identity brokers.
- 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 let's you choose convenience without compromising security.
- ONEShield by Appdome: Appdome's unique app hardening secures the app, the data, and all the services inside the app. Key features include obfuscation, anti-tampering, anti-reversing, 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 the short video below to see how Appdome simplifies Okta implementations.