What Is OAuth 2.0? How It Works for SaaS API Integrations

Every modern SaaS product eventually encounters the same challenge: customers want it to connect with the tools they already use.

A project management platform might need access to a customer's Google Calendar. A reporting application might pull information from HubSpot. An accounting product might synchronize transactions with QuickBooks.

These integrations need permission to access customer data. But asking customers to share their passwords would be insecure, difficult to maintain, and often prohibited by the platforms involved.

That's where OAuth 2.0 comes in.

OAuth 2.0 is an authorization framework that allows applications to obtain limited access to resources on behalf of a user without requiring the application to know that user's password.

Understanding OAuth is essential for building SaaS integrations that are secure, reliable and capable of operating across many customer accounts.

What is OAuth 2.0?#

OAuth 2.0 is a framework for delegated authorization.

In simple terms, it allows one application to request permission to access specific resources controlled by another service.

Imagine you're building a SaaS reporting platform that needs to read a customer's Google Calendar events.

Instead of asking for their Google password, your application sends them to Google's authorization screen. The customer signs in directly with Google, reviews the requested permissions, and approves or rejects the request.

If approved, your application receives credentials that allow it to access the permitted resources through Google's APIs.

Your application never needs the customer's Google password.

Authentication and authorization are related, but different problems. OpenID Connect (OIDC), which builds on OAuth 2.0, adds standardized identity functionality.

Why SaaS applications use OAuth#

OAuth solves several problems that become particularly important as a SaaS product grows.

1. Users retain control over access#

Customers can authorize a connection without sharing their credentials. They can often revoke that connection through the provider's security settings.

2. Access can be limited#

OAuth supports scopes, which describe the permissions an application requests.

For example, an application might request permission to read calendar events without requesting permission to modify them.

The provider determines the meaning and enforcement of each scope.

3. Integrations can operate after the initial connection#

Depending on the provider and authorization grant, applications may receive refresh tokens that allow them to obtain new access tokens without asking users to reconnect every time an access token expires.

4. SaaS applications can connect many individual accounts#

An embedded integration needs to distinguish between the accounts connected by different customers.

OAuth makes delegated access possible, but the SaaS application still needs to associate each authorization with the correct tenant, user or connected account.

This last requirement is where OAuth implementations often become operationally complicated.

The four roles in OAuth 2.0#

OAuth defines four roles. Understanding them makes the authorization flow much easier to follow.

The authorization server and resource server may be operated by the same provider, but they are conceptually different roles.

Your application is the OAuth client. It requests permission, receives an access token, and uses that token to call the relevant API.

How OAuth 2.0 works: the authorization code flow#

For a server-side SaaS application, the authorization code flow is one of the most important OAuth flows to understand.

Modern implementations should use Authorization Code with PKCE, which adds protection against authorization-code interception.

Here's the process.

Step 1: The user chooses to connect an account#

A customer clicks a button such as "Connect Google Calendar" inside your SaaS application.

Your application initiates an authorization request with the provider.

The request typically includes the client identifier, redirect URI, requested scopes, response type, a state value and PKCE parameters.

Step 2: The user authorizes access#

The customer is directed to the provider's authorization server.

They may need to sign in, select an account and approve the requested permissions.

This interaction takes place with the provider, not inside your application.

Step 3: The provider redirects back#

After authorization, the provider redirects the browser to your registered redirect URI with an authorization code.

Your application must validate the state value to help protect the authorization flow against request forgery and mix-up problems.

Step 4: The application exchanges the code#

Your backend sends the authorization code and PKCE code verifier to the provider's token endpoint.

For confidential clients, client authentication may also be required.

If the exchange succeeds, the provider returns an access token and potentially other credentials, such as a refresh token.

Step 5: The application calls the API#

Your application sends the access token when requesting protected resources.

For example:

GET /calendar/v3/calendars/primary/events HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer ACCESS_TOKEN

The resource server validates the token and determines whether the request is authorized.

The application can now retrieve the permitted calendar data.

