What Is OAuth? Roles, Flows, Tokens, and Security Basics

Scrapeless Scraping API uses an account API key in the x-api-token header, providing a concrete contrast with OAuth’s delegated authorization model.

What Is OAuth?

OAuth is a framework for delegated authorization. It allows an application to request limited access to protected resources without asking the user for the password of the service that owns those resources. The user interacts with the authorization server, approves the requested access, and the client receives a token rather than the user’s primary credentials.

RFC 6749 defines the OAuth 2.0 authorization framework. It describes roles, protocol endpoints, authorization grants, access tokens, and refresh tokens. Later documents update the framework and provide security guidance for current deployments.

OAuth can also authorize machine clients acting on their own behalf. The client credentials grant is designed for a confidential client accessing resources under an established service relationship. That flow is different from a user approving a third-party application.

The Four OAuth Roles

One organization may operate both the authorization server and resource server, but they remain separate protocol roles. Keeping the roles clear helps teams place validation and policy at the correct boundary.

How the Authorization Code Flow Works

1. The client creates an authorization request. It sends the browser to the authorization endpoint with a client identifier, requested scope, redirect URI, state, and PKCE challenge.
2. The authorization server handles user interaction. It authenticates the user when needed and displays the access being requested.
3. The resource owner grants or denies access. Consent and policy determine whether an authorization code is issued.
4. The browser returns to the registered redirect URI. The response includes the authorization code and state value.
5. The client validates the response. It compares state with the value bound to the initiating browser session.
6. The client exchanges the code. It calls the token endpoint with the code and PKCE verifier; a confidential client also uses its approved authentication method.
7. The authorization server issues tokens. The response commonly includes an access token and may include a refresh token under the server’s policy.
8. The client calls the resource server. The resource server validates the token and enforces scope, audience, and resource-level policy.

The authorization code is an intermediary credential, not the final API token. Sending the access token directly through the browser-facing authorization response exposes it to more front-channel surfaces. Current practice keeps the access-token exchange at the token endpoint and protects it with PKCE and client authentication where applicable.

What Is PKCE?

PKCE stands for Proof Key for Code Exchange. The client generates a high-entropy verifier for one authorization attempt and sends a derived challenge with the authorization request. During the code exchange, the client presents the verifier. The authorization server recomputes the challenge and accepts the code only when the values match.

RFC 7636 defines PKCE. It was created to protect authorization codes intercepted from public-client redirects, and current security guidance applies it broadly to authorization code flows. Use the secure challenge method supported by the standard profile rather than a plain verifier transformation.

PKCE does not replace state. PKCE binds the code exchange to the initiating client instance. State binds the authorization response to the browser interaction and helps protect against cross-site request forgery and mix-up in the client’s session handling.

Access Tokens and Refresh Tokens

An access token represents authority granted to a client. The resource server uses it to decide whether a request can access the requested resource and operation. The token can be opaque, requiring introspection or server-side lookup, or self-contained under a defined signed-token profile.

A refresh token lets a client request a new access token without another user interaction. It is normally sent only to the authorization server, not to the resource server. Refresh tokens are valuable long-lived credentials and need protected storage, client binding, rotation or replay controls defined by the server, and revocation support.

Token format is separate from OAuth flow. OAuth does not require JSON Web Tokens. An opaque access token can be preferable when immediate central policy and revocation matter. A self-contained token can reduce lookup needs but requires careful validation of issuer, audience, signature, time claims, and the profile’s allowed algorithms.

Scopes, Audience, and Consent

A scope is a string defined by the authorization server that represents a permission or access category. A client requests scopes, but the server may issue less authority based on consent and policy. Scope names should describe meaningful capabilities rather than mirror every internal endpoint.

Audience identifies the intended resource server or resource set. A token issued for one API should not be accepted by an unrelated API merely because its signature is valid. Resource servers must validate the audience and issuer they expect.

