While having a discussion with a partner this week, he pointed out that enterprise single sign-on and federation are being confused much less often these days.  That led me to asking a few people what the difference is and finding that there is still confusion about the two.

So what is federation?  And how is it different from Single Sign-on (SSO)?

SSO is an umbrella term for any time a user can login to multiple applications while only authenticating once.  It covers both federation and password vaulting which is more commonly known as “Enterprise SSO”.  The main difference is that federation eliminates the requirement to use and remember passwords and Enterprise SSO doesn’t.

Federation allows single sign-on (SSO) without passwords – the federation server knows the username for a Person in each application and presents that application with a token that says, " this Person is domain\johndoe or johndoe@example.com".  No password is required for the user to login to each system.  Because of the trust between the two systems, the target application accepts this token and authenticates the user.

The federation server passes that token using one of the standard identity protocols: SAML, OpenID, WS-Trust, WS-Federation and OAuth.  The benefit to federation is security and authentication into both on premise and cloud applications.

Enterprise SSO is when the applications all still require that a password be sent to login, but the software handles storing it and automatically retrieving it for the user and inputting it into the application for an automatic login. The user still has a password for each system that must be provided to login, must be changed on a regular basis, etc. 

I like analogies; in my mind, Identity federation is like an amusement park.  With Enterprise SSO (ESSO), you get into the amusement park but still need a ticket for each ride (think Santa Cruz Beach Boardwalk).  With federation, you get into the amusement park but have a wristband that every ride operator recognizes and lets you on (think Disneyland).  Feel free to use this one.

Even understanding this distinction, there are a lot of different implementation scenarios depending on whether you are initially authenticating on network or in the cloud, whether you are signing in to cloud or on-premise apps, or whether you want to manage Identity as a Service (IDaaS).  Download our whitepaper on the Top 5 Federated Single Sign-on Scenarios to see which one best fits your requirements.