Understanding OAuth access tokens#

An access token is a credential that an application presents when accessing protected resources.

In many APIs, the token is transmitted using the HTTP Authorization header:

Authorization: Bearer ACCESS_TOKEN

Bearer tokens require careful handling because possession of a valid token may be sufficient to use it.

Access tokens should be protected from accidental exposure through logs, browser storage, analytics systems and unsecured communication channels.

They may be opaque strings or structured tokens, depending on the provider.

A common misconception is that every OAuth access token is a JWT. That is not true. OAuth does not require access tokens to use a particular format.

Applications should generally treat access tokens as credentials rather than attempting to infer their meaning from their contents.

What are refresh tokens?#

Access tokens are frequently short-lived.

When an access token expires, an API request may fail with an authorization error. Requiring the customer to repeat the entire connection process whenever that happens would make integrations frustrating and unreliable.

Refresh tokens can solve this problem.

A refresh token is a credential that, when issued and supported by the authorization server, allows an application to request another access token.

A simplified lifecycle looks like this:

1. The customer authorizes the integration.
2. The application receives an access token and possibly a refresh token.
3. The application uses the access token to call an API.
4. The access token expires.
5. The application uses the refresh token to request new credentials.
6. The integration continues without requiring another interactive authorization.

Not every provider issues refresh tokens. Some require special scopes, parameters or approval conditions. Others rotate refresh tokens, impose expiration rules or revoke credentials after periods of inactivity.

Applications must therefore handle refresh-token rotation, concurrent refresh attempts, revoked access and provider-specific error responses.

OAuth scopes and least privilege#

Scopes represent requested permissions.

For example, an integration might request permission to read customer contacts, access calendar events or manage selected files.

The exact scope names and meanings vary by provider.

A calendar integration that only displays upcoming events should not automatically request permission to delete calendars.

Requesting fewer permissions can reduce security exposure and improve user trust.

It may also make the provider's application-review process easier, although review requirements differ by provider.

A useful design principle is to request the minimum access necessary for the feature being delivered.

Some providers support incremental authorization, allowing an application to request additional permissions when a customer enables a new capability.

OAuth is not the same as login#

OAuth is frequently described as a login mechanism, but OAuth 2.0 is fundamentally about authorization.

Suppose a website receives an access token for a user's profile API. That token may allow the website to retrieve information, but it does not automatically provide a standardized, trustworthy identity assertion for logging the user in.

OpenID Connect addresses this by adding an identity layer to OAuth 2.0.

OIDC introduces concepts such as ID tokens and standardized identity claims.

For a SaaS product, the distinction matters:

• Use OAuth to obtain delegated access to another service's APIs.
• Use an appropriate authentication protocol, such as OIDC, when establishing user identity.

A product may need both, but they solve different problems.

The challenges of implementing OAuth across providers#

The basic authorization flow is relatively straightforward to understand.

The difficulty appears when a SaaS application needs to support dozens or hundreds of providers, each with different implementation details.

Provider-specific authorization requirements#

Different providers may require different scopes, authorization parameters, token endpoint authentication methods, redirect URI rules and consent configurations.

Some have unusual onboarding or application-verification requirements.

Token expiration and refresh behavior#

One provider may rotate refresh tokens. Another may invalidate a connection after a password change. Another may require customers to reconnect after an administrative policy change.

These differences need to be handled without disrupting the product experience.

Multi-tenant connection management#

A SaaS application may serve thousands of customers, each connecting one or more external accounts.

It needs a reliable mapping between its own customers and the external authorizations they granted.

A request made for Customer A must never accidentally use Customer B's credentials.

Connection health and reauthorization#

Integrations fail for reasons beyond token expiration.

Customers revoke access, administrators change permissions, apps lose approval, and providers change their requirements.

Your product needs to recognize when a connection is no longer valid and guide the customer through reauthorization.

Secure credential storage#

OAuth credentials are sensitive.

Production implementations need appropriate encryption, access controls, secure transport, auditability and safeguards against leaking tokens into application logs.

