OAuth 2.0

OAuth 2.0 is an authorization framework that enables third-party applications to obtain limited access to a user's resources without exposing their credentials. It powers 'Login with Google/Facebook/GitHub.'

Category: Security (also: Web Development, Apis)

Author: Atomic Glue Security Team

## Definition

OAuth 2.0 is an industry-standard protocol for delegated authorization. It allows a user to grant a third-party application access to their resources (e.g., their Google Drive files) without sharing their password. The protocol defines four roles: resource owner (the user), client (the application), authorization server (which issues tokens), and resource server (which hosts protected data). Access tokens are issued to the client and presented to the resource server to access data. OAuth 2.0 is not an authentication protocol by itself; it is typically combined with OpenID Connect (OIDC) for authentication.

## Grant Types (Flows)

**Authorization Code Grant**: The most common flow for web and mobile apps. The client gets a temporary code after user consent, then exchanges it for an access token. **PKCE (Proof Key for Code Exchange)**: An extension to the authorization code flow that prevents interception attacks on public clients (mobile apps, SPAs). **Client Credentials Grant**: Used for server-to-server communication where no user is involved. **Implicit Grant (Deprecated)**: Previously used for SPAs but is no longer recommended due to security concerns.

## Tokens: Access and Refresh

**Access tokens**: Short-lived tokens (typically 1 hour) that the client sends to the resource server to access data. They should never be exposed to the browser in a way that allows token theft. **Refresh tokens**: Longer-lived tokens that can be exchanged for new access tokens without requiring the user to re-authenticate. Refresh tokens can be revoked if compromised. Both tokens should be HTTP-only secure cookies or stored securely on the backend, never in JavaScript-accessible storage.

## OpenID Connect (OIDC)

OIDC is an identity layer built on top of OAuth 2.0. It adds an ID token (a JWT) that contains user identity claims. When you see 'Login with Google,' the flow is typically OAuth 2.0 with OIDC: OAuth handles authorization delegation, and OIDC handles proving identity. OIDC standardizes user info endpoints, so clients can always get user profile data the same way regardless of the provider.

## Note

Never implement OAuth from scratch. Use well-vetted libraries and SDKs. The biggest OAuth security failures come from implementing flows incorrectly, especially in mobile apps and SPAs.

## Common questions

Q: Is OAuth 2.0 an authentication protocol?

A: Strictly, no. OAuth 2.0 is an authorization delegation protocol. OpenID Connect adds authentication on top. In practice, OAuth with OIDC is used for both.

Q: What is PKCE and why is it important?

A: PKCE (Proof Key for Code Exchange) is a security extension to the authorization code flow that prevents authorization code interception attacks. It is now recommended for all OAuth clients, including web apps.

Q: Can I use OAuth for API authentication?

A: Yes. OAuth 2.0 is widely used for API authentication. The client presents a Bearer token in the Authorization header. The resource server validates the token.

## Key takeaways

• OAuth 2.0 is an authorization framework, not an authentication protocol.
• OIDC adds authentication on top of OAuth 2.0 via ID tokens (JWTs).
• Use PKCE for all public clients (SPAs, mobile apps).
• Access tokens should be short-lived; refresh tokens enable seamless renewal.

## Related entries

• [Authentication vs Authorization](atomicglue.co/glossary/authentication-vs-authorization-backend)
• [SSO](atomicglue.co/glossary/sso)
• [JWT](atomicglue.co/glossary/jwt-backend)

Last updated December 2024. Permalink: atomicglue.co/glossary/oauth-20