Consent is not a substitute for policy. A user should not be able to grant authority the user does not possess. The authorization server and resource server still enforce tenant, role, ownership, risk, and resource-level restrictions.

Public and Confidential Clients

A confidential client can protect credentials through an environment controlled by its operator, such as a backend service. A public client runs where a secret cannot be kept, such as a browser or installed application distributed to users. Shipping the same client secret in every copy of a public application does not make those copies confidential.

Public clients rely on PKCE, exact redirect handling, platform protections, and limited token authority rather than a shared embedded secret. Confidential clients use an authorization-server-approved authentication method at the token endpoint and must protect those credentials through a secret lifecycle.

OAuth vs API Keys

An API key usually identifies a client or project directly. It works well for a controlled server-to-server relationship where the account owner provisions the credential. OAuth adds a protocol for obtaining tokens under a grant, including user-delegated access with consent and scopes.

Use an API key when a backend service accesses its own account and the provider’s key model offers adequate restrictions. Use OAuth when third-party clients need bounded access on behalf of users, when permissions need independent revocation, or when an ecosystem requires standardized authorization flows.

Neither option is automatically secure. API keys need protected storage and restrictions. OAuth needs correct endpoint validation, redirect handling, token validation, scope design, and client-type decisions.

OAuth vs OpenID Connect

OAuth authorizes access to resources. It does not define a standard statement that the client can treat as the user’s login identity. OpenID Connect adds an authentication layer on top of OAuth and introduces the ID token, a signed assertion about the authentication event and subject.

A client should not treat an arbitrary OAuth access token as proof of login. For sign-in, use an OpenID Connect flow and validate the ID token according to the provider metadata and profile, including issuer, audience, signature, time claims, nonce when used, and the authorization response binding.

Current OAuth Security Guidance

RFC 9700 provides OAuth 2.0 security best current practice. It updates deployment guidance based on attacks and implementation experience. New systems should use authorization code flows with PKCE, exact redirect URI matching, secure browser interaction, and protected token transport.

The implicit grant exposes access tokens through the authorization response and is not the preferred design for new clients. The resource owner password credentials grant asks a client to handle the user’s password and should not be used. These older patterns may appear in legacy systems, but copying them into a new implementation discards stronger boundaries.

Common OAuth Mistakes

• Calling OAuth authentication. OAuth authorizes API access; use OpenID Connect for a standard login identity layer.
• Loose redirect URI matching. Accept only exact registered redirect URIs under the profile’s rules.
• Skipping state validation. Bind the response to the initiating browser session and reject mismatches.
• Omitting PKCE. Authorization code clients should use a fresh verifier and secure challenge for each request.
• Accepting any signed token. Resource servers must validate issuer, audience, type or profile, time, signature, and authorization claims.
• Overbroad scopes. Request and issue the smallest useful authority.
• Putting tokens in URLs. Use authorization headers over HTTPS to reduce leakage through logs and browser surfaces.

OAuth Use Cases

Implementation Checklist

1. Choose the grant for the client and use case. Interactive user delegation and service access have different trust boundaries.
2. Register exact redirect URIs. Separate environments and avoid open redirectors.
3. Use authorization code with PKCE. Generate a new verifier and state value for each authorization request.
4. Validate every response. Check state, issuer metadata where applicable, code binding, and token response fields.
5. Protect tokens. Keep them out of URLs and logs, store them for the shortest necessary period, and use secure browser or server storage patterns.
6. Enforce at the resource server. Validate token profile, issuer, audience, expiry, scope, and resource-level policy.
7. Plan revocation and incident handling. Users and administrators need a way to remove grants and disable compromised credentials.

Conclusion

OAuth separates a user’s or service’s primary credentials from the limited tokens a client uses at an API. Its roles, grants, scopes, and endpoints create a standard authorization boundary, but the protocol still depends on precise implementation. Authorization code with PKCE, exact redirects, narrowly issued tokens, correct resource-server validation, and OpenID Connect for login provide a sound foundation for current systems.