Identity Federation in SaaS: OAuth, OpenID Connect, and SAML

Identity federation simplifies user authentication by delegating it to trusted third-party Identity Providers (IdPs) like Google or Microsoft Azure AD. This approach enhances security, supports Single Sign-On (SSO), and reduces the need for multiple passwords, which are a common source of breaches. SaaS applications rely on three main protocols to implement identity federation: OAuth 2.0, OpenID Connect (OIDC), and SAML.

• OAuth 2.0: Focuses on authorisation, allowing apps to access user data securely without sharing passwords.
• OpenID Connect (OIDC): Adds an authentication layer to OAuth, verifying user identity through ID tokens.
• SAML: Designed for enterprise authentication, using XML-based assertions to provide SSO for corporate users.

Each protocol suits different needs:

• OAuth 2.0 is ideal for API access and machine-to-machine communication.
• OIDC works well for consumer apps and mobile-friendly services.
• SAML is preferred in enterprise environments with strict compliance requirements.

Choosing the right protocol depends on whether you need authentication, authorisation, or both, as well as your application’s infrastructure and audience. Hybrid approaches often combine these protocols to meet diverse requirements.

Understanding OAuth 2.0

What is OAuth 2.0?

OAuth 2.0 is a framework for authorisation that lets third-party applications access specific parts of a user’s data without needing their password. Introduced in RFC 6749 in October 2012, it replaced OAuth 1.0 by introducing a token-based system to simplify and secure the process. Instead of sharing login credentials, users grant limited permissions to an application, and in return, the service issues an access token. For example, if a marketing tool needs to use your Google Contacts, it doesn’t ask for your Google password. Instead, Google provides a token that allows access to only the data you’ve approved.

The framework is built around four core roles:

• Resource Owner: Usually the end-user who controls access to their data.
• Client: The application requesting access on behalf of the user.
• Resource Server: The server hosting the user’s data (e.g., an API).
• Authorisation Server: The system that authenticates the user and issues tokens.

This separation of roles creates a structured and secure flow for granting access.

Key Features of OAuth 2.0

OAuth 2.0 uses tokens to manage access, specifying what the application can do, for how long, and with which permissions. Tokens can either be opaque (requiring server-side validation) or structured, like JSON Web Tokens (JWT), which include verifiable information. The framework supports multiple grant types, tailored to different use cases. For instance:

• The Authorisation Code flow is ideal for server-side apps.
• The Client Credentials flow is suited for service-to-service communication.
• PKCE (Proof Key for Code Exchange), initially created for mobile apps, is now recommended for all client types to prevent security vulnerabilities like code injection. It has replaced the older Implicit flow, which is no longer advised.

Access tokens usually expire quickly to enhance security. To avoid frequent logins, refresh tokens can be used. These long-lived tokens allow applications to request new access tokens without requiring the user to log in again. This combination of short-lived and refreshable tokens makes OAuth 2.0 adaptable and secure for a range of scenarios.

Use Cases for OAuth 2.0

OAuth 2.0 is particularly effective in API-driven environments where applications need controlled access to user data. For example, when a marketing tool integrates with Google Contacts, OAuth 2.0 ensures it only gets the permissions you’ve approved, without exposing your credentials. It’s widely used in mobile apps, IoT devices, and modern microservices.

In SaaS systems, OAuth 2.0 is a common choice for securing microservices. The Client Credentials grant allows backend services to authenticate and communicate securely, even across multiple data centres, without requiring user interaction. The framework’s ability to define specific scopes ensures that third-party applications can only access limited resources, such as “read-only” access to a calendar, rather than full control. This precision makes OAuth 2.0 a go-to solution for secure and delegated access.

OpenID Connect: Authentication Built on OAuth 2.0

What is OpenID Connect?

OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0. While OAuth 2.0 focuses on granting access to resources, it doesn’t confirm who the user is. That’s where OIDC steps in, verifying user identity through an ID Token. This ID Token is a JSON Web Token (JWT) that carries verifiable claims about the user. As the OpenID Connect Core 1.0 Specification explains:

“OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.”

OIDC also clears up ambiguities left by OAuth 2.0 by standardising processes like endpoint discovery. This is achieved through a well-known configuration document, typically located at https://<domainURL>/.well-known/openid-configuration. It also supports dynamic client registration, laying the groundwork for its more advanced capabilities.

