Authentication and authorization can be tough. They are critical aspects of granting access but extremely difficult to get right, with poor implementations resulting in disastrous consequences. In the past, developers were forced to build these access control mechanisms internally. After all, every app, machine, and service benefits from having some sort of access control.

But as the industry realized that everyone was building the same thing, they began to standardize. This resulted in SSO and its derivatives — SAML, OIDC, and OAuth2 — created to simplify these authentication and authorization processes.

This piece will talk about the following:

• What is SSO?

• What is SAML?

• What is OAuth2?

• What is OIDC?

• When to use which?

What is SSO?

Single Sign-On (SSO) is a way for users to be authenticated for multiple applications and services with one process.

A common example is Google SSO — once you’re signed in to Google, you can use most Google tools and services (e.g.: Google Docs, Sheets, Calendar, Chrome) without needing to sign in again. Then taking it a step further, your Google SSO authenticates you to any service that accepts Google as the identity provider (IdP).

This results in the following benefits for each party:

The User

• Does not need to reconfirm their identity each time they use a different service

• Only needs to remember one login credential instead of many for each service

• Has one form of “valid” ID accepted by most applications, machines, or services

The Service

• Does not need to persist user credentials in a database

• Does not need to deal with the users having password fatigue

• Does not need to use a cookie that is only viable within the same domain

To accomplish this, SSO services utilize standardized forms of authentication. We’ll cover some of the most common ones:

• SAML

• OAuth

• OIDC

What is SAML?

SAML (Security Assertion Markup Language) is the standardized language for authenticating users to applications and services. SAML enables SSO technology by allowing the IdP to authenticate users to service providers (SP) such as web applications and services.

Too complicated? Just think of SAML authentication as a user’s ID card, one that most apps are designed to read. Similar to a driver’s license, the government (the IdP) will have standardized the information each user provides onto the license. Because the government is trusted, many services will accept the driver’s license as a valid form of identity proving you are who you are.

The flow will look like this:

What is OAuth2?

OAuth 2.0 is an authorization framework that allows a user to grant a third-party application access to their resources on a server, without giving the application their credentials or login information. It is commonly used for granting access to APIs (Application Programming Interfaces) or other web-based services.

While SAML is for authentication, OAuth2 is for authorization. SAML gives the user access to the resource by having a third party provide the verification. OAuth2 gives a third-party access to the resource by having the user provide authorization. This is accomplished by having the OAuth authorization server provide the access token (once it has verified the entity), and then the access token is used to access the authorized resources.

Have a real life example: Slack wants to access your Google Calendar so you can access your schedule from within Slack.

In this scenario, you give Slack permission to access the resources (AKA “scopes”) it needs to get those events: maybe a Google profile (profile details, Gmail address, other related metadata), and of course Google Calendar. Slack tells you what scopes it needs to get your events, and you give Slack permission if you’re OK with that. Google then gives Slack the access token and refresh token it needs to continually send you those events everyday.

The flow will look like this:

What is OIDC?

OpenID Connect (OIDC) is an authentication protocol built on top of OAuth2. OIDC enables authentication of end-users against an authorization server, which verifies the user's identity and issues an ID token, usually a JSON Web Token (JWT). This ID token contains information about the user in the form of “claims.” As a superset of OAuth2, OIDC comes with all of OAuth2’s authorization capabilities and then adds authentication.

Like SAML, OIDC is widely used for SSO, where a user can use their credentials from one trusted identity provider to access multiple applications or services.

When to use OIDC vs. OAuth 2.0 vs. SAML?

Now that you understand the differences between the three, the next question is which one best suits your needs. While there’s no one-size-fits-all answer and edge-case circumstances exist, we are fans of using OIDC for access control.

OIDC is a common industry standard that allows the tool or platform to accept SSO everywhere. Being a superset of OAuth2, it is almost always correct to implement OIDC into your platform or application even if you only need OAuth2’s authorization capabilities. Doing so saves you headache for the future in case you ever need authentication capabilities as well.

SAML is largely on its way out because it was not designed with modern needs in mind. Its primary message exchange, XML, is cumbersome and inflexible compared to OIDC. Many mobile and web-based ecosystems do not support SAML. Today, SAML is largely used to support extremely old legacy systems that were built with SAML in mind, and it’s only done so because it’s difficult to update those systems.

Simplifying OIDC SSO Implementations

That being said, SSO with OIDC is hard. This is why organizations prefer using Pomerium for implementation, easily adding authentication and authorization to any service while supporting all IdPs. Just drop the SDK in front of the application or legacy service, plug in the IdP values, and get it working immediately.

In addition to simplifying the SSO implementation, Pomerium also adds a unique function for users to pass JWT claims data to upstream applications. This can be extremely useful for services which can’t be modified to perform verifications, such as Grafana or legacy applications.

If you want to start implementing access control to sensitive resources today, Pomerium is an open-source context-aware access gateway to secure access to exposed applications and services. Whether the devteam is spinning up a new application or trying to add access control to a legacy service, adding SSO is just an SDK away.