Home / Knowledge hub / OAuth redirect URI
Knowledge hub
OAuth redirect URI
The address a sign-in provider sends the user back to, which must be matched exactly.
What it means
An OAuth redirect URI is the address the authorisation server sends the person back to after they sign in or approve access. The authorisation code or token travels with that redirect. Each app registers the addresses it will use with the provider ahead of time.
When a sign-in starts, the app names a redirect URI in the request, and the server compares it with the registered list. If it matches, the code goes there. The security of the flow depends on this comparison being strict, as the code goes to whoever owns that address.
Why it matters
If the provider accepts an address it should not, the attacker's page receives the victim's code or token. With that, they can sign in to the victim's account in your app or call APIs on their behalf. The victim only had to click a sign-in link that looked normal.
Loose matching has caused real account takeovers on large services. The current OAuth security guidance says servers must compare redirect URIs by exact string match, with one narrow exception for the port in local native apps. Wildcards and "starts with" checks are not allowed.
How it shows up
You meet it in the app's OAuth settings in the provider's console and in your own authorisation server's client registry. Look for wildcard entries, entries for staging or localhost left in production, and addresses on domains you no longer own.
Common weaknesses: pattern or prefix matching, matching only the host, an open redirect on a registered domain that can forward the code on, and a registered sub-domain that can be taken over. Also check that a request missing the parameter does not fall back to something unsafe.
Questions people ask
OAuth redirect URI, answered
Why must the match be exact?
Because any difference can point the code at an attacker. Prefix, wildcard and host-only checks all leave room for a path or sub-domain the attacker controls.
Is a wildcard redirect URI ever acceptable?
Not in production. It is convenient for testing, but it lets an attacker choose where the code goes. Register each address in full.
How does an open redirect make this worse?
If a registered page can forward visitors anywhere, an attacker can send the code through it to their own server, even though the registered address matched exactly.
Does PKCE fix a bad redirect URI?
It helps, because a stolen code cannot be exchanged without the verifier. But it is not a substitute. The redirect check is the first control and should be strict.
How do we test redirect URI handling?
Start a sign-in with altered addresses: a different path, an extra sub-domain, a trailing difference, an encoded character. Check that each is refused and the user is not redirected.
Related
Terms that sit next to this one
Open redirect
A page that forwards visitors to any address handed to it in the URL.
PKCE
An extra check that stops a stolen OAuth code from being swapped for a token.
OpenID Connect
A sign-in layer on top of OAuth that tells your app who the user is.
Single sign-on
One company identity for many applications, granted and removed in one place.
Account takeover
An attacker ends up signed in as one of your real users.
Where does your sign-in send the code?
We test OAuth sign-in for redirect addresses that should have been refused and prove each one with the exact request. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.