Comparison of Single Sign-On: Saml vs Oauth vs Openid

For every way there is to keep data safe, there’s a way to attack it. You can use single-sign on, firewalls, multi-factor authentication, and many other options. For IT professionals and developers, the first thing to do is to choose the standard that needs to be deployed to keep federation identities safe.

Unfortunately, the decision isn’t always clear cut. Many professionals have a hard time distinguishing between security assertion markup language (SAML), Oauth, and OpenID. Each standard brings structure to the federation process.

Let’s take a closer look at the differences between the standards, learn what each means, and why organizations should use them.

What is Federated Identity?

In simple terms, federated identity refers to linking and using an electronic identity that the user has across several systems. This means an application doesn’t necessarily need to obtain in-store credentials in order to authenticate users. Rather the application can use an identity management system that is already storing a user’s electronic identity to authenticate the user as long as the application trusts that identity management system.

It all started with single sign-on (SSO) because companies required a way to unify all the authentication systems in their organization, or easier management and better security.

The Difference Between Standards

The primary difference between SAML vs. Oauth vs. OpenID is that Oauth is a framework that controls authorization to protected resources like applications or groups of files. OpenID Connect and SAML, on the other hand, are industry standards for federated authentication. Because of this, Oauth 2.0 is used in different situations, but it can be used at the same time as SAML or OpenID Connect. OAuth 2.0 is a standard for resource authorization, not authentication.

You can use SAML or OpenID Connect independently to authenticate users and support single sign-on. Even though they both deal with login, they have their own strengths and weaknesses.

OpenID Connect is built on the OAuth 2.0 protocol. It uses an ID token, an JSON web token to standardize the areas OAuth 2.0 leaves to choice, including endpoint discovery and scopes. It focuses solely on user authentication, and is mostly used to enable users to login to consumer websites and mobile applications.

SAML runs independently of Oauth 2.0, and instead of JSON web token, it uses message exchange to authenticate in XML. As such, it is more common to help organization users to use a single login for multiple applications. It is an umbrella standard that addresses federation, single sign-on, and identity management.

It’s not about which structure a company should use, but is about when the company should deploy each one. The strongest identity solution uses these structures to achieve different things, depending on what the organization needs to protect.

SAML

This is what allows users to login to identity providers (IdPs) or corporate intranet and then access other services without needing to re-enter your credentials. It uses XML to exchange authentication and authorization messages between IdPs and service providers to verify user identity and permission, then either grants or denies access accordingly.

Terms to Know in SAML

Client: The web browser or other application the end user uses to access a resource or web application.

Identity Provider: The server that owns the user identities and credentials.

Service Provider (SP): The protected application.

SAML Workflow

1. The end user clicks the login button for a file sharing service. The file sharing service is the service provider and the end user is the client.
2. The file sharing service builds an SAML authentication request, signs, and optionally encrypts it. Then, it sends it to the identity provider.
3. The file sharing service redirects the client’s browser to the identity provider for authentication.
4. The identity provider verifies the received SAML authentication request. If valid, it presents a login form for the user to enter their username and password.
5. After the client is successfully logged in, the identity provider generates a SAML assertion, also known as a token. It includes the user identity and sends it directly to the service provider.
6. The identity provider redirects the client back to the service provider.
7. The service provider verifies the SAML token, extracts the user identity from it, assigns the correct permissions for the client and then logs them into the service.

OAuth

This standard provides secure delegated access, meaning an application can access sources or take action on a server on a user’s behalf, without requiring users to log in or share sign-in information. When you’ve set up a new smartphone and given permission to add your Facebook contacts to your phone’s contacts, then it’s more than likely you’ve used OAuth 2.0.

Terms to Know in OAuth

Client: The web browser or other application the end user uses to access a resource or application.

Authorization Server: The server that owns the user identities and credentials.

Resource Server: The protected application.

OAuth Workflow

OAuth does not assume the client is a web browser. The workflow is as follows:

1. The end user clicks the login button for a file sharing service. The file sharing service is the resource server and the end user is the client.
2. The resource server presents the client with an authorization grant and directs the client to the authorization server.
3. The client requests an access token from the authorization server with the authorization code.
4. The client logs into the authorization server and checks to see if the code is valid. If so, the client gets an access token that can be used to request a Protected resource from the resource server.
5.  After receiving a request for a protected resource with an access token, the resource server will verify the token’s validity with the authorization server.
6. if the token is valid, the authorization server sends the information about the client to the resource server.

OpenID

OpenID is an open standard companies can use to authenticate users. IdPs use this so users can sign into the IdP then access other apps or websites without needing to share their sign-in information or login again.

It’s an open source solution that handles the authentication process. Major companies like Google, Microsoft, Ping Identity, Facebook, Yahoo, and PayPal sponsor the standard. It allows users to choose the third-party OpenID provider they want to use to login to any website that accepts the OpenID standard. If you’ve ever used your Google or Facebook accounts to sign into another service or shopping cart, then you’ve seen OpenID in action.

OpenID is useful for app and website developers who want to authenticate users, but do not want the responsibility of storing and managing their own user records due to the sheer volume of data breach possibilities.

OpenID Connect is the third version of this standard. Before it came OpenID and OpenID 2.0.

Use Cases and the Standard to Use

• Access to Applications from a Portal: Use SAML
• Centralized Identity Source: Use SAML
• Enterprise Single Sign-On: Use SAML
• Mobile use cases: Oauth or OpenID
• Access to resources (either permanent or temporary): Oauth or OpenID

These of course, aren’t the only protocols for federated identity – just the most popular. Others include: Higgins, Liberty Alliance, MicroID, and Windows CardSpace.

As technology continues to grow and we see even more interconnectivity between systems, federated identity helps because it’s more convenient for users. It ensures they don’t have to remember as many usernames and passwords – but it does present some security issues. The key to its success lies in proper implementation – whether it is SAML, OAuth, or OpenID.