What Is OAuth 2.0? A Practical Guide to the Authorization Framework
OAuth 2.0 is an authorization framework — not an authentication protocol, despite how often it’s used as one. It defines how one application can get limited access to a resource on another application’s behalf, without ever handling that resource owner’s actual password.
The Actors
OAuth 2.0 defines four roles:
- Resource owner — usually a person, the one who owns the data being accessed.
- Client — the application requesting access (a web app, a mobile app, a backend service).
- Authorization server — issues tokens after verifying identity and consent.
- Resource server — the API that actually holds the data, and checks incoming tokens before responding.
In a lot of real systems the authorization server and resource server are run by the same company (Google, GitHub, Slack all do this), but the spec treats them as separate roles because they don’t have to be.
Grant Types
OAuth 2.0 defines several ways (“grants”) to actually get a token, chosen based on what kind of client is asking:
- Authorization Code — the most common flow for apps with a user present: redirect the user to the authorization server, they log in and consent, and the server redirects back with a code the client exchanges for a token. Modern implementations pair this with PKCE (Proof Key for Code Exchange) even for confidential clients, since it closes a well-known interception weakness in the original flow.
- Client Credentials — no user involved at all. A backend service authenticates directly with its own client ID and secret to get a token representing itself, not a person. This is the grant type you reach for when one of your own services needs to call another API you control.
- Implicit and Resource Owner Password Credentials — both are deprecated in current OAuth guidance (the implicit grant returns tokens directly in a URL fragment, which is hard to secure; the password grant requires the client to handle the user’s actual password, defeating much of the point of OAuth). Avoid both in new work.
Access Tokens vs. Refresh Tokens
A successful grant returns an access token — short-lived, sent on every
API request, almost always as a
bearer token in the Authorization
header. Many flows also return a refresh token — longer-lived, stored
securely, and used only to get a new access token once the old one expires,
without asking the user to log in again.
Scopes
A scope parameter lets the client request (and the resource owner grant)
a specific, limited slice of access — read:repos instead of blanket
account access, for example. Well-designed APIs enforce scopes on the
resource-server side, so a token with read:repos genuinely can’t write,
even if a client tried.
OAuth 2.0 vs. API Keys vs. Bearer Tokens
These three overlap in practice more than the names suggest:
- An OAuth 2.0 access token usually is a bearer token — the grant is how you got it, “bearer” describes how it’s sent.
- API keys skip the whole exchange: no authorization server, no grant, just a static credential issued once.
- OAuth 2.0 is worth the extra complexity when you need user consent, token expiry, and scoped access. A static API key is enough when you’re just identifying which application is calling, with no per-user permissions to manage.
Testing OAuth 2.0 (Client Credentials) in HTTP Titan
HTTP Titan’s Auth tab supports the Client Credentials grant directly: enter the token URL, client ID, client secret, and scope, then fetch a new access token on demand instead of pasting one in by hand. The token is attached to the request the same way a manually-entered bearer token would be.