Key Features of OpenID Connect

At the heart of OIDC is the ID Token, formatted as a JWT with three parts: header, payload, and signature. This token includes key claims:

• iss (issuer): Identifies the entity that issued the token.
• sub (subject): A unique identifier for the user, which is never reassigned and must not exceed 255 ASCII characters.
• aud (audience): Specifies the intended recipient, typically the client’s ID.
• exp (expiration time): Indicates when the token becomes invalid.
• iat (issued-at time): Shows when the token was issued.

OIDC also introduces standard scopes such as openid, profile, email, address, and phone. Each scope determines the type of claims returned. Additionally, OIDC defines a UserInfo Endpoint, a protected resource where applications can use access tokens to retrieve more identity details about the user.

Unlike the XML-heavy SAML, OIDC’s JSON-based structure aligns with modern API and mobile-first architectures. Another standout feature is the ability to validate ID Tokens locally using the provider’s public key. This eliminates the need for constant server calls, reducing latency and boosting performance.

Use Cases for OpenID Connect

OIDC’s features make it ideal for a variety of scenarios. One prominent use case is enabling Single Sign-On (SSO) for SaaS applications. With OIDC, users can log in once through an OpenID Provider (like Google or Microsoft) and seamlessly access multiple connected apps without re-entering credentials. The ID Token ensures each app gets verified identity details, while access tokens handle permissions for resources.

Mobile and native applications particularly benefit from OIDC’s design. Unlike SAML, which struggles outside browser-based environments, OIDC was crafted with mobile and native apps in mind. When paired with the Authorisation Code flow and PKCE, it offers robust security against threats like code injection attacks.

OIDC also shines in API-driven setups where user identity verification is crucial before granting access. Its JWT format allows applications to quickly extract and verify claims without additional network requests. This makes it a great fit for microservices architectures, where distributed systems need to trust the same authentication and identity data across multiple services.

SAML: Enterprise Authentication for SaaS

What is SAML?

SAML, or Security Assertion Markup Language, is an XML-based protocol that enables enterprise single sign-on (SSO) by authenticating user identities through digitally signed assertions. Unlike OAuth 2.0, which focuses on authorisation, SAML is designed specifically for authentication – verifying who the user is.

Cloudflare explains it this way:

“SAML makes single sign-on (SSO) technology possible by providing a way to authenticate a user once and then communicate that authentication to multiple applications.”

SAML operates through three main components:

• Principal: The user trying to gain access.
• Identity Provider (IdP): Services like Okta or Azure AD that authenticate the user.
• Service Provider (SP): Applications such as Salesforce or Slack that rely on the IdP for authentication.

The process works by having the Identity Provider authenticate the user and issue digitally signed XML documents, called assertions, which carry identity information. These assertions are then trusted by the Service Provider, granting the user access. The user’s browser acts as the middleman, relaying SAML requests and responses between the IdP and SP.

Key Features of SAML

SAML’s functionality is built on digitally signed assertions (authentication, attribute, and authorisation), secured using X.509 certificates and RSA-SHA256 for data integrity.

Key features include:

• SP-initiated and IdP-initiated flows: These allow flexibility in how authentication begins. The relayState parameter plays a critical role here, enabling deep linking by redirecting users back to the specific resource they originally requested.
• XML metadata files: These simplify configuration by providing a standard way to exchange setup information between IdPs and SPs.
• Security mechanisms: Features like audience restrictions ensure tokens are only valid for the intended application, while timestamp constraints (NotOnOrAfter) protect against replay attacks.

These security-focused elements make SAML a strong choice for enterprise environments where protecting user identities is paramount.

Use Cases for SAML

SAML’s capabilities make it a go-to solution in enterprise settings, especially where centralised user access is crucial. With a single authentication event at the IdP, employees can seamlessly access multiple tools – such as Microsoft 365, Salesforce, and Slack – without repeatedly entering passwords. This not only improves user experience but also addresses security concerns. For instance, 34% of employees admit to reusing passwords at work, which heightens the risk of credential-based attacks. Additionally, with the average person needing to remember around 100 passwords, SAML significantly reduces the cognitive load.

Regulated industries also benefit from SAML, as it centralises authentication logs. This makes it easier to track who accessed which application and when, simplifying audits and compliance checks.

