Single Sign On Simplified

There is a myriad of information about Single Sign-on solutions out there. You might hear terms like Federated Identity, Claims based Identity, token based authentication, and many more. So I am going to try to demystify some of this, and boil down what many complicate into simple terms.

I am going to glaze over details. I will have some more posts where I go into specific solutions, but for now lets just look at the basics.

First, some terms. Let's make sure we all can speak a common dialect...

General Terms

  • Authentication - Authentication is the process of proving that an identity is truly who they say they are. Historically this was by proving that they knew something (e.g. a password). Newer methods also work by having the person prove that they have something (e.g. a token) that only they could have.

  • Authorization - Authorization is the process of proving that an identity has the right to use something. For example, you have to be authorized before you can access a file share, even if you have already been authenticated by logging into a workstation.

  • Federated Identity - An authentication method where the identity provider (Where you log in) is not the same system/owner as the identity consumer (also known as the "reliant party" or more simply the application you are signing on to. An extremely common scenario for this is logging onto something within a remote organization, using an account from my own windows domain. The two domains "Federate" the identity across, allowing your identity to be known within both organizations.

  • Claims Based Identity - At it's core, Claims Based Identity simply means that the identity of a party is provided to the application through a list of things that you know about that party. For example, I may log in and have claims that state my first name is Tim, and another that states I live in Missouri. Typically these are provided within a cryptographically trusted token so that the application consuming these claims can be sure that I am not making up my name.

  • Token Based Authentication - Token Based Auth is simply a method of authenticating a user without the application needing to hold on to the password, as was common with Basic/Forms based authentication. Instead, a cryptographically signed token is provided, that can be verified that it was obtained from a trusted party. In additions, the tokens often carry claims allowing for claims based identity.

Specific Technologies

  • OAuth/Oauth2 - OAuth (And the sequel, OAuth2) are authorization specifications designed to allow delegated access to resources on behalf of an identity. Often they are also used as authentication methods, however that is not their goal. The delegated part is important, as usually in the OAuth scheme, the application is given authorization by the user. This can be, for example, to allow the application to access their social media account, and retrieve friends, etc.

  • OpenID Connect - OpenID Connect is an authentication specification built on top of OAuth 2. As it became clear that OAuth 2 was taking off being used for authentication despite it not being designed for that, OpenID was developed to sit on top of the protocol and fill in the gaps.

  • WSTrust - WSTrust is an older authentication specification originally designed to allow easy authentication of SOAP based Web Services. It however continues to be used in several combination Single Sign On Solutions.

  • WSFederation - Think of WSFederation as WSTrust+. WSFederation adds federation capabilities on top of WSTrust, and adds a Passive, web based flow to make the protocol much easier to use.

I think that is enough to get a base understanding of the landscape.
If you wish to understand more about these topics, I highly recommend the following Pluralsight Courses:

As well as the following blogs:

Stay tuned for more on this topic, and comment below if you would like specific topics covered.

Check out the next post in the series here.

Tim Ritzer's Image
Tim Ritzer
Missouri, USA

I am a Software Architect who loves to code, trying to practice what he preaches.
Follow me on Twitter @TimRitzer

Share this post