OAuth vs OpenID Connect: Authentication and Authorization Explained

On this page

1. Authorization vs authentication
2. What OAuth 2.0 provides
3. What OpenID Connect adds
4. Access token vs ID token
5. Validating an ID token
6. How this applies to SaaS integrations
7. Common mistakes
8. Where Pathfix fits
9. Frequently asked questions

OAuth 2.0 and OpenID Connect are often mentioned together, and the buttons that use them look the same: "Continue with Google", "Connect your Microsoft account". But they answer different questions.

• OAuth 2.0 answers: *may this application access this resource on the user's behalf?*
• OpenID Connect (OIDC) answers: *who is this user, and has the identity provider verified it?*

Confusing the two leads to real security problems, such as treating an access token as proof of identity. This guide explains the difference and how each applies to SaaS integrations.

Authorization vs authentication#

Authentication establishes identity. When a user logs in, your application learns who they are.

Authorization establishes permission. When a user connects their Google Calendar to your product, your application gains permission to read events, within the scopes the user approved.

A SaaS product typically needs both, for different reasons. Users must log in to your product (authentication). Your product may then need access to data in their other tools (authorization).

What OAuth 2.0 provides#

OAuth 2.0 is a framework for delegated authorization. Through a flow such as Authorization Code with PKCE, your application receives an access token that lets it call a provider's API within the approved scopes. It may also receive a refresh token for obtaining new access tokens later.

What OAuth does *not* provide is a standard way to identify the user. An access token is meant for the API it was issued for. Its format isn't defined by OAuth; it may be an opaque string. Your application isn't supposed to read it, and it isn't a statement about who the user is.

What OpenID Connect adds#

OpenID Connect is an identity layer built on top of OAuth 2.0. It reuses the same flows and adds:

• The openid scope, which signals that the client wants identity information.
• An ID token, a signed JSON Web Token (JWT) intended for your application, containing claims about the authentication event.
• Standard claims such as sub (a stable user identifier at that provider), iss (issuer), aud (audience), exp (expiry) and optionally profile data like email and name.
• A UserInfo endpoint for retrieving additional profile claims.
• Discovery and key publication, so clients can find endpoints and the keys used to sign ID tokens.

Access token vs ID token#

Two rules follow from this table. Don't use an access token to log users in. Don't send an ID token to an API as if it were an access token.

Validating an ID token#

If you use OIDC to log users in, validate every ID token before trusting it:

1. Verify the signature using the provider's published keys.
2. Check that iss matches the expected issuer.
3. Check that aud contains your client ID.
4. Check that the token hasn't expired.
5. If you sent a nonce in the request, check that it matches.

Use the sub claim, combined with the issuer, as the stable identifier for the user. Email addresses can change and aren't guaranteed to be unique or verified at every provider.

Most teams should use a maintained OIDC client library rather than implementing validation by hand.

How this applies to SaaS integrations#

Consider a project management product.

Logging users in. The product offers "Sign in with Google". This is authentication, and OIDC is the appropriate protocol. The product validates the ID token, finds or creates a user record, and starts its own session.

Connecting a calendar. Later, the user connects Google Calendar so tasks with due dates appear as events. This is authorization. The product needs an access token with calendar scopes, and probably a refresh token so the integration keeps working.

These can happen in one flow, by requesting openid together with API scopes, but they're often better kept separate. Users sign in with minimal permissions and grant integration access only when they enable a feature that needs it. This also means a user's login identity and their connected accounts don't have to match. A user might sign in with one account and connect a calendar from another.

Common mistakes#

Using OAuth alone for login. Calling a profile API with an access token and treating the result as a login is vulnerable to token substitution, where a token issued to a different application is accepted as proof of identity.

Parsing access tokens. Some providers issue JWT access tokens, but their structure is for the API, not your application, and can change.

Requesting every scope at sign-in. Asking for broad API access just to log in reduces trust and may trigger extra provider review.

Ignoring the issuer. If you support several identity providers, the same sub value could exist at more than one. Key users by issuer and subject together.

Where Pathfix fits#

Pathfix OAuth is focused on the authorization side: connecting your users' third-party accounts so your application can call those providers' APIs. It handles the OAuth flow, token storage, refresh and authenticated API passthrough across 350+ providers, using your own OAuth apps and credentials.

User login to your own product is a separate concern, typically handled by your authentication system or identity provider. Learn more about Pathfix OAuth or read the documentation.

Frequently asked questions#

Is OIDC a replacement for OAuth?#

No. OIDC is built on OAuth 2.0 and adds identity. Use OAuth for API access and OIDC for authentication.

Can I get both an ID token and an access token in one flow?#

Yes. Requesting the openid scope alongside API scopes returns both, subject to provider support.

Is SAML the same as OIDC?#

Both are used for single sign-on, but SAML is an older XML-based standard common in enterprise environments. OIDC is JSON-based and built on OAuth 2.0.