SSO, OAuth, federated identity management — these are all terms tossed around the internet, but you might be confused what they actually mean (to you, as a developer). What compounds the confusion is the constant misuse and mixing of the terms to describe authentication systems.
So, when some one says, “federated identities to achieve SSO using SMAL” What are they actually saying? Untangling the barrage of misused terms, protocols, and frameworks is the key to understanding these authentication mechanisms. To address the problem, let’s start with some simple definitions.
What is Single Sign On (SSO)?
SSO is an authentication process or a use case that allows users to authenticate once and then gain access to multiple applications or services (called resources). SSO is not a protocol nor a framework. It does not make any assumptions on how this should be achieved.
There are several standard ways to implement a SSO solution, but some methods are geared towards specific users, flows, and user-agents so it is important to keep in mind a few things while you search you search out your SSO solution.
**Who are your users?**Are you providing SSO abilities to company employee (B2I)? For example, a company makes use of several web-based applications within their network and wishes to issue employees a single set of credentials between the apps.
Or does your company provide services though multiple applications to customers (B2C) and are trying to provide a SSO experience throughout your application suite?
**What devices do you support?**Do you support native mobile applications or just browser based web apps?SSO provides a great deal of benefits to both user-administrators and end-users. However, before diving into SSO solutions, we must introduce some fundamental prerequisite topics which will help drive the SSO discussion later.
What is Federated Identity Management(FIM)?
First, what is a Federated Identity?
Many definitions state something of the line “A Federated Identity refers to an identity of a person in one system which is linked to same person’s identity in multiple other systems.” So, let’s take a look at what that confusing definition means.
Therefore, by being federated, the identities can be used across multiple applications. This grouping of applications is sometimes called the identity federation — in which they all share a common set of federated identifiers. Once authenticated with the IdP, users can move freely between applications within the federation.
That still may not be very clear. What does it really mean when someone says, “my authentication is ‘federated’ out to ABC”. In the simplest of terms, instead of a service provider authenticating the user itself, it has offloaded its authentication to another system (called an identity provider). The service provider must trust the authentication ability of the identity provider.
But federation is more then applications sharing a common set of identifiers. It is also about linking identifiers in different systems. Users can authenticate with the IdP using credentials for the any of the applications within the federation. For example, a user can login to one of the federated applications using either their Facebook credentials OR Google+ credentials given that the IdP accepts both credentials. It doesn’t matter which one is used, the federated applications see the authenticated user as the same user.
Federated identity management refers to the standards and protocols used to i) enable the exchange of information between the identity provider and service provider and ii) make the identifying information portable (format and attributes) so that it can be used across multiple applications and iii) a system that can support the volume of required users.
In other words, user credentials are no longer stored by the service provider. Nor does the service prodder need to validate them. Instead, the identity provider validates the user and notifies the service provider that the user is indeed who they say they are.
Federation also provides the added benefit that the application does not need to obtain the user credentials. Though FIM protocols, the application needs only to be told that the user has authenticated and a way of validating this is true. The service provider stays well clear of ever seeing or touching a password. This is great for environments where individual development teams must have limited exposure to user credentials.
Keep in mind, in this definition, we’ve made no assertion how this happens. The how is an implementation detail. Also note that we’ve made no binding between the concept of SSO and federated identity. Though many implementations of SSO make use of federated identity management, the two are separate concepts.
Some may say, well isn’t SSO a subset of FIM?
Answer: Yes and no. There’s nothing in the definition of SSO that requires a FIM but most practical implementations of SSO use a form of FIM (or rather, once an application federates out authentication to an third-party IdP, SSO is easily implementable across all the federated applications). Thus, the two terms are often incorrectly used interchangeably.
Federated Authentication Flows
Let’s look at a sample flow. We’ll re-examine implementation details when we start looking at specific protocols to achieve federated identity management (and SSO) but for now it’s important to get a grasp of a basic flow. In this example, we’ll assume the user is using a browser to access the service provider (which serves out web front-end HTML and has a server backend) and the IdP is using an authentication flow using employing redirects.
First, the SP may have a mechanism of checking if a user is currently authenticated by based on any session state it maintains. In some cases, the SP will always redirect to the IdP and let it check the user’s current state.
If the user is not authenticated, they are redirected to the identity provider’s login page.
The user then enters their credentials (i.e. username and password). When they click the submit button, the identity provider validates their credentials and returns the user back to the service provider (if valid).
In addition, the identity provider creates some signed data to be sent back along the HTTP request. This data tells the service provider the user has successfully logged in (among other things). The service provider now validates this data and if it is found to be valid, the application can treat the user as authenticated.
Keep in mind, this flow keeps out much of the specific details, specifically, what this “data” is, how the validation of the data is done, and other important specific security details (tied to the implementation). What you should see is that the service provider never dealt with the user’s credentials. The validation is done by the IdP and used a secure data format to communicate a successful authentication (this could be XML, a JWT, etc).
Delegated Authentication
Delegated authentication simply means the service provider does not provide authentication on its own but rather delegates this task to another third-party service (the IdP). A site allowing users to login via Facebook Connect is an example.
Federated authentication uses a form of delegated authentication but, delegated authentication is not necessarily federated. The key difference between the two is the acceptance of the identities across different service providers. For example, if two or more service providers trust the same IdP for authentication and the user identities are valid across both applications, then we call this federation (and federated authentication).
Federated Authentication
With delegation, an application uses only a known set IdPs for authentication. In the example below, the application allows logins using Facebook and Twitter, but only those two. The key difference is that the federated example above accepts credentials from any system that the IdP accepts.
Delegated Authentication
Next, we’ll look at some specific implementations of federated identity management and how they can be used to achieve SSO.
Central Authentication Service Protocol(CAS)
CAS is a protocol for achieve federated identify management. To add some confusion, there is the CAS project (run by Apereo) which provides an implementation of the CAS protocol (among others). Between CAS, SAML, and OpenID Connect, CAS is the least popular.
Security Assertion Markup Language(SAML)
SAML is a well-established XML-based standard for exchanging authentication and authorization data between systems (and with respect to authentication, between an IdP and a SP). Unlike CAS, which is a protocol, the SAML standard defines the XML document structure and how applications should consume it.
There are well established SAML authentication flows which define rules and procedures to create an federated SSO experience. Like CAS, the SAML experience is trailered for browser user-agents with application backends that can parse and validate the heavyweight SAML token.
OpenID Connect
OpenID Connect is a lightweight authentication protocol which uses REST based message flows using JSON web tokens (JWT). OpenID Connect is well suited towards single page applications, native mobile apps, and other non-browser user-agents. OpenID Connect is built on-top of the OAuth2 framework and has uses OAuth2 like flows for authentication (which OAuth2 was not well suited for).
Conclusion
Federation has benefits in both the B2C and B2I worlds. In the enterprise world, federation allows your employees to remember only one set of credentials. For your customers, it lowers the burden of registration by allowing them to use credentials they already have (Facebook, Gmail, or Twitter). In the end, federated identity management systems enables the trust between systems.
I’ve also written a follow up regarding what you need to consider before choosing an authentication service provider.
