What Is OAuth?

OAuth is an authorisation framework, not an authentication protocol. It lets a user grant an application limited access to their resources on another service without sharing their credentials — the mechanism behind every “connect your account” flow.

It is routinely used as though it authenticated the user, which is the single most common misunderstanding in this area and the source of real vulnerabilities. Authentication on top of OAuth is OpenID Connect, which exists precisely because OAuth alone does not provide it.

What it actually establishes

An access token represents permission to act on specified resources for a limited period. It says what the bearer may do. It does not reliably say who the user is, and treating token possession as proof of identity is where implementations go wrong.

The practical consequence: an application that authenticates users by accepting an access token and asking the provider “who does this belong to” can be fooled by a token obtained for a different application. OpenID Connect issues a separate identity token, audience-restricted and signed, for exactly this reason.

Implementation details that matter

Redirect URI validation must be exact. Loose matching permits redirecting the authorisation response to an attacker-controlled destination, delivering the code or token to them.

The state parameter must be used and verified, or the flow is open to cross-site request forgery that links an attacker's account to a victim's session.

Scopes should be minimal. Applications routinely request far broader access than they use, and users grant it because the consent screen is an obstacle rather than a decision.

The flows, and which to use

The authorisation code flow with PKCE is the correct choice for essentially all current applications — web, mobile and single-page. The code is exchanged for a token by a back channel, and the proof key prevents an intercepted code being redeemed by anyone else.

The implicit flow, which returned tokens directly in the browser, is deprecated for good reason: tokens were exposed in URLs, history and referrer headers. Applications still using it are worth migrating.

Client credentials covers machine-to-machine access where no user is involved, and resource owner password credentials — where the application collects the user’s password directly — defeats the purpose of the framework and should not be used.

Token handling after issue

Access tokens are bearer credentials: anyone holding one can use it. That makes storage and transmission the practical security question after the flow completes.

Tokens in browser local storage are reachable by any script running on the page, which makes cross-site scripting directly equivalent to account compromise. Storage in memory, or in cookies with appropriate flags, narrows that considerably.

Refresh tokens deserve more care still, since they mint new access tokens indefinitely. Rotation on use — where each refresh invalidates the previous token — makes theft detectable, because the legitimate client and the attacker cannot both continue using them.

Where to start

Review which third-party applications currently hold OAuth grants against your organisation's data, and what scopes they were given. Most tenants have accumulated more than anyone expects.

See OpenID Connect for the authentication layer. GuardsArm runs application penetration testing.