Can we use OAuth access tokens to identify users?

Not reliably. Access tokens are meant for the API they were issued for, and their format and contents are not guaranteed for the client. Use OpenID Connect ID tokens, validated properly, for sign-in.

Which OAuth flow should we use?

For web, single-page and mobile apps where users sign in, use the authorisation code flow with PKCE. For server-to-server access without a user, use client credentials. Current security guidance (RFC 9700) recommends against the implicit flow and prohibits the resource owner password credentials grant.

SAML is an older XML-based standard still widely used for enterprise single sign-on. Many identity providers support both SAML and OIDC. New applications usually prefer OIDC, but B2B SaaS often supports SAML too because enterprise customers require it.

Should we build our own authentication?

Usually not. Use an established identity provider or a well-maintained library that implements OAuth 2.0 and OIDC, and focus on configuration, roles and user experience. Building authentication from scratch is risky.

Web Development4 min read

OAuth 2.0 vs OpenID Connect: Choosing the Right Approach for Authorisation and Sign-In

OAuth 2.0 vs OpenID Connect explained: authorisation vs authentication, access and ID tokens, which flows to use, PKCE, SAML, and common security mistakes.

OAuth 2.0 or OpenID Connect?

Use OpenID Connect when you need to sign users in and know who they are; use OAuth 2.0 when an application needs delegated, limited access to an API. Most modern apps use both: OIDC for sign-in, returning an ID token, and OAuth access tokens for calling APIs. Use the authorisation code flow with PKCE for user-facing apps and client credentials for machine-to-machine access, and rely on an established identity provider rather than building your own.

This guide is for developers and technical leads. For API protection, see API security best practices; for mobile sign-in, mobile app authentication.

Key takeaways

OAuth is for authorisation; OIDC adds authentication.
ID tokens identify users; access tokens call APIs.
Authorisation code with PKCE for user-facing apps.
Client credentials for service-to-service calls.
No implicit or password grants for new work.
Use an identity provider; validate tokens properly.

Comparison

Aspect	OAuth 2.0	OpenID Connect
Purpose	Delegated authorisation to APIs	User authentication (sign-in) on top of OAuth
Main token	Access token (plus refresh token)	ID token (a signed JWT), plus OAuth tokens
Who reads the token	The API (resource server)	The client application
User information	Not standardised	Standard claims and a UserInfo endpoint
Specification	RFC 6749 (IETF)	OpenID Connect Core 1.0 (OpenID Foundation)

Which flow to use

Scenario	Flow
Web app with a server	Authorisation code (with PKCE)
Single-page app	Authorisation code with PKCE, ideally with a backend-for-frontend holding tokens
Mobile app	Authorisation code with PKCE via the system browser
Server-to-server	Client credentials
Devices without browsers	Device authorisation grant
Legacy implicit or password flows	Replace; see RFC 9700 (IETF)

Tokens and validation

Validate ID tokens' signature, issuer, audience, expiry and nonce before trusting them. APIs should validate access tokens and check scopes and audience. Keep access tokens short-lived, store refresh tokens securely and rotate them, and never put tokens in URLs or logs. PKCE (RFC 7636) protects the authorisation code from interception (RFC 7636). OAuth 2.1, which consolidates current practice, is still an IETF draft at the time of writing.

Business customers often require single sign-on with their identity provider through OIDC or SAML, plus automated provisioning (often SCIM) and group-to-role mapping. Plan for multiple customer identity providers per tenant, and make sure users removed by the customer lose access promptly. See SaaS roles and permissions.

Hypothetical example: a SaaS adding SSO and an API

This example is hypothetical. A B2B SaaS used its own passwords and shared API keys. It moved sign-in to an identity provider using OIDC with the authorisation code flow and PKCE, added SAML and OIDC single sign-on for enterprise tenants, and replaced API keys for partner integrations with OAuth client credentials and per-client scopes. The API validated access tokens and scopes on every request.

Common mistakes

Using access tokens as proof of identity.
Implicit flow in single-page apps.
Skipping ID token validation.
Long-lived tokens stored in browser storage.
Building authentication from scratch.

Secrets management for client secrets and keys.
Multi-tenant SaaS architecture for per-tenant identity providers.
SaaS integration marketplaces for third-party app authorisation.
Secure web application development for broader practice.

Conclusion

OAuth 2.0 and OpenID Connect work together: OIDC signs users in, OAuth grants API access. Use current flows, validate tokens, keep them short-lived and rely on a proven identity provider. For implementing SSO for business customers, see enterprise SSO implementation.

Adding sign-in or securing an API?

ZSpace Labs is an India-based, remote-first technology studio working with Australian and international businesses on secure web applications and APIs and mobile apps. If it would help to plan authentication for your product, we are happy to talk it through.

Start a Project

FAQ

Common questions.

OAuth 2.0 is an authorisation framework: it lets an application obtain an access token to call an API with limited permissions. OpenID Connect (OIDC) is an identity layer on top of OAuth 2.0: it adds an ID token and standard user information so an application can sign a user in and know who they are.