SAML and OAuth2 are open standard protocols designed with different, but related goals. Primarily, SAML 2.0 is designed to authenticate a user, so providing user identity data to a service. OAuth 2.0 is designed as an authorization protocol permitting a user to share access to specific resources with a service provider.

SAML (Security Assertion Markup Language) is a well-established, secure protocol, used extensively by enterprises and governments for sharing identity data. These data use XML data structures and simple HTTP or SOAP for data transport mechanisms. With SAML, an Identity Provider (IdP) provides user data (attributes, such as name, email, etc.) when requested by a service or Relying Party (RP).

Before any authentication transaction happens, the Relying Party (RP) and Identity Provider (IdP) need to establish a trust relationship. This relationship is built by exchanging a few artifacts such as metadata, specific endpoints, signing and encryption certificates, supported connection methods, etc.

Once these are established, the RP needing a user’s identity sends the IdP a form POST (or redirects) with an authentication request, within a web browser session. The IdP then authenticates the end-user with an interactive login and returns the corresponding identity data (set of credentials) in a SAML Response via a form POST back to the RP. These identity data will always include an identifier that the RP may use to identify the user. As part of this interaction, the IdP may also set up a Single Sign-On (SSO) session, so that authentication requests from other RPs may skip the interactive login step.

If the RP requires additional attributes, these may be requested within the context of the SSO session by sending an Attribute Query to the IdP.

Normally, SAML responses are digitally signed, to enable detection of data manipulation in transit, and may also be encrypted if transport encryption (HTTPS) is insufficient.

First published in 2012, OAuth 2.0, also known as OAuth2, is an authorization protocol designed to allow users to give access to their resources hosted by a service provider, without giving away credentials. The nature of the user’s resources is not defined in the protocol specifications, so they can be data or other entities. OAuth2 has a rich set of features that permit its use from a broad range of devices and applications. Also, OAuth2 is the base upon which OpenID Connect, a popular authentication protocol, is built.

In OAuth2 terminology, the service requiring access to users’ resources is the Client, and the service that can supply these resources is the Resource server. Access to user resources held by the Resource server is controlled through the use of access tokens, artifacts proving access authorization. Also, OAuth2 provides a mechanism, named scope, that limits permissions on a user’s resource.

The system that authenticates the user and ultimately responds with access tokens is the Authorization server.

Like SAML, before OAuth2 can be used, the Client and the Resource server must exchange some data with the Authorization server. At a minimum, they obtain a client ID and secret from the Authorization server and agree to the endpoints to call to get specific information.

OAuth2 is very flexible and provides a Client with a number of flows, known as grants, to get an access token. Which grant to use mostly depends on the Client type (mobile app, native app, web client, etc.) and the overall security requirements. Perhaps the most common is the Authorization Code grant, which applies when the Client application that needs to access a user’s resource is a regular Web app. The following briefly describes the interactions between the Client, the Resource server, and the Authorization server in this grant:

1. The Client redirects the user to the Authorization server requesting authorization to access the user’s resource with specific scopes.

2. The Authorization server performs an interactive login with the user, who also confirms they grant the permissions for the specified scopes.

3. The Authorization server redirects the user to the Client’s endpoint with a single-use Authorization Code.

4. The Client authenticates with the Authorization server and exchanges the Authorization Code for an access token.

5. With the access token, the Client requests the user’s resource from the Resource server.

SAML supports Single Sign-On while also supporting authorization by the Attribute Query route. OAuth is focused on authorization, even if it is frequently coerced into an authentication role, for example when using social login such as “sign in with a Facebook account”. Regardless, OAuth2 does not support SSO.

From a technical point of view, SAML defines a token format, its encryption is complicated, and the size of the exchanged messages is significant. In contrast, OAuth2 doesn't use any message encryption (it relies on HTTPS) and doesn't define a token format.

The attraction of OAuth2 lies in the ease of use and flexibility: it can be used in mobile devices, smart devices (e.g., smart TVs), Web apps, single-page apps, and so on. Many libraries are available to facilitate the integration process with different client types and service providers. SAML, in contrast, wasn’t designed with these modern applications in mind, making it more difficult to use on these systems. It is commonly used with traditional Web apps.

SAML is typically used for SSO in government and enterprise applications (identity management), where backend system processing of XML is commonplace. Many government citizen ID schemes (e.g., UK Verify) are SAML based.

OAuth2 is widely used in consumer and enterprise applications, both in authorization and authentication roles. It is typically used to authorize access to RESTful APIs, where its use of access tokens makes it simple and attractive.

Keep reading at our Intro to IAM page to explore more topics around Identity and Access Management.