SAML (Security Assertion Markup Language) and OAuth (Open Authorization) are both open standards that are used within identity management to handle authentication and authorization. Organizations including OASIS and the IETF (Internet Engineering Task Force) help to develop, publish, and maintain protocols such as SAML and OAuth.

SAML and OAuth perform different functions: SAML is used mainly for authentication (that is, to validate user identities) but can be used for authorization, whereas OAuth by itself is only designed for authorized access to resources without sharing the resource owner’s credentials.

Why are protocols needed in an IAM system?

An open standard protocol defines how authentication and authorization work in an identity ecosystem. A protocol is a way for information, such as user credentials, to be communicated between components of an identity system, such as an identity provider (IdP) and a service provider (SP, or sometimes called a relying party or RP). Standardizing the processes ensures interoperability across digital resources.

What is SAML?

SAML is an XML-based authentication protocol that handles cross-domain sign-in. A SAML Identity Provider (IDP) manages and stores user credentials and other attributes. The SAML protocol handles the exchange of digitally signed and encrypted attributes that make up user identities. These attributes are exchanged in the form of a SAML XML document; the tokenized document allows users to access an SP on request. The token shares assertions that contain the requested information, such as an email address. SPs include many web services and web applications, such as productivity web applications. SAML can handle single sign-on (SSO) using federation between an IdP and multiple SPs to deliver SAML SSO. SAML is used to pass information such as login credentials and user attributes via a SAML token when an SP requests them.

What is OAuth?

OAuth is an authorization protocol that handles the sharing of identity data via access tokens. This data is shared with third-party services, apps, and servers without sharing a user’s login credentials. OAuth2 grants, via user consent, access to identity data such as email addresses, contacts, and images. Access tokens are usually JSON web tokens.

History of SAML

SAML is a veteran authentication protocol, first published as an open standard by OASIS in 2002. One of the most successful implementations of federation and SAML SSO is in higher education, with the Shibboleth initiative and the Liberty Alliance’s Identity Federation Framework. OASIS released SAML 2.0 in 2005, and the protocol is still in use today. However, SAML is increasingly being replaced by the more modern identity protocol, OpenID Connect (OIDC), which is built on top of OAuth.

History of OAuth

OAuth was originally devised to solve an issue with delegated authentication. OAuth 1.0 was released as an open standard in 2010 and published by the IETF. By 2012, OAuth 2.0 had been released. Since then, OAuth 2.0 has found massive uptake; it’s used by companies such as Google, Amazon, Facebook, LinkedIn, Microsoft, and Netflix.

How does SAML 2.0 work?

The main components of the SAML system are:

• The user

• The IdP

• The SP

SAML 2.0 handles the communication between an IdP and the SPr. A SAML assertion is a message exchanged between an IdP) and the SP. SAML assertions underpin the SAML workflow. However, the communication must be trusted. SAML-based services use secure onboarding that requires the sharing of specific endpoints, metadata, and digital certificates to add trust. Once trusted onboarding of the IDP and SAML SP is established, the SAML authentication request and response process can begin.

SAML Workflow

The SAML workflow below is based on the exchange of a SAML assertion:

1. User wishes to access an SP.

2. The SP initiates a SAML authentication request.

3. The browser redirects this SAML authentication request to the IdP.

4. The user is asked to login to the IdP and give consent to share attributes, and so on, as requested by the SP.

5. Successful login generates a SAML token response back to the SP.

6. If the SP accepts the SAML response, the user will be logged into the service provider.

SAML provides the means to deliver federated authentication SSO, which links user identities across multiple identity management systems.

How does OAuth 2.0 work?

The main components of an OAuth 2.0 system are:

• Resource owner: The user or system that owns the resources and can grant access (consent).

• Client: The system that requires access to the resource.

• Authorization server: Receives requests from the client for access tokens and issues access tokens to the client on successful authentication and consent by the resource owner.

• Resource server: Accepts and validates access tokens.

OAuth handles authorization requests and responses between services while ensuring the confidentiality of user credentials. However, OAuth 2.0 has several different flows called grant types.

These grant types have different use cases. Three commonly used grant types are:

1. Authorization code: Involves a single-use access code, which is then exchanged for an access token.

2. Authorization code with PKCE: Can be used for mobile apps and native apps, as well as single page apps.

3. Device authorization flow: For use by apps on devices where input is constrained, for example, smart TVs.

OAuth Workflow

There are several grant types for OAuth 2. The steps below show a service requesting access to a user’s email address and profile picture:

1. The user wishes to access a service.

2. The user is redirected to the authorization server that maintains the user’s resources.

3. The user is asked to sign in and consent to the access of the resources requested by the service provider.

4. If consent is provided, the web browser is redirected back to the service with an access code.

5. The service then exchanges the access code for an access token.

6. The service uses this token to request the user’s email and profile picture.

SAML use cases

Single sign-on (SSO): SAML enables federated authentication SSO across multiple applications and services. Employees can authenticate once with their corporate credentials to access federated applications without re-entering their credentials.

Access to cloud-based apps: SAML secures access to cloud-based applications and services. SAML can be used for inter- and intra-organizational access control. This allows organizations to maintain control over user authentication while providing access to external users such as supply chain members.

Cross-organizational secure collaboration: SAML can be used to secure collaboration between organizations using identity federation.

OAuth use cases

Consented sharing between third-party apps: A user may want to allow a third-party app to access assets, such as email addresses, from a different data store. OAuth provides the means to share this data without sharing the user’s login credentials. Federated social media login typically uses OAuth 2.0 for this use case.

Smart TVs and similar devices: OAuth Device Flow provides the protocol rails to connect limited-input devices with online services and APIs.

API gateways: OAuth 2.0 can be used to control access to APIs. The gateway becomes an authorization server and issues access tokens to clients. Then, when a client requests access to an API, the gateway verifies the access token, allowing access if the token is valid.

Who uses SAML?

SAML is an older protocol. SAML was developed before mobile devices became widely used. A newer protocol, OpenID Connect (OIDC), adds support for smartphones and single-page apps (SPAs), and many organizations now use OIDC. However, many enterprises, governments, and educational establishments still use SAML 2.0. And many authentication solution providers continue to offer support for SAML 2.0. An example of a current implementation of SAML is Login.gov. U.S. government agencies use Login.gov for SSO. However, Login.gov also allows support for OIDC.

Who uses OAuth?

OAuth 2.0 is widely used across the web as the industry standard for authorization. Companies such as Facebook, Google, LinkedIn, and Twitter use OAuth 2.0 for identity data sharing and consent. OAuth has been extended by other protocols built on top of the standard. Each additional extension adds new use cases to the basic protocol:

● OpenID Connect (OpenID Foundation)

● UMA 2.0 (Kantara)

● IndieAuth (W3C)

What’s Google Sign-In?

Google Sign-In is widespread on the web and is based on OAuth. It provides simplified registration and sign-in. Users who are signed in to Google on a device or browser can then get fast authentication on a web application or website that supports Google Sign-In. Automatic one-tap sign-in for returning users is also supported. New account registration is simplified by federating with Google Sign-In.

Google has made the integration with Sign-In simple by supplying client libraries for developers. Using client libraries allows a web developer to hand off the management and handling of the OAuth 2.0 flow and token lifecycle to Google. This simple integration and the improved user experience of sign-in and registration have resulted in 3,827,591 websites using Google Identity Platform and Sign in with Google.