Nowadays, across the web, it is common practice for websites to allow users the choice to login in to applications using their existing Facebook, Google, or Twitter accounts, instead of registering a new account. This authentication method utilizes a Federated Identity, and has been gaining popularity due to the fact that users simply do not want to deal with the hassle of registering over and over again every time they want to use a new application on the web.
Federated Identity Management (FIM) allows users to use the same login credentials across the web in different applications even when those applications employ different standards and technologies. The user’s credentials are stored at the identity provider (where the user’s credentials are originally created and stored). So when the same user wants to log into another service, that service provider will validate the user’s credentials with the identity provider.
Contrary to popular belief, FIM is different than single sign-on (SSO). SSO allows users to access multiple applications or services with a single login. Example of utilizing SSO is when you open your Youtube account in one tab and then you open your Gmail in another tab without logging in again. Whereas FIM lets you login to Spotify using your Facebook account instead of registering for an account (if you are a first-time user).
Example of logging in using Federated Identity.
There are many types of FIM available, including SAML (Security Assertion Markup Language), OAuth, OpenID, Security Tokens (Simple Web Tokens, JSON Web Tokens, and SAML assertions), Web Service Specifications, and Windows Identity Foundation. In this article, we are going to focus on the top 3 open standard, which are: OAuth, OpenID and SAML (Security Assertion Markup Language).
But before we go there, we need to talk about authentication and authorization. For some, these two terms are sometimes used interchangeably but the fact is, they are two very different things.
Authentication is the process of verifying a user’s credential (normally user and password) while authorization is the process of determining whether the authenticated user has the necessary privileges in the system. Normally authentication is the first step while authorization comes after authentication.
OAuth is an open standard for authorization, not authentication. This means that it is a protocol for access control, and not for validating a user’s identity. OAuth allows the sharing of user’s resources without sharing the user’s credentials. To simplify, OAuth has 2 main parts; obtaining an access token and using the access token to access protected resources.
There are currently 2 versions of OAuth: OAuth1 and OAuth2.
OAuth1 (created in 2007)
- Access tokens are stored for a very long time (more than a year).
- Does not scale well.
- Works best for desktop web browsers but not so much for mobile apps.
OAuth2 (published in 2012)
- Considered the standard model for OAuth.
- Initially developed to address the issues in OAuth1.
- OAuth2 is not backward-compatible with OAuth1 because of the drastic changes in version 2.0.
- Less secure than OAuth1. It is expected that OAuth2 is to be implemented inside the Transport Layer Security (TLS) or SSL.
- More complex and less prescriptive.
- Designed to be more interoperable between sites and devices.
- Access tokens are short-lived (example is session-based).
OpenID is an open standard and decentralized authentication protocol. OpenID which was developed in 2005 was the first mainstream standard for authentication, but after the approval of OpenID Connect in 2014, OpenID was rendered obsolete. OpenID Connect is an identity layer built on top of OAuth 2.0.
OpenID Connect allows users to login to multiple websites without needing to register for an account. The identity provider confirms the user’s identity to the website/web app that the user visits. For developers, this reduces the need for them to create a login system (or database for storing usernames and accounts) where the users are authenticated using a decentralized third-party service.
OpenID Connect is being widely used and supported by most large internet companies like Google, Facebook, Microsoft, Amazon, and many others.
Developed in 2001, Security Assertion Markup Language (SAML) is an open standard for exchanging authentication and authorization data between an identity provider and a service provider. It is an XML-based framework where authentication information is exchanged through digitally signed XML documents.
Typically, a user requests a service from a service provider (e.g a website). The service provider then requests and obtains an assertion (xml that contains statements about authentication, authorization, and/or attributes) from the identity provider. Upon receiving the assertion, the service provider can then render the service requested by user. By this principle, SAML enables single sign-on applications.
Current version is SAML 2.0, which was approved as the standard in 2005. Like OAuth2, SAML 2.0 is incompatible with its predecessor. Additionally, SAML 2.0 is not suited for mobile applications (although there are less-than-elegant workarounds available) due to the fact that mobile apps cannot read the SAML token if it is too long.
SAML 2.0 is best used to authorize a partner or user to use a web service.
An example of SAML 2.0 usage is when a user logs into a travel agent services website (identity provider), the user then is able to book a room through a hotel website that has been configured with SAML-configured SSO.
|OAuth2||OpenID Connect||SAML 2.0|
|Latest version developed||2012||2014||2005|
|Authentication||No (but possible with pseudo authentication)||Yes||Yes|
|Token / Assertion type||JSON||JSON||XML|
|Purpose||Provide temporary access tokens to access resources||Decentralized authentication||SSO for enterprise partners|
|Best for||Mobile apps with API||Mobile apps||SSO for desktop browser|
Well there you go: the gist of the available open standard for authorisation and authentication.
However, since the current trend is increasingly moving towards mobile applications, using SAML is almost out of the question as SAML is more suited for desktops on enterprise network. Safe to say that the invention of SAML did not anticipate the current widespread use of mobile apps and devices.
Considering that the use of mobile devices are growing exponentially, the current standard for authentication and authorization that are being implemented seem to be a combination of OAuth2 and OpenID Connect. An example would be like, a web app asks Google to sign-in a user using his or her Google account and at the same time requests access to protected information available via a Google API that is enabled with OAuth2.