In order to provide a user with a single sign on experience a developer needs to implement a SSO solution. Over the years there have been many attempts at achieving SSO, but this article is going to focus on a comparison between SAMLand OAuth2 - a recent exploration that we took on.
This article discusses about various security policies. To determine an option which fits for both application and customer’s security policies, it provides details of OpenID, OAuth2, and SAML.
Authentication means verifying that someone is indeed who they claim to be. Authorization means deciding which resources a certain user should be able to access, and what they should be allowed to do with those resources. Oftentimes, an application will require a little bit of both.
With sites like Facebook or Google, a user can log in to one application with a set of credentials. This same set of credentials can then be used to log in to related websites or applications (like websites that ask you, “Sign up with Facebook or Google account?”).
Likewise, a business may have an internal-facing employee portal with links to intranet sites regarding timesheets, health insurance, or company news. Rather than requiring an employee to log in at each website, a better solution would be to have the employee log in at a portal, and have that portal automatically authenticate the user with the other intranet sites. This idea, called single sign-on (SSO), allows a user to enter one username and password in order to access multiple applications.
The benefits are pretty nice for the user. The use of linked identities means they have to manage only one username and password for the related websites. The user experience is better for them, as they can avoid multiple logins. A user’s (single set of) credentials will be stored in one database, rather than multiple credentials stored across multiple databases. This also means that developers of the various applications don’t have to store passwords. Instead, they can accept proof of identity or authorization from a trusted source.
There are multiple solutions for implementing SSO. The three most common web security protocols as of now are OpenID, OAuth, and SAML. Implementations and libraries exist in multiple languages already, and going with a standardized protocol allows better interoperability than a custom solution.
OpenID is a protocol, an open standard for authentication, promoted by the non-profit OpenID Foundation. There are over a billion OpenID-enabled accounts on the internet, and organizations such as Google, WordPress, Yahoo, and PayPal use OpenId to authenticate users.
A user must obtain an OpenID account through an OpenID identity provider (for example, Google). The user will then use that account to sign into any website that accepts OpenID authentication (think YouTube or another site that accepts a Google account as a login). The OpenID standard provides a framework for the communication that must take place between the identity provider and the relying party.
In OpenID, authentication is delegated: server A wants to authenticate user U, but U's credentials (e.g. U's name and password) are sent to another server, B, that A trusts (at least, trusts for authenticating users). Indeed, server B makes sure that U is indeed U, and then tells to A: "ok, that's the genuine U". Basically, OpenID is about verifying a person's identity.
On a website, it looks like this:
Consider an example, where user wants to log in to MyExample Account. User navigates to the login screen, where user is offered a “Sign in with Google” option. User clicks that, and MyExample initiates
association with Google and requests and receives an association handle. MyExample then forwards user to the Google login page. User enters credentials, and Google validates user. User is then redirected back to MyExample, along with a token stating that Google believes user is who he claims to be. MyExample trusts this token and creates session for user.
OAuth2 is an open standard for authorization. OAuth2 is also the basis for OpenID Connect, which provides OpenID (authentication) on top of OAuth2 (authorization) for a more complete security solution. OpenID Connect (OIDC) was created in early 2014. This primer will instead focus on OAuth2 by itself, not as a part of OIDC.
OAuth2 provides secure delegated access, meaning that an application, called a client, can take actions or access resources on a resource server on the behalf of a user, without the user sharing their credentials with the application. OAuth2 does this by allowing tokens to be issued by an identity provider to these third-party applications, with the approval of the user. The client then uses the token to access the resource server on behalf of the user. Yet Twitter’s OAuth guide says that OAuth2 is an authentication standard. So what gives? As it turns out, authorization can be used as a form of pseudo- authentication.
In OAuth, authorization is delegated: entity A obtains from entity B an "access right" which A can show to server S to be granted access; B can thus deliver temporary, specific access keys to A without giving them too much power. You can imagine an OAuth server as the key master in a big hotel; he gives to employees keys which open the doors of the rooms that they are supposed to enter, but each key is limited (it does not give access to all rooms); furthermore, the keys self-destruct after a few hours.
An authorization use case of OAuth2 might be as follows: Alice is leaving town and she wants her friend Bob to house-sit. Alice gives Bob the house key, and he now has access to enter the house. The key gives him authorization to enter the house, as authorization relates to which resources a user should have access to, and what they can do with those resources. In this metaphor, the homeowner is the user, Bob is the client, the door lock is the identity provider, and the house is the resource server.
This can be twisted into a pseudo-authentication use case by assuming that the person who has the house key is the homeowner. However, as we can see with Bob house-sitting for Alice, this is not always the case.
Online, an OAuth2 use case might look like this: Alice signs up for a new account at NewApp and is offered the option to see which of her friends already use NewApp so she can connect with them. There’s a button labeled “import contacts from Facebook.” Alice clicks that button, and she is redirected to Facebook to log in. Alice successfully logs in and is asked if she wants to share her Facebook friend list with NewApp. She clicks yes, and is forwarded back to NewApp along with a token. NewApp now has permission (with the token) to access Alice’s friend list, without her sharing her credentials directly with NewApp. This eliminates the risk of NewApp logging into Facebook on Alice’s behalf and doing things she wouldn’t want (posting status updates, changing her password, etc.).
OAuth 1.0 (2010) lets an end user grant an app limited access to resources on a third-party server that an authority owns.
a) App to end user: We'd like to access your pictures on some other server. b) The end user and authority speak for a moment. c) Authority to app: Here is an access token. d) App to third-party server: Here is the access token that proves I am allowed to access pictures for an end user.
Oauth facilitates automated access to a permissioned resource within a container (e.g. CRUD ops on a file or record through a web api).
OAuth 2.0 (2012) does the same thing as OAuth 1.0 but with a completely new protocol.
OAuth 2.0 is actually giving a way for users to allow an application/client to access their own resources on their behalf. In other words, OAuth 2.0 is authorizing clients, not users, to access the resources. The Authorization Policy (granting user access to resources) is supposed to be existing prior to deploying OAuth.
SAML is the oldest standard of the three, originally developed in 2001. SAML, pronounced “sam-el,” stands for Security Assertion Markup Language. It’s an open standard that provides both authentication and authorization.
SAML 2.0 is an XML-based protocol that uses security tokens containing assertions to pass information about a principal (usually an end user) between a SAML authority, named an Identity Provider, and a SAML consumer, named a Service Provider. SAML 2.0 enables web-based, cross-domain single sign- on (SSO), which helps reduce the administrative overhead of distributing multiple authentication tokens to the user.
Similar to the terminology of the other two standards, SAML defines a principal, which the end user is trying to access a resource. There is a service provider, which is the web server that the principal is trying to access. And there is an identity provider, which is the server that holds the principal’s identities and credentials.
The SAML 2.0 specification defines assertions (as discussed above); protocols, which are assertion requests and responses; bindings, or how these requests and responses happen between the service provider and identity provider, using standard communication methods (e.g. HTTP POST); and profiles, which are combinations of assertions, protocols and bindings for various use cases, like SSO. An SSO use case might look like this: Alice is a manager at Acme Corp. She accesses Acme Corp’s intranet portal, where she logs in with her credentials. After logging in, she can click on a number of links that may be of interest to her (payroll, company news, Salesforce, etc.). She clicks on the Salesforce link, which contains a SAML assertion about Alice. She is forwarded to Salesforce, which receives the SAML assertion. Salesforce trusts Acme Corp, and thus trusts the assertion. Using information in the token, Alice is automatically logged in, and the appropriate data is shown to her based on attributes in the assertion.
Some of the SAML and OAuth terms are for similar concepts. Below is a list that should clarify the similarities. SAML terms with OAuth equivalents in brackets:
Systems which already use SAML for both authentication and authorization and want to migrate to OAuth as a means of authorization will be facing the challenge of integrating the two together. It makes sense for such systems to keep using SAML as it is already set up as an aut hentication mechanism.
The implemented solution has the same flow as described in the following article: SAML 2.0 Bearer Assertion Flow for OAuth 2.0.
These three options are summarized in the table. Our application implements IdentityServer, a .NET framework that implements both OAuth2 and OpenID Connect.
|Token (or assertion) format||JSON||JSON or SAML2||XML|
|Current version||OpenID Connect||OAuth2||SAML 2.0|
|Transport||HTTP GET and HTTP POST||HTTP||HTTP Redirect (GET) binding, SAML SOAP binding, HTTP POST binding, and others|
Identity providers have a log of OpenID logins, making a compromised account a bigger privacy breach
OAuth 2.0 does not support signature, encryption, channel binding, or client verification. Instead, it relies completely on TLS for confidentiality.
|XML Signature Wrapping to impersonate any user|
|Best suited for||Single sign-on for consumer apps||API authorization||Single sign-on for enterprise
Note: not well suited for mobile