OAuth 2.0 is an authorisation framework with a lot of optional parts, and the optional parts are where accounts get taken. Most findings come down to four things: loose redirect handling, a missing state parameter, public clients without PKCE, and scopes far broader than the feature needs. RFC 9700, published in January 2025 as the security best current practice for OAuth 2.0, closes each of these off explicitly.
Redirect URI validation is the main event
If an attacker can influence where the authorisation code is delivered, they have the account. Servers that match redirect URIs loosely are the usual cause: a prefix match that accepts anything starting with your domain, a wildcard in a subdomain, or an allowance for any path on a host that also has an open redirect. Chain that open redirect with the loose match and the code lands with the attacker while the user sees your genuine login. Register exact URIs, compare them exactly, and audit every one that is registered, because the entry added for a developer’s laptop three years ago is still valid today.
State, PKCE and the flows nobody replaced
The state parameter is the cross-site request forgery defence for the authorisation flow, and it only works if the server generates it, stores it against the session and rejects a mismatch. Plenty of implementations send a state value and never check it. PKCE matters for any client that cannot keep a secret, which includes every mobile app and single page application, and it is now recommended for confidential clients as well. The implicit flow, which returns tokens straight in the address bar, should be gone from anything built or maintained in the past few years, though it survives in older internal tools.
“Ask your developers for the list of registered redirect URIs and client identifiers, then read it with them. In almost every review, somebody is surprised by an entry: a test host that no longer exists but still resolves, or a partner integration set up for a pilot that ended. Each one is a valid destination for an authorisation code until you remove it.”
William Fieldhouse, Director, Aardwolf Security Ltd
Scopes, consent and long-lived access
Scope creep is a security problem before it is a product problem. An integration that needs to read a calendar should not hold permission to read every mailbox in the tenant, yet consent screens are approved quickly and rarely revisited. Review which applications hold offline access, since that is what keeps a refresh token working after the user has gone home, and check whether administrators can consent on behalf of everyone in your organisation. Where a third-party integration turns out to be excessive, the fix is usually a narrower scope rather than removing the integration, and it takes a conversation with the vendor rather than a code change.
Testing an OAuth implementation properly
Test the flow as an attacker would, with two accounts and a proxy. That means intercepting each redirect, altering the redirect URI, replaying an authorisation code, removing the state parameter, and swapping a code issued to one client for use with another. None of it is exotic and none of it appears in an automated scan, which is why API security testing covers these paths by hand. If your platform sits in front of customer data and you have never had the authorisation flow reviewed, book a penetration testing quote that names OAuth explicitly in the scope so the days are allocated to it.
Frequently asked questions about OAuth security
Two questions come up on nearly every integration review.
Is OAuth 2.0 the same as single sign-on?
Not quite. OAuth handles authorisation, and OpenID Connect adds the identity layer on top of it. Many problems appear when a team uses OAuth alone to prove who somebody is.
Does using a well known provider make you safe?
It removes some risk and leaves the rest with you. Providers implement the protocol correctly. Your registered redirect URIs, scope requests and token storage are still your responsibility.
