SAML, OAuth, OpenID

Introduction

In this article, we are going to see what are federation, single sign-on, and three federated identity standards, namely Security Assertion and Markup Language (SAML), OpenID and OAuth. We will also see the shortcomings observed in each standard.

The three federated identity standards that we will talk in this article are all related to one basic concept of federation. Federation of identity is the means of linking a person's attributes across various identity management systems. It means that now users have the liberty to access multiple applications with a single password, provided there is a trust established between two participating entities. In this, only one side stores authentication credentials and authenticates all the requests that are coming from other sites.

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

SAML

What is SAML?

Security Assertion Markup Language (SAML) is an XML standard that allows a user to log on once to the log on site for all the trusted websites. SAML was released in 2002 with version 1.0 and in 2005 version 2.0 was released. SAML is designed for B2B and B2C transactions. SAML has the following components:

• Assertions: Authentication, attribute, authorization
• Protocols: HTTP, SMTP, FTP, SOAP
• Bindings: SAML over SOAP, SAML over HTTP

How SAML works

SAML defines three roles:

• Identity Provider (IDP): This role will validate the identity of a user who is asking for a service.
• Service Provider (SP): This role will provide services to user.
• Principal: This is typically the user asking for a service from SP and getting validated by IDP.

Circle of Trust: before setting up assertions between different providers, both the parties need to establish a Circle of trust amongst (COT) themselves. This is genially done by exchanging the metadata between the parties.

Steps:

1. User tries to access a protected resource hosted by the SP.
2. SP generates a SAML request token and redirects the browser to the IDP site.
3. User gets redirected to IDP site.
4. IDP receives the SAML request, validates user credentials with the data store and generates an encoded SAML response.
5. Browser sends the SAML response to the SP.
6. SP verifies the SAML response and gives the user access to the protected resource. It should be noted that without the COT between the parties, it is not possible to trust the SAML response.

SAML shortcomings

In 2011, a vulnerability termed as "XML signature wrapping vulnerability" was found. This vulnerability can be used to impersonate any user.

OAuth

What is OAuth?

OAuth provides authorization to APIs. I assume everyone has seen "import contact information" on LinkedIn, Facebook, etc., where the Service Providers ask us to grow our network by importing our contact list from our email providers such as Gmail, Yahoo, etc. With the OAuth 2.0 standard being published in 2012, now various frameworks are available which provide a layer of authentication over authorization too.

How OAuth works

OAuth has following roles:

• A resource server called as OAuth Provider –the entity which is hosting the resource.
• End User that owns the resource that is being requested.
• Client –OAuth Consumer-the entity requesting for resource.

Steps:

1. User is logged into a social network platform like Facebook (OAuth Consumer in this case) and wants to import contacts from email provider such as Gmail (OAuth Provider in this case).
2. OAuth Consumer redirects the request to OAuth Provider to generate a request token and secret key.
3. OAuth Provider generates request token and secret key and sends it to OAuth Consumer.
4. OAuth Consumer asks the user to authorize and sends the user the request token received from OAuth Provider.
5. On clicking the link, secret key is passed over to OAuth Provider using API.
6. OAuth Provider asks the user to authorize the OAuth Consumer to consume its data.
7. User confirms the OAuth Consumer to consume its data.
8. OAuth Provider sends user a "request token" and a "request token secret" and redirects the user to OAuth Consumer.
9. User gets redirected to OAuth Consumer with a "request token" and a "request token secret".
10. OAuth Consumer presents the "request token" and the "request token secret" and asks for user contacts.

OAuth shortcomings

Below are the shortcomings found in OAuth:

• OAuth 1.0 was vulnerable to session fixation attack.
• OAuth 2.0 does not have native encryption capabilities. It relies on the SSL/TLS protocol to provide encryption of the sensitive data being exchanged between parties to and fro.

OpenID

What is OpenID?

OpenID was released in 2006 and its functions resemble that of SAML, but instead of limiting the usage to enterprise users, OpenID was designed for consumer apps and services. With OpenID, the enterprise users are also in scope now. OpenID is being provided by majors like Facebook, Google, Yahoo, etc.

How OpenID works

Below are the roles that OpenID provides:

• End user who has OpenID and wants to verify the identity.
• Resource Party which is the party that wants to verify the identity of end user.
• OpenID provider which is the party used to verify end user.

Steps:

1. User wants to access a resource being protected by Resource Party.
2. Resource Party asks the user for OpenID.
3. User enters the OpenID and it is received by the Resource Party.
4. Resource party identifies the OpenID provider via XPDS and initiates association.
5. OpenID provider generates and returns key and association handle.
6. Request is being redirected to the user for authentication for user authentication
7. User enters the credentials and it is received by the OpenID provider.
8. OpenID provider validates the user and redirects the user back to Resource Party with a signed assertion.
9. User presents the signed assertion to the Resource Party.
10. Resource Party validates the assertion and creates a session for the user.

OpenID shortcomings

Following are the shortcomings being observed in OpenID:

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

• OpenID has some authentication flaws in which an attacker can impersonate any user if the OpenID provider does not validate the signed email address.
• OpenID is susceptible to phishing attacks where a rogue Resource Party can forward the user to another rogue OpenID provider and thus can obtain user credentials.

Which one to choose?

Following are the points which can be useful to consider which one to use among OpenID, OAuth or SAML or any of their combination.

• If the use case is to develop SSO where at least one partner is enterprise use SAML, otherwise use OpenID.
• If the use case involves mobile devices for API authorization then use OAuth.
• If use case requires a centralized identity provider the use SAML.

References

• http://www.softwaresecured.com/2013/07/16/federated-identities-openid-vs-saml-vs-oauth/
• http://www.trishburgess.com/trishs-blog/intro-to-openid-oauth-and-saml