Federated Identities: OpenID vs SAML vs OAuth
Single sign-on (SSO) started it all. Organizations needed a way to unify authentication systems in the enterprise for easier management and better security. Single sign-on was widely adopted and provided a solution for keeping one repository of usernames and passwords that could be used transparently across several internal applications.
Service-oriented software kicked off the next wave of change. Organizations wanted to open APIs in their software so partners and independent developers could use them. Managing authentication and authorization for entities looking to consume these APIs was obviously a challenge.
Social media moved things even further. Various platforms spread far and wide on a plethora of devices, and many applications were built on top of those platforms. Now we have countless apps and services hooked into Twitter, Facebook, and LinkedIn.
The problem? How to bring together user login information across many applications and platforms to simplify sign-on and increase security.
The solution? Federated identities . . .
What is federated identity?
Federated identity means linking and using the electronic identities a user has across several identity management systems. In simpler terms, an application does not necessarily need to obtain and store users’ credentials in order to authenticate them. Instead, the application can use an identity management system that is already storing a user’s electronic identity to authenticate the user—given, of course, that the application trusts that identity management system.
This approach allows the decoupling of the authentication and authorization functions. It also makes it easier to centralize these two functions in the enterprise to avoid a situation where every application has to manage a set of credentials for every user. It is also very convenient for users, since they don’t have to keep a set of usernames and passwords for every single application that they use.
There are three major protocols for federated identity: OpenID, SAML, and OAuth.
OpenID is an open standard sponsored by Facebook, Microsoft, Google, PayPal, Ping Identity, Symantec, and Yahoo. OpenID allows user to be authenticated using a third-party services called identity providers. Users can choose to use their preferred OpenID providers to log in to websites that accept the OpenID authentication scheme.
The OpenID specification defines three roles:
- The end user or the entity that is looking to verify its identity
- The relying party (RP), which is the entity looking to verify the identity of the end user
- The OpenID provider (OP), which is the entity that registers the OpenID URL and can verify the end user’s identity
OpenID had a few interesting vulnerabilities in the past, for example:
- Phishing Attacks: Since the relying party controls the authentication process (if necessary) to the OpenID provider, it is possible for a rogue relying party to forward the user to a bogus OpenID provider and collects the user’s credentials for the legal OpenID provider.
- Authentication Flaws: In March 2012, three researchers presented a paper that highlighted two vulnerabilities in OpenID. Both vulnerabilities allow an attacker to impersonate any user to a website if the website doesn’t properly check whether the response from the OpenID provider contains a properly signed email address.
Security Assertion Markup Language (SAML) is a product of the OASIS Security Services Technical Committee. Dating from 2001, SAML is an XML-based open standard for exchanging authentication and authorization data between parties.
The SAML specification defines three roles:
- The principal, which is typically the user looking to verify his or her identity
- The identity provider (idP), which is the entity that is capable of verifying the identity of the end user
- The service provider (SP), which is the entity looking to use the identity provider to verify the identity of the end user
Following diagram explains SAML work flow:
- A group of researchers presented a paper in 2011 where they used an XML Signature Wrapping vulnerability to impersonate any user.
OAuth is another open standard. Dating back to 2006, OAuth is different than OpenID and SAML in being exclusively for authorization purposes and not for authentication purposes.
The OAuth specifications define the following roles:
- The end user or the entity that owns the resource in question
- The resource server (OAuth Provider), which is the entity hosting the resource
- The client (OAuth Consumer), which is the entity that is looking to consume the resource after getting authorization from the client
OAuth 2.0 is an open authorization protocol which enables applications to access each others data. For instance, a game application can access a users data in the Facebook application, or a location based application can access the user data of the Foursquare application etc.
Here is a diagram illustrating the concept:
- A session fixation vulnerability flaw was found in OAuth 1.0. An attacker can fix a token for the victim that gets authorized. The attacker then uses the fixated token.
- OAuth 2.0 was described as an inherently insecure protocol since it does not support signature, encryption, channel binding, or client verification. The protocol relies entirely on the underlying transport layer security (for example, SSL/TLS) to provide confidentiality and integrity.
This table explains the major differences between the three protocols:
Single sign-on for consumers
API authorization between applications
Single sign-on for enterprise users
SAM, XML, HTTP, SOAP
In a world with increased interconnectivity between hybrid systems, protocols, and devices, federated identity seems to be here to stay. Although federated identity is much more convenient for users who don’t have to remember so many different usernames and passwords, it comes with a security price. However, proper implementation of OAuth, SAML, OpenID, or any other federated identity protocol adds convenience without extra threat surface.