Platform

Platform overview How it works Authorization testing Evidence & reports Private scanning Integrations

Solutions

Security agencies Product teams Regulated industries Partner programme

Learn

Blog Knowledge hub Compare

Resources

Pricing Documentation FAQ Security & data What we haven’t proved

Company

About Contact Careers Sign in to the platform Start a $199 pilot

Home / Knowledge hub / OAuth

Knowledge hub

OAuth

The standard behind every sign in with and connect your account button.

What it means

OAuth sits behind every sign in with and connect your account button. Rather than handing one application the password for another, you approve a set of permissions at the second service. The first then receives a token that does those things and nothing more.

RFC 6749 describes this as adding an authorisation layer that separates the client from the resource owner. The word to hold on to is delegation. OAuth grants limited access on your behalf, and it never set out to tell an application who you are.

Why it matters

It removes the worst habit in integrations, which is one system storing another system's password. You grant access narrowly, and you withdraw it from one application without touching any of the others.

The misunderstanding does real damage. Treating the arrival of a token as proof of identity is how applications sign in the wrong person. A token proves that an application received access. It says nothing about who is sitting in front of the screen.

How it shows up

Redirect handling is where the trouble lives. The provider returns the user with a code, and a loose return address lets an attacker have that code delivered somewhere they control. RFC 9700 is blunt about the fix: compare the redirect address against the registered one as an exact string, with no wildcards and no anything-on-our-domain rules.

Check four more things. A state parameter that you genuinely verify. The narrowest scopes that work. Tokens that expire and that you can revoke. And a client secret that never ships inside a mobile app or front-end code, where anyone can extract it.

Questions people ask

OAuth, answered

Is OAuth a login protocol?

No, and treating it as one causes real bugs. OAuth hands an application permission to act on somebody's behalf. Identity is a separate question.

If you want to know who the user is, use OpenID Connect, which is a layer built on top of OAuth for exactly that purpose.

What is the difference between OAuth and OpenID Connect?

OAuth answers what an application may do. OpenID Connect answers who the person is, and it issues an identity token to say so.

Most sign in with buttons you meet are OpenID Connect running over OAuth, even though everyone calls the whole thing OAuth.

Is OAuth secure?

The specification is sound and widely reviewed. Nearly every OAuth incident comes from how one application configured or interpreted it, not from the standard itself.

That is why the security best current practice, RFC 9700, spends most of its length on implementation details such as redirect matching.

Can we use a wildcard in our redirect URI?

RFC 9700 says no. It requires exact string matching, with the single exception of the port number on a localhost address used by native apps.

Pattern matching went wrong in enough real deployments that the working group removed the flexibility rather than document the traps.

Do we still need the state parameter if we use PKCE?

They cover different things. PKCE stops an intercepted authorisation code being exchanged by somebody else. State ties the response back to the request that started it, which is what RFC 6749 recommends it for.

Keep state if you rely on it for cross-site request forgery protection, and verify it rather than merely sending it.

Where does your redirect go?

Sign-in flows are one of the places we look hardest, from redirect handling to what a token actually grants, and every finding comes with the request that proved it. Ask us for a pilot.

Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.