What are SAML, OAuth, and OIDC?

Topics

Identity Sprawl, IT Management, IAM

TL;DR

Security Assertion Markup Language (SAML) handles enterprise authentication, Open Authorization (OAuth) manages authorization by delegating access without sharing passwords, and OpenID Connect (OIDC) layers identity verification on top of OAuth 2.0. While each protocol serves a distinct purpose, modern identity architectures frequently combine all three to deliver seamless single sign-on (SSO) experiences for users and developers alike.

Understanding which protocol to use — and when — can mean the difference between a fragmented identity architecture and one that scales securely across enterprise and consumer applications. This article breaks down how SAML, OAuth, and OIDC each work, how they compare, and how to choose the right tool for your use case.

Core definitions: Authentication vs. authorization protocols

Security assertion markup language (SAML) is a standard protocol for authentication, primarily in enterprise environments. SAML allows you to log in to your company's dashboard and automatically gain access to apps like Google Workspace or Salesforce without entering another password.

Open Authorization (OAuth) is a protocol for authorization, not authentication. It allows apps to request limited access to a user's resources (like files, emails, calendars) on another system without needing the user's password. When you connect Zoom to Google Calendar or Slack to Microsoft 365, those apps don't ask for your credentials but still access your data. That's OAuth.

OpenID Connect (OIDC) is built on top of OAuth 2.0 and provides a way to verify user identity. It allows for authentication, user information retrieval, and authorization. If you've ever clicked "Sign in with Google" on a third-party website and were instantly logged in and greeted by name, that's OpenID Connect.

These protocols are not competing technologies. Developers can leverage them for web single sign-on (SSO). And modern identity architectures often combine them.

How does SAML work?

SAML is an open standard that verifies identity and supports authentication. In a typical office environment, employees must log on to access any part of the company's internal functions.

With SAML authentication complete, a user may access a suite of tools, including a corporate intranet, Microsoft 365, and a browser, without entering another password. SAML allows the user to access multiple resources under one digital signature.

Network administrators can use SAML to manage users from a central location. One password unlocks all the services a person needs and protects the company's security.

A typical SAML workflow:

Request: A user taps on a "Log in" button
Validation: The SAML and the identity provider (IdP) connect for authentication
Login: The user sees a screen waiting for the username and password data
Token creation: If the user enters the correct information, a SAML assertion (often referred to as a SAML token) moves to the service provider, which allows the user to log into the server

This workflow allows a service provider, a browser, and an IdP to trade information seamlessly. This process typically happens so quickly that the user won't notice it happening in the background.

How does OAuth work?

While "auth" can mean authentication or authorization, the OAuth protocol explicitly refers to authorization. This protocol passes authorization from one service to another while protecting someone's username and password.

Think of OAuth as a critical timesaver in an environment where the average US employee switches through an average of 13 job-critical applications 30 times a day. Employees increasingly want a way to jump from one app to another without logging in again. OAuth makes that possible.

Consider an employee with an active Google account. That person could use the same credentials to tap into data found on:

Hootsuite
SurveyMonkey
HotJar
Microsoft 365
Salesforce
Marketo
Box

The employee needs all of these web-based programs to do the job right. But that same person may be bogged down by creating (and remembering) multiple pairs of usernames and passwords. Duplicating the usernames and passwords is a security gamble. If one site fails, the user's critical data is exposed and vulnerable on all the platforms. However, logging into another site with the validation provided by the first is very different.

What are the privacy considerations with OAuth?

Some consumers worry about data mining and feel that using this tool gives companies like Meta (formerly Facebook) too much power. Each time a user selects a Meta login for other apps and sites, Meta gains more customer insight. If Meta's data is compromised, that person's additional logins could fail, too. However, most employees would be thankful for the ability to save time during busy, stressful periods.

What does an OAuth flow look like?

Request: A user clicks a "Log in" button on a web page
Choice: The client chooses the third-party authorization credentials to use
Log in: The authorization server creates an access token and sends it to the client application, which then uses it to request protected resources from the resource server
Connection: After verifying the token, the resource server grants access

How are OAuth tokens structured?

Throughout this process, the two servers pass information back and forth. OAuth often uses JavaScript Object Notation (JSON) Web Token (JWT) for tokens containing verifiable data in a structured JSON format. No matter how they are created, tokens are always encoded, usually signed, but rarely encrypted as they pass from one server to another. These tokens consist of three parts:

Header — identifies the token type and signing algorithm
Payload — contains the verifiable data in structured JSON format
Signature — used to verify the token has not been tampered with

They are base64url encoded but not encrypted by default.

OAuth client types

