BACKEND

Home › Glossary › Backend· 291 ·

OAuth 2.0

\\oh-awth too point oh\\n.

Filed underBackendSecurityApis

In brief · quick answer

OAuth 2.0 is an authorization framework that allows third-party applications to obtain limited access to a user's resources without exposing the user's credentials. It is the industry standard for delegated access.

§ 1 Definition

OAuth 2.0 is a framework for delegated authorization. It lets an application (the client) access resources on behalf of a user (the resource owner) without the user sharing their password with the application. Instead of credentials, OAuth 2.0 uses tokens: short-lived access tokens and optionally long-lived refresh tokens. OAuth 2.0 is not an authentication protocol. It is an authorization protocol. To authenticate users, you combine OAuth 2.0 with OpenID Connect (OIDC), which adds an ID token (a JWT containing user identity claims). OAuth 2.0 defines multiple grant types for different scenarios: Authorization Code (most common, for web and mobile apps), PKCE (Proof Key for Code Exchange, for public clients like mobile apps), Client Credentials (for server-to-server communication), Device Code (for devices without browsers), and Refresh Token (to get new access tokens without re-authenticating). The Authorization Code flow with PKCE is the recommended approach for almost all modern applications.

§ 2 The Authorization Code Flow

The Authorization Code flow is the standard OAuth 2.0 flow for web applications. The user clicks 'Sign in with Google.' Their browser is redirected to Google's authorization server. The user logs in and consents to the requested scopes (what data the app can access). Google redirects back to the application with an authorization code in the URL. The application's server exchanges this code (along with its client secret) for an access token and optionally a refresh token. This exchange happens server-to-server, so the authorization code is useless if intercepted (it requires the client secret to exchange). The access token is then used to call the Google API on behalf of the user. The access token is short-lived (typically 1 hour). The refresh token is long-lived and can be used to get new access tokens.

§ 3 OAuth 2.0 Grant Types

OAuth 2.0 defines several grant types for different scenarios. Authorization Code with PKCE is the recommended grant for all public clients (mobile apps, SPAs). PKCE adds a cryptographic challenge to the authorization code flow, preventing interception attacks. Client Credentials grant is for server-to-server communication where no user is involved (internal microservices). Device Code grant is for devices without a browser (smart TVs, CLI tools, IoT). Refresh Token grant lets clients obtain new access tokens without user interaction. The Implicit grant (deprecated) was replaced by Authorization Code with PKCE. The Resource Owner Password Credentials grant (deprecated) should not be used because it exposes user passwords to the client. Always prefer Authorization Code with PKCE for your application.

§ 4 OAuth 2.0 vs OpenID Connect

