What is a redirect URI in OAuth?

It's the address the provider sends the user back to after they approve your login. The provider only allows addresses you pre-register, and it must match what your app sends on the request exactly — same scheme, host, and path — or the provider refuses before login even completes.

What causes a redirect_uri_mismatch error?

The redirect URI on the request doesn't exactly match one registered in the provider's console. The usual culprits are http vs https, a missing or extra trailing slash, www vs no www, or a different path. It's a character-for-character comparison, so even a tiny difference fails.

What redirect URI do I use with Oathwall?

The same one for every provider: https://sso.oathwall.com/auth/callback. You register that single HTTPS address in each provider's console. Oathwall receives the callback there, then deep-links the result back into your game — so you never register a game-specific URI at the provider.

Is the redirect URI a secret?

No. It's a public value that appears in the browser URL during login. It's not sensitive like a client secret. Its job is correctness, not secrecy — it has to match exactly, but it doesn't need to be hidden.

Glossary

What Is a Redirect URI (and how to set one for a game)?

The Oathwall TeamUpdated July 1, 20263 min read

The redirect URI is the single most common reason an OAuth integration "doesn't work" on the first try. It's a small setting with zero tolerance for typos, and a game makes it slightly trickier than a website does. Here's what it is, why OAuth insists on it, and the one value you actually register when you use Oathwall.

What a redirect URI is

When a player taps "Sign in with Google," they leave your app and land on the provider's approval screen. After they approve, the provider has to send them somewhere — and that somewhere is the redirect URI (also called the callback URL). It's the return address for the whole flow.

OAuth treats it as a security control, not just a convenience. The provider only sends users to addresses you've pre-registered in its console, and the address on each login request has to match a registered one. That's what stops an attacker from rerouting a half-finished login to a site they control. If you want the flow this sits inside, OAuth 2.0 explained walks through it end to end.

Why "exactly" means exactly

The match is character-for-character. These are all different redirect URIs as far as a provider is concerned:

https://example.com/callback
http://example.com/callback      ← http, not https
https://www.example.com/callback ← www added
https://example.com/callback/    ← trailing slash
https://example.com/Callback     ← different case in the path

Register one and send another, and the provider stops the login with a redirect_uri_mismatch before your code ever runs. It's frustrating precisely because the error is upfront and unforgiving — but that strictness is the security feature working as intended.

The game problem

A website is the redirect target — the browser is already there. A game isn't a web page, so "send the user back to a URL" doesn't obviously map to "send the user back into my running app." You can't register https://my-game/callback; there's no such web server.

The standard fix is a two-hop return. The provider redirects to a real HTTPS page you control, and that page then bounces the user back into the game through a deep link — a custom URL scheme or an iOS/Android app link. The provider only ever sees the clean HTTPS address; the game-specific hop happens after.

The redirect URI with Oathwall

This is where it gets simple. With Oathwall, the redirect URI you register at every provider is the same fixed value:

https://sso.oathwall.com/auth/callback

You paste that one HTTPS address into Google's console, into GitHub's, into Discord's — the same string everywhere. It's public, it never changes, and it's identical across providers, so there's exactly one thing to get right instead of one per provider. Oathwall receives the callback there, completes the token exchange server-side, and then hands the result back to your game through the deep link you configured in the dashboard — the scheme, path, and package that route into your build.

That division is the whole point: the provider-facing redirect URI is fixed and shared, and the game-facing return is a separate deep link Oathwall manages for you. Get the one HTTPS value pasted correctly and the most common OAuth setup error disappears.

To see where the game-facing hop happens, read deep linking in Unity, and the Unity authentication guide ties the whole return trip together.

Frequently asked questions

What is a redirect URI in OAuth?: It's the address the provider sends the user back to after they approve your login. The provider only allows addresses you pre-register, and it must match what your app sends on the request exactly — same scheme, host, and path — or the provider refuses before login even completes.
What causes a redirect_uri_mismatch error?: The redirect URI on the request doesn't exactly match one registered in the provider's console. The usual culprits are http vs https, a missing or extra trailing slash, www vs no www, or a different path. It's a character-for-character comparison, so even a tiny difference fails.
What redirect URI do I use with Oathwall?: The same one for every provider: https://sso.oathwall.com/auth/callback. You register that single HTTPS address in each provider's console. Oathwall receives the callback there, then deep-links the result back into your game — so you never register a game-specific URI at the provider.
Is the redirect URI a secret?: No. It's a public value that appears in the browser URL during login. It's not sensitive like a client secret. Its job is correctness, not secrecy — it has to match exactly, but it doesn't need to be hidden.