Client type	Description	Examples
Public clients	Applications that cannot securely maintain a client secret. They rely on different authorization flows, like Proof Key for Code Exchange (PKCE), to maintain security.	Single-page applications (SPAs) running in a web browser (e.g., JavaScript frontends); Native mobile applications (e.g., iOS, Android apps); Desktop applications
Confidential clients	Applications that can securely store and protect a client secret. They can authenticate themselves to the authorization server using their client ID and client secret, typically as part of a more secure authorization flow.	Traditional web server applications (e.g., a backend server for a website); Application Programming Interface (API) services

How does OIDC work?

OpenID Connect (OIDC) builds on OAuth 2.0 to add authentication and user identity. It lets applications verify the user's identity and access profile information via an ID token (a special type of JWT).

OIDC provides login functionality using IdPs like Google, Microsoft, or Meta, while also enabling access to APIs via OAuth.

What does an OIDC flow look like?

Login initiated: User initiates login on an app (the client)
Redirect to IdP: Redirected to the identity provider (IdP) (e.g., Google)
Sign in and consent: The User signs in and grants permission
Tokens returned: ID token and access token are returned to the app
App engages tokens: App employs the ID token to confirm identity and the access token to call APIs

How do OAuth, SAML, and OIDC compare?

OAuth, SAML, and OIDC are protocols that encourage and standardize interoperability. People use these tools to avoid an ever-expanding list of usernames and passwords that block them from accessing critical resources. For app owners, these protocols allow for easy onboarding and the ability to delegate user management. For admins, these tools mean fast integration and centralized authentication and authorization. There are, however, some very different functions involving:

Concept	Protocol(s)	Description
Authentication	SAML, OIDC	Involves a user's identity. SAML and OIDC work somewhat like house keys, granting access to the facility.
Authorization	OAuth	Involves a user's privileges. OAuth performs like the rules of the house, dictating what a person can and can't do once inside.

To explain this further, consider an employee on an average workday. That person logs in once in the morning with SAML or OIDC. That one login grants access to the entire suite of SAML/OIDC-based applications. No additional effort is required for the user to move from one to the other.

When should you use SAML, OIDC, or OAuth?

SAML and OAuth allow SSO opportunities, which are crucial in keeping today's employee workflows productive. They're not exactly alternatives, more like technologies that can work together.

Protocol	Primary function	Best use case
SAML	Authentication	Enterprise SSO across internal applications in traditional environments
OAuth	Authorization	Delegating access to resources (e.g., files, calendars) without sharing passwords
OIDC	Authentication + Authorization	Modern web and mobile apps that need both login functionality and secure API access

How do SAML and OAuth work together?

For example, in the Microsoft environment, OAuth handles authorization, and SAML handles authentication. You could use the two simultaneously to grant access (via SAML) and allow access to a protected resource (via OAuth).

OIDC extends OAuth 2.0 to include authentication. It not only tells you what the user can access, but also who the user is, combining identity and permissions. It's ideal for modern web and mobile apps that need login and secure API access.

Do all applications require authentication or authorization?

You could also eliminate these tools. Some web pages, for example, don't require either authentication or authorization.

Most businesses with digital systems need some kind of authentication and authorization system to function effectively. Users must be allowed to sign in and move throughout the company's systems as they complete their daily work.

To thoroughly compare each technology, explore the differences between SAML, OAuth, and OpenID Connect.

Seamlessly secure your applications with Okta

Discover how Okta's SSO services can simplify secure authentication for the applications your employees use daily with SAML, Sign-in Widgets, Auth SDK (a JavaScript-based library), Social Login, or Authentication APIs for any client.

Learn more about Okta's pre-built identity solutions here.

Frequently asked questions

What is the difference between SAML and OAuth?

SAML is an authentication protocol used primarily in enterprise environments to verify user identity, while OAuth is an authorization protocol that allows apps to access a user's resources on another system without requiring their password. In short, SAML confirms who you are, while OAuth determines what you're allowed to do.

Can SAML and OAuth be used together?

Yes. In environments like Microsoft's, OAuth handles authorization while SAML handles authentication. The two can work simultaneously to grant access and allow interaction with protected resources.

What is OpenID Connect and how does it relate to OAuth?

OpenID Connect (OIDC) is built on top of OAuth 2.0 and adds an authentication layer. It allows applications to verify a user's identity and retrieve profile information via an ID token, making it ideal for modern web and mobile apps that need both login functionality and secure API access.

What is the difference between a public client and a confidential client in OAuth?

The key distinction is whether an application can safely store a secret. Public clients like mobile apps and browser-based SPAs cannot, so they use flows like Proof Key for Code Exchange (PKCE) for security. Confidential clients like backend servers can store secrets securely and authenticate directly with the authorization server.

What is a SAML assertion?

After a user successfully logs in, the identity provider generates a SAML assertion — a digitally signed data package — and forwards it to the service provider. This eliminates the need for the user to re-enter credentials when moving between connected applications.

When should I use OIDC instead of SAML?

OIDC is generally preferred for modern web and mobile applications that need both login functionality and secure API access, while SAML is more commonly used in traditional enterprise environments for single sign-on across internal applications.