OAuth 2.0 is an authorization framework. It tells the application 'this user allowed you to access their calendars.' It does not tell the application who the user is. OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0. It adds an ID token (a signed JWT containing the user's identity: name, email, profile picture) and a UserInfo endpoint. When you 'Sign in with Google,' you are using OAuth 2.0 + OIDC. OAuth 2.0 provides the access token. OIDC provides the ID token that tells you who the user is. If you only need to identify users (not access their data on other services), OIDC alone is sufficient. If you need to call APIs on behalf of users, you need both OAuth 2.0 (access tokens) and OIDC (identity).

§ 5 Note

Common misunderstanding: OAuth 2.0 is not an authentication protocol. It is an authorization protocol. It gives access tokens that authorize API calls. It does not tell you who the user is. For authentication, combine OAuth 2.0 with OpenID Connect. Another misconception: OAuth 2.0 is 'sign in with Google.' That is OAuth 2.0 + OIDC. The 'sign in' part (identity) is OIDC. The 'access Google Calendar' part is OAuth 2.0. Also: the Implicit grant and Password grant are deprecated and should not be used for new applications.

§ 6 In code

```javascript
// Authorization Code + PKCE flow (simplified)
import { randomBytes, createHash } from 'node:crypto';

// Step 1: Generate PKCE challenge
const codeVerifier = randomBytes(32).toString('base64url');
const codeChallenge = createHash('sha256')
  .update(codeVerifier)
  .digest('base64url');

// Step 2: Redirect user to authorization server
const authUrl = new URL('https://provider.com/authorize');
authUrl.searchParams.set('client_id', process.env.CLIENT_ID);
authUrl.searchParams.set('redirect_uri', 'https://app.com/callback');
authUrl.searchParams.set('response_type', 'code');
authUrl.searchParams.set('code_challenge', codeChallenge);
authUrl.searchParams.set('code_challenge_method', 'S256');
authUrl.searchParams.set('scope', 'openid profile email');

// Step 3: Exchange code for tokens
const tokenResponse = await fetch('https://provider.com/token', {
  method: 'POST',
  headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
  body: new URLSearchParams({
    client_id: process.env.CLIENT_ID,
    client_secret: process.env.CLIENT_SECRET,
    code: authorizationCode,
    code_verifier: codeVerifier,
    redirect_uri: 'https://app.com/callback',
    grant_type: 'authorization_code'
  })
});

const { access_token, id_token, refresh_token } = await tokenResponse.json();
```

§ 7 Common questions

Q. Is OAuth 2.0 secure?: A. Yes, when implemented correctly. Always use Authorization Code with PKCE for public clients. Never use the Implicit or Password grants. Validate redirect URIs strictly. Use HTTPS everywhere.
Q. What is the difference between OAuth 2.0 and OpenID Connect?: A. OAuth 2.0 provides access tokens for API access. OpenID Connect adds identity (ID tokens with user info). OAuth 2.0 answers 'Can this app access my data?' OIDC answers 'Who is this user?'
Q. Do I need a third-party OAuth provider?: A. For social login (Google, GitHub, Apple), yes. For your own application's SSO, you can implement it yourself or use a provider like Auth0, Clerk, or Supabase Auth.

Key takeaways

OAuth 2.0 is a delegated authorization framework. It grants API access, not identity.
Authorization Code with PKCE is the recommended flow for modern applications.
Combine OAuth 2.0 with OpenID Connect (OIDC) for authentication (sign-in).
Always use HTTPS, validate redirect URIs, and rotate tokens. Never use deprecated grants.

How Atomic Glue helps

Atomic Glue implements OAuth 2.0 and OpenID Connect for social login, API access delegation, and single sign-on. We follow OAuth 2.0 best practices: Authorization Code + PKCE, strict redirect URI validation, token rotation, and least-privilege scopes. Whether you need 'Sign in with Google' or a full OAuth authorization server, our team builds secure delegated access that protects both your users and your APIs. Security integrations are part of our Web Development services. Get in touch to implement OAuth 2.0 for your application.

Get in touch

# OAuth 2.0

Category: Backend (also: Security, Apis)

Author: Atomic Glue Development Team

## Definition

## The Authorization Code Flow

## OAuth 2.0 Grant Types

## OAuth 2.0 vs OpenID Connect

## Note

## In code

## Common questions
Q: Is OAuth 2.0 secure?
A: Yes, when implemented correctly. Always use Authorization Code with PKCE for public clients. Never use the Implicit or Password grants. Validate redirect URIs strictly. Use HTTPS everywhere.
Q: What is the difference between OAuth 2.0 and OpenID Connect?
A: OAuth 2.0 provides access tokens for API access. OpenID Connect adds identity (ID tokens with user info). OAuth 2.0 answers 'Can this app access my data?' OIDC answers 'Who is this user?'
Q: Do I need a third-party OAuth provider?
A: For social login (Google, GitHub, Apple), yes. For your own application's SSO, you can implement it yourself or use a provider like Auth0, Clerk, or Supabase Auth.

## Key takeaways

OAuth 2.0 is a delegated authorization framework. It grants API access, not identity.
Authorization Code with PKCE is the recommended flow for modern applications.
Combine OAuth 2.0 with OpenID Connect (OIDC) for authentication (sign-in).
Always use HTTPS, validate redirect URIs, and rotate tokens. Never use deprecated grants.

## Related entries

Last updated June 2026. Permalink: atomicglue.co/glossary/oauth-2-0