Federated SSO, A Primer (SAML, OAuth 2.0, OpenID Connect)

Federated single sign-on (or SSO) is a modern way to solve the problem of having multiple logins between different services and applications. Let’s take a look at three of today’s common federated identity protocols: SAML, OAuth 2.0, and OpenID Connect.


The first of the authentication methods that I’d like to talk about today is SAML, which stands for Security Assertion Markup Language. SAML is the oldest of the free main federated identity protocols, with its last major revision in 2005. There are three major players in SAML – the user, the Identity Provider (or IdP) that authenticates the user, and the Service Provider (or SP) such as an application. SAML has three primary components, which are the assertion, the protocol, and the binding. The SAML assertion is an XML-based package of information that contains specific information such as the user, group the user belongs to, or any other information that might be useful to an application. Assertions are for authentication (identifying a user), attributes (information about a user), or authorization (what a user can access and do). The protocol defines how assertions are sent and received. Finally, the binding is a definition of how SAML message exchanges and Simple Object Access Protocol (SOAP) exchanges are mapped to each other.

A simplified flow (or basic use case) of SAML is as follows: The user needs to access many different applications. The user’s client tells and application, which is the Service Provider, that they want to access its services. The Service Provider then needs to check if the user is authenticated. If they are, then the user is free to proceed. If they aren’t, the client needs to go to the Identity Provider for authentication. The Identity Provider will authenticate the user against some credential at this point. Once the Identity Provider has authenticated the user and someone good to the application, it then creates the SAML assertion. The Identity Provider passes the SAML assertion to the client, which then passes it to the Service Provider. The Identity Provider can also pass the assertion to different applications as needed, saving the user from re-authenticating.

SAML 2.0 flow diagram (created by Zach Dennis of Mutually Human)


SAML isn’t perfect for all use cases, however, as SAML is poorly suited for mobile devices. With its last major update in 2005, SAML was designed before mobile use was even a use case. It assumes its clients will be web browsers, which poses a problem for mobile apps. On the other hand, OAuth 2.0 was designed with the mobile use case in mind and features several different flows, including one for mobile.

OAuth 2.0

OAuth 2.0 is another open web standard available for simplifying login experiences.  The OAuth protocol was originally established in 2006 and its most recent revision, which was published in 2012, is used by a number of large companies, such as Google, Facebook, Twitter, Yahoo, and more.

OAuth 2.0 allows users to share private resources between applications without having to disseminate their login credentials. This is accomplished through use of access tokens known to and usable only by certain applications. In this setup, client applications have limited access to resources provided by another application and can act on the behalf of the user, all based on what the user allows.

OAuth 2.0 flow diagram (created by Zach Dennis of Mutually Human)


It’s worth noting that the “Auth” in OAuth 2.0 refers to authorization, not authentication. Authentication is verifying the identity of a user and knowing that a user is who they say they are, like we see in SAML. With SAML, shared information regards who a user is and what attributes they have. It also provides the ability to give or deny access to something like an application and to request authentication. Authorization, on the other hand, is permitting a user or service to only access data appropriate for them. This fits OAuth’s use case of delegating access, allowing client applications to access information on behalf of the user.

OpenID Connect

While OAuth 2.0 isn’t quite suited for authentication, our next federated protocol, OpenID Connect, manages to solve this problem. Established in 2014, OpenID Connect is an identity layer built on top of OAuth 2.0, with a large number of implementations from companies such as Google and Paypal. OpenID Connect enables client applications to receive valuable basic information about a user, such as the user’s identity, the user’s available attributes, and other authentication-related details. Like SAML, authentication is done by some Identity Provider, such as Google, which is then relayed back to the relying party, or the service requesting authentication. Supported Identity Providers range from large companies to small providers, such as a self-issued one. OpenID Connect was designed with simplicity in mind, uses REST/JSON message flows. It supports clients of all types, including web-based clients, mobile clients, and JavaScript clients. Finally, OpenID Connect’s extensible specification allows for optional features such as encryption of identity data, discovery of OpenID Providers, and session management.

OpenID Connect flow diagram (based on diagram by David Hay)


While the three mentioned federated protocols have a lot of similarities and a degree of overlap, each suits a different use. SAML is best suited for use as single sign-on for enterprise users, with its ability to centralize authentication and ease directory integration. Its age works against it though, as it’s not suited for mobile applications and the consumer realm as a result. Next, OAuth 2.0 is geared towards API authorization between applications with its ability to delegate access on behalf of users. Finally, OpenID Connect is very well suited for single sign-on for consumers, especially since it was designed for mobile applications.

Check out our Identity & Access Management and IDaaS matrices, which go into a large number of today’s vendors and their products for identity software and services. Some specific products that feature these federated protocols for SSO purposes include Microsoft’s Active Directory Federation Services (SAML, OAuth, OpenID Connect), IBM Tivoli Federated Identity Manager (SAML, OpenID), and Oracle Identity Federation (SAML, OAuth, OpenID).

If you need a partner to help with federated protocols or implementing a single sign-on, M&S Consulting is here for you. We’d be more than happy to help you find the best solution for your single sign-on needs.

Leave a Reply

Your email address will not be published. Required fields are marked *