Protocols like SAML, OAuth, and OpenID Connect (OIDC) are foundational in digital identity and access. Each plays a distinct role, but when used together, they provide comprehensive authentication and authorization experiences for users and developers.
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.
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.
An OAuth flow:
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
Throughout this process, the two servers pass information back and forth. OAuth often uses 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: a header, payload, and signature, and they are base64url encoded but not encrypted by default.
OAuth client types
In OAuth and OIDC, applications that request authorization are known as “clients,” which are categorized based on their ability to securely store secrets:
Public clients: Applications that cannot securely maintain a client secret
Examples:
Single-page applications (SPAs) running in a web browser (e.g., JavaScript frontends)
Native mobile applications (e.g., iOS, Android apps)
Desktop applications
Public clients cannot keep secrets confidential and rely on different authorization flows, like Proof Key for Code Exchange (PKCE), to maintain security.
Confidential clients: Applications that can securely store and protect a client secret
Examples:
Traditional web server applications (e.g., a backend server for a website)
API services
Confidential clients can authenticate themselves to the authorization server using their client ID and client secret, typically as part of a more secure authorization flow.
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.
OIDC flow:
Login initiated: User initiates login on an app (the client)
Redirect to IdP: Redirected to the identity provider (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
OAuth vs. SAML and OIDC: Similarities and differences
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:
Authentication: Involves a user's identity
SAML and OIDC work somewhat like house keys, granting access to the facility.Authorization: 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.
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. 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.
References
A Survey on Single Sign-On Techniques. (2012). Procedia Technology.
Employees Switch Apps More Than 1,100 Times a Day, Decreasing Productivity. (December 2018). TechRepublic.
Stop Synching Your Contacts with Facebook. (August 2019). Mashable.
Authentication vs. Authorization. (September 2018). Medium.
Authentication vs. Authorization. (May 2020). Microsoft.
Why SAML? (Security Assertion Markup Language). (July 2018). Medium.
Understanding Authentication, Authorization, and Encryption. Boston University.
