What’s the Impact of SSO on Mobile Security and Usability?
Mobile single sign-on is a top security practice whenever it can be implemented practically for a workforce. It’s become common for enterprise applications and large field service brands, but it’s seen limited adoption in consumer-facing services.
It’s becoming slightly more popular with apps that act as a password holder, but they rely on the device storing and processing passwords and sign-ons, which can be dangerous if the device is lost or stolen. This is also limited by an authorization vs authentication concern.
Most professionals are familiar with mobile SSO on the consumer side of things when Google, Facebook or LinkedIn accounts are used as the login information for new apps. Users click on a button that says something along the lines of “Login with Facebook,” and they are then taken to an authorization service.
The interaction still requires the user to authenticate credentials, but it limits them to more memorable options, such as social media accounts. It’s a smart sort of check and a main way consumer SSO operates, because it’s simple but provides an extra layer of protection when trying to access those services or apps directly.
The downside is that acquiring credentials for the social media account puts other accounts at risk. Even worse, most social media services include a settings option that shows what third-party services are linked to that account. If the social account is compromised, each successive platform can be compromised significantly more quickly.
SSO Architecture: Security and Usability
Deploying an authorization server technology should require the use of token endpoints to look for and check OAuth tokens. Endpoints can be activated by native apps during the SSO process, allowing you to use checks at every initial session interaction.
The most important factor of Mobile SSO is planning and execution for broad support. Your system will need to support a wide range of devices and access them from across the internet and intranet. You’ll have to craft existing IT infrastructure and architecture, which typically makes this a long planning process.
Users will authenticate to the SSO gateway, and it will need the capabilities to identify, access, store and retrieve all of the credentials for users, devices and applications. This makes the process complex during planning and initial execution, but the nature of it means you typically shouldn’t do a partial rollout.
Layering Device and Personal IDs
To introduce significant security in mobile SSO, top firms are pairing the login being used with device information that is inherently transferred during each request. By tying the known ID and authentication to data related to the device itself, IT teams can prevent unauthorized access when an unknown party is able to secure one or the other.
The SSO process can provide an immediate check for both of these, reducing your exposure. It can also help to address problems associated with a user having multiple login credentials for different devices or access points.
Concerns with Multiple IDs
Potential issues may make your IT team consider avoiding mobile SSO in favor of multiple IDs per use, but that’s a more significant Pandora’s box.
SSO is beloved by many implementers because it has reduced the workload of their IT departments. They’re free from processing multiple requests — sometimes from the same person — to have IDs and passwords reset. Resources can be shifted to more important factors in your organization.
If your company is the target of hackers, you’re risking exposure with each new touchpoint or ID. The simpler the ID — such as not pairing user logins with device information — the easier it is to break in and commit corporate espionage. Social engineering and the user failing to protect their device make it easy to slip past a firewall. Pairing IDs and limiting the total number of IDs are best practices that can boost the efficacy of your automated security processes.
Choosing Mobile SSO
Selecting and implementing a mobile single sign-on process requires a variety of considerations. Companies and IT teams should consider:
- The ability to identify and authenticate device passcodes, instead of only domain passwords
- Support for one-time password platforms by guaranteeing that each temporary password is only used once
- Ability to pair your SSO with SSL VPN support, including the limitation of sign-ons to specific apps
- Existing application support, such as OAuth or SAML 2.0
- Availability on consumer, enterprise and native access styles
- Speed of the SSO to not only maintain high-quality experiences but also limit vulnerabilities during transmission