However, SAML’s centralised nature does come with a drawback: it creates a single point of failure. If the Identity Provider experiences downtime or a configuration error, users could lose access to all connected applications. To avoid this, organisations are advised to maintain a secret, non-SAML administrative login URL as a contingency plan. Additionally, SaaS applications should periodically revalidate assertions (e.g., every 15 minutes) using the IsPassive parameter to ensure user accounts remain active and authorised at the IdP level.

For companies like Tucanoo Solutions Ltd, SAML plays a critical role in building secure, scalable, cloud-based applications, ensuring seamless identity federation for SaaS platforms.

Comparing OAuth, OpenID Connect, and SAML

Protocol Comparison Table

OAuth 2.0 focuses on granting limited access to resources, OpenID Connect adds user authentication on top of that, and SAML combines both authentication and authorisation, making it a go-to for enterprise Single Sign-On (SSO) setups.

The choice of data format plays a big role in usability. SAML’s reliance on XML often leads to bulky and harder-to-process assertions, whereas OAuth and OIDC leverage streamlined JSON Web Tokens (JWTs), which are better suited for mobile and modern web applications.

This table sets the stage for understanding how these protocols differ in purpose and implementation. Let’s dive deeper into their strengths and limitations.

Strengths and Weaknesses

SAML is a trusted option in enterprise environments, offering robust, centralised control and encryption that meets the needs of heavily regulated industries. Its XML-based framework ensures high security but comes with challenges. For example, updating certificates between identity providers and service providers is a tedious manual process. Additionally, its reliance on XML and SOAP makes it less suitable for mobile-friendly applications. As Fortinet puts it:

“SAML is designed to focus on enterprise security, while OAuth… is generally not a good choice for securing an enterprise of hundreds or thousands of employees”.

OpenID Connect (OIDC) excels in consumer-facing applications, such as “Sign in with Google” options. Its lightweight JSON format and developer-friendly approach make it ideal for mobile apps, single-page applications, and modern SaaS platforms. Unlike SAML, OIDC allows for dynamic public key fetching, significantly reducing administrative tasks like certificate updates. However, it may not be the best fit for enterprises already invested in SAML infrastructures.

OAuth 2.0 is the go-to protocol for granting access to APIs and enabling machine-to-machine communication. For example, when a productivity app needs to sync with a user’s calendar, OAuth is the natural choice. That said, OAuth is strictly about authorisation, not authentication. As Sherif Koussa, CEO of Software Secured, clarifies:

“OAuth was never meant to authenticate users – only to authorise applications to access user data on their behalf”.

Okta offers a helpful analogy:

“SAML and OIDC work somewhat like house keys, granting access to the facility. OAuth performs like the rules of the house, dictating what a person can and can’t do once inside”.

These protocols often complement each other rather than compete. For instance, an enterprise might use SAML for initial login and OAuth for API authorisation. This is particularly relevant as companies manage dozens, if not hundreds, of applications. Approximately 10% of organisations juggle over 200 apps, and the average UK employee switches between around 13 critical applications 30 times a day. Selecting the right protocol can make a noticeable difference in both security and productivity.

Understanding these trade-offs helps organisations align their protocol choices with their specific SaaS needs.

How to Choose the Right Protocol for Your SaaS Application

Factors to Consider

Choosing the right protocol comes down to your specific needs. For consumer apps that rely on social logins, OpenID Connect is a great fit. On the other hand, if you’re dealing with enterprise integrations that require compatibility with corporate directories, SAML is a more reliable option.

Your application’s architecture also plays a big role. Modern web apps, mobile apps, and Single Page Applications (SPAs) benefit from OpenID Connect’s lightweight JSON format and REST-based design. SAML, while dependable, uses verbose XML, which can slow down mobile performance. As Auth0 explains:

“SAML is proven, powerful and flexible, but for the requirements of [modern web apps], that flexibility and power is not [always] required”.

Take a close look at your existing infrastructure. If your clients already have legacy systems or enterprise directories, SAML integrates seamlessly into those environments. However, OpenID Connect offers a more developer-friendly experience, thanks to modern SDKs and tools. Security and compliance are also key considerations. SAML’s digitally signed XML assertions are often preferred in industries like finance, healthcare, and government, where compliance is critical.

