Federated Identity Management vs. Single Sign-On: What’s the Difference?

Each time an enterprise deploys a new application, end users have to create a new set of credentials to remember. The result for employees? Too many passwords. In fact, the average user has to remember at least ten passwords every day—but forgets up to three of those every month. 

Nearly 40% of employees reuse the same two to four passwords for various accounts, and 10% have just one password for all their applications. This example of weak password hygiene means that it’s now easier than ever for hackers to use stolen credentials to access other critical data—compromising individuals and businesses alike. As it stands, organizations need to be able to provide users with easy access to all of their applications by adopting tools like federated identity management (FIM) and single sign-on (SSO).

But first—it’s important that we understand the nuances of these solutions. How is FIM different from SSO? What are the ideal use cases for each approach? This article will help you understand that and more.

What is SSO?

Much like the name implies, SSO is a function that allows users to access multiple web applications at once, using just one set of credentials. For businesses that deploy various applications for HR, payroll, and communications, an SSO solution allows employees to access each of those services with just one login. This makes it easier for users to do their job—as they no longer have to remember multiple passwords—and also reduces the amount of time IT spends on password resets.

Beyond the workforce, companies can utilize SSO to help customers access various sections of one account. For instance, retail networks with many brands can use SSO to let customers access their accounts with each store from one central dashboard, enhancing their user experience. When shifting between each one, the site re-authenticates users with the same credentials.

Breaking down Federated Identity Management (FIM)

As a tool, SSO fits within the broader model of FIM. This model was developed to address the constraints posed by early internet infrastructure, where entities on one domain could not access user information stored in other domains. For companies that operated across various domains, this was particularly problematic, as it made it difficult to create streamlined experiences for employees and customers alike. 

As a solution, FIM was developed as a set of agreements and standards that help enterprises and applications share user identities. Essentially, it’s an arrangement that can be made among multiple organizations so that subscribers can use the same identifiers to access various applications. In short, it’s what allows you to sign into Spotify with your Facebook account details. 

Added to that, in a FIM system, the onus of reviewing and authenticating user credentials is with an identity provider (IdP), not the applications themselves. So, when a user attempts to log into a specific service provider (SP) or application, the SP then communicates with the IdP to authenticate the user. This user identity authorization is often executed through open-sourced Security Assertion Markup Language (SAML), or other related standards like OAuth or OpenID Connect. 

Where the difference lies

The key difference between SSO and FIM is while SSO is designed to authenticate a single credential across various systems within one organization, federated identity management systems offer single access to a number of applications across various enterprises. 

So, while SSO is a function of FIM, having SSO in place won’t necessarily allow for federated identity management. That said, both tools are crucial in supporting organizations with both securing their data and minimizing obstacles in user experience. 

Interested in learning more?

Take a look at how Okta’s SSO combines security and usability for
organizations of all sizes.