These concerns become more significant as the number of connected accounts grows.

Building OAuth integrations yourself versus using managed OAuth infrastructure#

Teams generally have two approaches.

The first is to implement and maintain each provider's OAuth integration directly.

This gives developers complete control but requires ongoing work to manage authorization, callback handling, credential storage, token refresh and provider-specific behavior.

The second is to use managed OAuth infrastructure for those common responsibilities while retaining control of the application's API logic.

This separation is useful because obtaining and maintaining authorization is a different engineering problem from building the features that use an API.

For example, a SaaS application connecting to HubSpot still needs to decide which contacts to retrieve, how to transform them and how to represent them inside its own product.

A managed OAuth layer does not automatically make those product decisions.

How Pathfix OAuth fits into this architecture#

Pathfix OAuth provides managed authorization and connection infrastructure for SaaS applications integrating with external providers.

It supports more than 350 OAuth providers and handles the authorization process, token storage, token refresh and authenticated API passthrough.

Your application continues to own the integration's business logic, including which API endpoints to call, how to process responses and what to do with the data.

For example, when building a CRM integration, your application can use Pathfix OAuth to maintain the customer's authorization while your own code implements contact synchronization, record matching or reporting.

That distinction is important: Pathfix OAuth is not a unified API that replaces provider-specific endpoints, and it does not automatically supply prebuilt business actions.

Its role is to remove the repetitive authorization infrastructure that sits underneath those integrations.

Explore Pathfix OAuth or read the developer documentation to understand the connection architecture.

OAuth security best practices#

Whether you implement OAuth directly or use managed infrastructure, several principles remain essential.

Use Authorization Code with PKCE. PKCE is recommended for modern authorization-code implementations, including confidential clients where applicable.

Validate redirect URIs and state. Follow the provider's redirect URI requirements and validate authorization responses against the request that initiated them.

Protect credentials. Keep client secrets and refresh tokens out of frontend code and public repositories. Restrict access to sensitive credentials.

Request minimal scopes. Ask for permissions that are actually required by the feature.

Use HTTPS. Protect authorization callbacks, token exchanges and API requests in transit.

Handle revocation and expiration. A connection that worked yesterday may require reauthorization today.

Separate tenant credentials. Associate every connection with the correct internal customer and enforce authorization before using it.

Avoid exposing access tokens in logs. Treat tokens as secrets even when they have short lifetimes.

The current OAuth 2.0 security best-practice guidance is an important reference when designing a production implementation.

Frequently asked questions#

Is OAuth 2.0 an API?#

No. OAuth 2.0 is an authorization framework. It describes how clients obtain and use delegated authorization. APIs may use OAuth to control access to protected resources.

Is OAuth 2.0 secure?#

OAuth 2.0 can support secure authorization when implemented correctly. Its security depends on the grant type, client architecture, token handling, redirect validation, PKCE and other implementation details.

What's the difference between OAuth and an API key?#

An API key often identifies or authorizes an application or integration through a static credential. OAuth supports delegated authorization, scoped permissions and token lifecycles. The exact security properties depend on how either approach is implemented.

Does every OAuth provider support refresh tokens?#

No. Refresh-token issuance, lifetime and rotation behavior depend on the authorization server, application type, requested permissions and provider policies.

Can OAuth connect multiple accounts for the same user?#

Yes, an application can support multiple distinct authorizations, subject to provider behavior. The application must correctly associate and manage each connection.

Final thoughts#

OAuth 2.0 makes modern SaaS integrations possible without requiring customers to surrender their passwords.

But implementing the authorization flow is only the beginning.

As a product adds providers and connected customers, the real challenge becomes keeping those authorizations secure, correctly associated and operational over time.

The strongest integration architectures separate authorization infrastructure from application-specific API behavior.

That lets developers focus on building the connected experiences their customers actually need.

Building integrations into your SaaS? Explore Pathfix OAuth to manage OAuth authorization and token lifecycles while retaining control of your API integrations.