Finally, think about whether your primary focus is authentication or authorisation. OAuth 2.0 is designed for delegated access to resources (authorisation), while OpenID Connect and SAML focus on verifying user identity (authentication). If you’re dealing with API access delegation or machine-to-machine communication, OAuth 2.0 is the way to go.

Recommendations for Different Use Cases

Your choice of protocol should align with your audience, application architecture, and infrastructure:

• OpenID Connect: Ideal for new SaaS products aimed at consumers or startups that need quick and easy integration. It’s also well-suited for applications requiring mobile compatibility. Its use of JSON Web Tokens allows microservices to validate tokens locally, reducing the need for repeated checks with an Identity Provider.
• SAML 2.0: A strong choice for enterprise customers who demand strict compliance, centralised governance, and legacy system integration. SAML also supports Just-in-Time (JIT) provisioning, which automatically creates user accounts the first time they log in via their corporate Identity Provider.
• OAuth 2.0: Best for API access delegation, machine-to-machine interactions, or enabling third-party applications to access user data without exposing passwords. For public clients like mobile apps, always implement Proof Key for Code Exchange (PKCE) to prevent interception attacks.

Many organisations adopt a hybrid approach, using an Identity Provider to bridge the gap between SAML for workforce applications and OpenID Connect for mobile-first services. This makes sense when you consider that the average user in a digital-first organisation interacts with 20 to 40 applications daily. No single protocol can cover every scenario, so blending them ensures comprehensive coverage.

Conclusion

Key Takeaways

Identity federation plays a crucial role in today’s SaaS applications. On average, users juggle between 20 and 40 applications daily, switching around 13 essential apps up to 30 times a day. Choosing the right protocol ensures smooth access while safeguarding against security risks.

• OAuth 2.0 focuses on authorisation, allowing third-party apps limited access to resources without sharing passwords.
• OpenID Connect builds on OAuth by adding an authentication layer, using JSON Web Tokens to confirm user identity.
• SAML remains a go-to for enterprises, particularly those with older systems or strict compliance needs.

Using an unsuitable protocol can expose your application to security vulnerabilities, especially as credential abuse continues to be a major concern. To avoid these risks, it’s essential to define your application’s identity needs clearly before selecting a protocol.

Next Steps

Now’s the time to map out your protocol strategy. Start by assessing your specific requirements. Are you building a mobile app for consumers or integrating with enterprise systems? Do you need authentication, authorisation, or both? These questions will guide you towards the right choice – whether it’s OpenID Connect for mobile-first solutions or SAML for enterprise setups.

If you’re ready to refine your identity federation strategy, Tucanoo Solutions Ltd (https://tucanoo.com) can help. They specialise in bespoke software development, including SaaS solutions and full-stack development, to implement a federation approach tailored to your architecture and security priorities.

FAQs

Which identity federation protocol is best for my SaaS application?

Choosing the right identity federation protocol for your SaaS application boils down to understanding your specific priorities. If federated authentication is at the top of your list, you might want to look at SAML for enterprise-grade single sign-on (SSO) or OpenID Connect if you’re working with modern web, single-page, or mobile applications. On the other hand, if your focus is on authorisation, OAuth 2.0 is often the go-to option.

Your decision should take into account factors like your application’s architecture, the kind of user experience you aim to provide, and the audience you’re catering to. For instance, SAML tends to be a favourite in enterprise setups, whereas OpenID Connect offers the adaptability needed for newer application types. Meanwhile, OAuth 2.0 shines when it comes to secure access delegation, allowing limited access to user resources without the need to share credentials.

What are the key security benefits of using OpenID Connect instead of SAML?

OpenID Connect offers notable security benefits compared to SAML, thanks to its foundation on the OAuth 2.0 framework. This modern architecture enables stronger token validation processes and ensures better integration with both mobile and web applications – key requirements in today’s SaaS-driven world.

Another advantage is its flexible authentication flows, which streamline integration with cloud-based systems. This adaptability not only simplifies deployment but also supports scalability, making it an excellent option for organisations focused on secure and efficient user authentication.

Can OAuth 2.0 handle both authentication and authorisation?

OAuth 2.0 is mainly focused on authorisation, enabling secure access to protected resources. However, it can also handle authentication when paired with protocols like OpenID Connect. Built on top of OAuth 2.0, OpenID Connect introduces an additional layer dedicated to verifying user identities, making it well-suited for authentication tasks.