Why Customer-Facing SaaS Integrations Often Need OAuth

On this page

1. The problem OAuth solves
2. Why OAuth works well for SaaS integrations
3. When OAuth isn't needed
4. What OAuth asks of you
5. Planning your first OAuth integration
6. Where Pathfix fits
7. Frequently asked questions

If you want your product to work with your customers' other tools, such as their calendar, CRM, accounting system or file storage, sooner or later you'll run into OAuth. This article explains why, and when other approaches still make sense.

The problem OAuth solves#

A customer-facing integration needs to act on behalf of a specific customer in another system. Your product might read their calendar events, create contacts in their CRM, or upload files to their storage.

To do that, your application needs permission. There are three broad ways to get it:

1. Ask for the customer's username and password. This is insecure, usually against the provider's terms, breaks when passwords change or MFA is enabled, and gives you far more access than you need.
2. Ask the customer to generate an API key and paste it into your product. This works for some developer-focused tools, but it's a poor experience for non-technical users, keys often grant broad access, and many providers don't offer them for user data.
3. Use OAuth. The customer clicks "Connect", approves specific permissions at the provider, and your application receives tokens scoped to what was approved.

For most major platforms, OAuth is the supported, and sometimes the only, way to access user data.

Why OAuth works well for SaaS integrations#

Customers never share passwords. They authenticate directly with the provider.

Access is scoped. Your app requests specific permissions, such as read-only calendar access, and the customer sees what they're approving.

Customers can revoke access from the provider's settings without changing their password.

Connections persist. With refresh tokens, integrations can keep working without the customer reconnecting every hour.

Providers know who you are. OAuth apps are registered, so providers can review, rate-limit and communicate with you.

When OAuth isn't needed#

OAuth isn't always the answer:

• Your own customers' data in your own product doesn't need OAuth; it's your authentication system's job.
• System-to-system integrations with no individual user context, such as calling a weather API with your company's key, typically use API keys or client credentials.
• Some providers only offer API keys, especially developer tools. You'll need a secure way to collect and store them.
• Customers configuring automations themselves in a third-party tool like Zapier means the tool handles authorization, not you.

What OAuth asks of you#

Supporting OAuth means:

• Registering an OAuth app with each provider, and sometimes passing a review.
• Implementing the authorization flow with state and PKCE.
• Storing tokens securely and linking them to the right customer.
• Refreshing tokens and handling rotation.
• Detecting broken connections and helping customers reconnect.
• Revoking tokens when customers disconnect.

For one provider, that's a manageable project. For ten, the differences between providers become the main source of work.

Planning your first OAuth integration#

1. Pick one provider and one feature your customers ask for most.
2. List the minimum scopes that feature needs.
3. Check the provider's app review requirements early. Some require a security assessment for sensitive scopes.
4. Design the connect experience: where the button lives, what customers see before and after, and how they disconnect.
5. Design the broken-connection experience: how you'll detect it and how customers reconnect.
6. Decide who runs the OAuth layer: your team, or managed infrastructure.

Where Pathfix fits#

Pathfix OAuth exists for exactly this: letting your customers connect their accounts so your application can call those providers' APIs. It handles the authorization flow, token storage, refresh and authenticated API passthrough across 350+ providers, using your own OAuth apps and credentials. Your application still makes the API requests and owns the integration logic.

See Pathfix OAuth, browse supported providers, or start with What Is OAuth 2.0?.

Frequently asked questions#

Can I use API keys instead of OAuth?#

Where the provider offers them and your customers are comfortable creating them, yes. For most mainstream business tools, OAuth is the expected and better-supported approach.

Will customers trust an OAuth consent screen?#

They're more likely to when the screen shows your product's name and requests only the permissions the feature needs.

Does OAuth work for team or company-wide connections?#

Many providers support admin-level authorization or app installation for a whole organization. The details vary, so check each provider's documentation.