What Is OAuth? Authorization, Tokens and PKCE Explained

OAuth is a framework for delegated authorization. It allows an application to obtain limited access to an HTTP service without asking the resource owner to hand over a password. A calendar tool, for example, can receive permission to read selected events without gaining the ability to sign in as the user everywhere. The permission is represented by an access token rather than by the user's primary credential.

Authorization is not authentication

Authentication answers who are you? Authorization answers what may you do? OAuth 2.0 was designed for the second question. A service can use OAuth during a sign-in experience, but OAuth alone does not define a standard identity claim about the person. Services that need interoperable login commonly add OpenID Connect, an identity layer built on top of OAuth 2.0. This distinction matters because accepting an access token as proof of identity can create subtle security errors.

The four roles in the basic model

• The resource owner is the party that can grant access, often the user.
• The client is the application requesting permission. In OAuth terminology, client does not necessarily mean a browser or end-user device.
• The authorization server authenticates the resource owner as needed, records consent and issues tokens.
• The resource server hosts the protected API and decides whether a presented token permits the requested operation.

These roles may be operated by the same company, but they remain logically separate. The authorization server creates the credential; the resource server enforces it. Keeping that boundary clear helps explain why an API must validate a token's issuer, audience, lifetime and permitted scope instead of merely checking that a token-shaped string exists.

What happens in an authorization-code flow

In a common browser flow, the client redirects the user to the authorization server. The user signs in there and reviews the requested permissions. The authorization server redirects the browser back with a short-lived authorization code. The client then exchanges that code at the token endpoint for an access token. The client presents the access token to the resource server on later API requests. A refresh token may also be issued so the client can obtain a new access token without repeating the complete user interaction.

Why PKCE is now part of the normal design

A stolen authorization code could otherwise be exchanged by the wrong application. PKCE addresses that risk by having the client create a secret verifier and send a derived challenge with the authorization request. The token endpoint releases tokens only when the later verifier matches the earlier challenge. Current OAuth security guidance requires PKCE for public clients and recommends it for confidential clients as well. PKCE protects the code exchange; it does not replace redirect validation, client authentication where applicable, or protection against cross-site request forgery.

Scopes, lifetimes and bearer-token risk

Scopes describe requested permissions, but their exact meaning is defined by each service. Good scopes are narrow enough for users and resource servers to understand. Access tokens should also be short-lived because many deployments use bearer tokens: possession is enough to use them. Refresh tokens deserve stronger storage and rotation controls because they can extend access beyond one access token's lifetime. Revocation behavior, token format and consent screens vary between implementations, so OAuth does not make an integration safe automatically.

The durable mental model is simple: OAuth gives software a constrained capability, not a copy of the user's master key. The security of the result depends on how narrowly that capability is defined, how safely tokens are handled and whether every participant validates the properties it is responsible for.

Sources: IETF RFC 6749: The OAuth 2.0 Authorization Framework; IETF RFC 9700: Best Current Practice for OAuth 2.0 Security; OpenID Connect Core 1.0 specification.

Corrections: Report an error at corrections@wireshaman.com.