OAuth 2.0 Explained Simply

What Is OAuth 2.0?

OAuth 2.0 is an authorization framework that allows third-party applications to access a user's resources without knowing the user's password. When you click "Sign in with Google" on a website, OAuth is what makes it work.

Before OAuth, if an application wanted to access your email contacts, you would have to give it your email password. That password granted full access, could not be scoped to specific resources, and could not be easily revoked. OAuth solves all three problems.

The Key Players

Resource Owner: You, the user who owns the data. Client: The application that wants to access your data (a website or mobile app). Authorization Server: The service that authenticates you and issues tokens (Google, Microsoft, Okta). Resource Server: The API that holds your data (Gmail API, Calendar API).

The Authorization Code Flow

This is the most common and most secure OAuth flow for web applications.

1. You click "Sign in with Google" on the client application.
2. The client redirects your browser to Google's authorization server with a request specifying what access it needs (scopes) and a redirect URL.
3. Google asks you to log in (if not already) and shows a consent screen listing what the application is requesting.
4. You approve. Google redirects your browser back to the client's redirect URL with a short-lived authorization code.
5. The client's server exchanges the authorization code (plus its own credentials) for an access token and optionally a refresh token.
6. The client uses the access token to make API requests to the resource server on your behalf.

Tokens

Access tokens are credentials that grant API access. They are typically short-lived (minutes to hours). They should be transmitted only over HTTPS and stored securely.

Refresh tokens are long-lived credentials used to obtain new access tokens when the current one expires. They must be stored with extreme care because they provide ongoing access. If a refresh token is compromised, the attacker has persistent access until the token is revoked.

ID tokens (from OpenID Connect, which layers on top of OAuth) contain information about the authenticated user. They are JWTs that include claims like the user's name, email, and unique identifier.

Scopes

Scopes limit what the access token can do. Instead of granting full access to everything, the client requests specific scopes like read:email or write:calendar. You see these listed on the consent screen. The access token is only valid for the approved scopes.

Security Considerations

Always use the authorization code flow with PKCE (Proof Key for Code Exchange). PKCE prevents authorization code interception attacks and is now recommended for all client types, including mobile and single-page applications.

Validate redirect URIs strictly. The authorization server should only redirect to pre-registered URIs. Open redirectors allow attackers to steal authorization codes.

Store tokens securely. Access tokens in browser memory (not localStorage). Refresh tokens in HttpOnly, Secure cookies or server-side storage. Never expose tokens in URLs.

Implement token revocation. When a user logs out or a token is compromised, revoke it immediately at the authorization server.

Use short-lived access tokens with refresh token rotation. Each time a refresh token is used, issue a new one and invalidate the old one. This limits the window if a refresh token is stolen.