OAuth and SSO | App Dev Guide

OAuth 2.0 is a protocol for delegated authorisation. It enables "Login with Google" flows and API access delegation. Understanding it is essential for modern applications.

OAuth 2.0: Decoupled Authentication

Traditionally, applications asked for passwords. Users typed passwords into your site. Your app sent them to a database. This works but has problems: you store passwords (breach risk), users distrust it, you manage password reset complexity.

OAuth lets someone else handle authentication. A user sees "Login with Google". They authenticate with Google (who they trust and already logged into). Google tells your app "yes, this is that user." Your app creates a session. No password on your servers.

The OAuth Authorization Code Flow

The standard OAuth flow: redirect user to Google, they authenticate, Google redirects to your site with an authorization code, your server exchanges the code for a token, you use the token to fetch user data.

This seems complex but libraries handle it. You use Auth.js or Passport.js, configure OAuth providers, add a login button. The library handles the flow.

What You Get from OAuth Login

After OAuth succeeds, you have a token and user data. The token lets you access the user's resources (if they granted permission). User data includes email, name, avatar, etc.

You create a session or local token and sign the user in. Future requests include your token, not Google's. Google's token is kept secure (usually server-side only).

OAuth Scopes and Permissions

Scopes define what the token can access. openid scope gives basic identity. email scope gives email. profile scope gives name and avatar. You request only scopes you need.

Users see the permissions you're requesting. "This app wants access to your email and calendar." They can deny. If scopes are excessive, users distrust the app.

OIDC: Identity on top of OAuth

OpenID Connect (OIDC) is an identity layer on top of OAuth 2.0. It standardizes how you get user information. Most "Login with Google" implementations use OIDC.

The distinction is subtle but important: OAuth is for authorization (what resources the app can access). OIDC is for authentication (proving who the user is).

Client Credentials Flow: Server-to-Server

Not all OAuth is for user login. The Client Credentials flow is for server-to-server authentication. One service calls another as a "client" without a user involved.

The client sends client ID and secret. The server verifies and issues a token. The client uses the token to make API calls. No user involved.

Enterprise SSO: SAML and OIDC

Large enterprises centrally manage employee access with identity providers like Okta, Azure AD, Google Workspace. These provide SAML or OIDC integrations.

When you sell to enterprises, they require SSO. "Your employees will use our identity provider to log in." Implementing SAML or OIDC support is often a sales blocker.

Libraries like @auth0/auth0-angular or next-auth support SAML and OIDC for enterprise customers. Adding enterprise SSO is usually straightforward once the foundation is there.

When to Build OAuth Login

Build OAuth login when: users have Google or GitHub accounts and you want to reduce signup friction, you need SSO for enterprise customers.

Don't build custom password management. Use OAuth or a service like Clerk. Password security is hard. Use established solutions.

When to Build SSO

Build SSO when selling to enterprises. Many large organizations won't use software without SSO. It's a sales enabler.

Implementing SSO is non-trivial. Use a library (Auth.js) and SAML/OIDC provider (Okta, Azure AD). Don't build from scratch.

Libraries for OAuth and SSO

Auth.js (formerly NextAuth): full-featured, supports OAuth, OIDC, SAML, credentials. Best for Next.js applications.

Passport.js: established, flexible, many strategies. Good for Express and Node.js.

Clerk: managed authentication service, OAuth, SAML, MFA. Good for teams wanting to outsource auth.

Auth0: comprehensive identity platform. Most expensive but most feature-rich.

Token Refresh and Security

OAuth tokens expire. When they do, refresh them with a refresh token (if the provider gave you one) or re-authenticate the user. Handle token expiry gracefully.

For browser-based applications, store tokens in HttpOnly cookies (inaccessible to JavaScript) or session storage (accessible to JavaScript but not to other sites). Each has tradeoffs.

Warning

Never implement custom OAuth flows. Use established libraries. OAuth has security subtleties. Homegrown implementations almost always have bugs. Auth.js, Passport, and Clerk are battle-tested. Use them.

Tip

For new applications, OAuth login is the default. "Login with Google" or "Login with GitHub" reduces authentication burden on users and your team. Implement it early.