Your board sent a callback URL the provider does not recognise. Almost always it sent http:// while you registered https://, because the board sits behind a proxy that terminates TLS and never told the application what scheme the visitor actually used. Fix the proxy header, not the console. Read the URL out of the error message first, because it tells you exactly what was sent.
This is the failure page under putting a request board behind your SSO, which covers the setup.
What is the provider actually comparing?
A string, character for character, against a list you typed into a console. Nothing is inferred and nothing is normalised. Google says so in one sentence:
Note that the http or https scheme, case, and trailing slash ('/') must all match.
Google, Using OAuth 2.0 for Web Server Applications
Microsoft's equivalent error is AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application, and its reply URL documentation adds two rules of its own: redirect URIs "must begin with the scheme https", with narrow exceptions for localhost, and they are "case-sensitive and must match the case of the URL path of your running application".
Both providers also refuse wildcards. There is no way to register https://*.example.com/callback and be done with it, so every hostname your board answers on needs its own entry.
How do you see the URL your board actually sent?
Read it out of the error page. Google prints the offending value under "Request details" as redirect_uri=..., which is the whole diagnosis in one line. That is exactly how it appears in an open Astuto issue from October 2025, where a board behind a TLS-terminating proxy sends redirect_uri=http://mysubdomain.mymaindomain/o_auths/MYTOKEN/callback and the reporter has no way to change it.
If the error page is not showing you the parameter, pull it out of the redirect your board issues when you click the sign-in button:
curl -sSI https://support.example.com/oauth/google \
| tr '&' '\n' | grep -i 'redirect_uri'The path differs by tool, but the principle does not: your board answers the sign-in link with a 302 to the provider, and everything it is claiming about itself is in that Location header. Compare what you see there with what is registered, one character at a time.
Why does the proxy cause this?
Because the application cannot see the outside of the connection. A visitor speaks HTTPS to nginx, Caddy or Traefik; the proxy terminates TLS and speaks plain HTTP to the container on the internal network. From inside, every request genuinely arrived over HTTP, so unless the proxy passes on the original scheme in a header and the application is configured to trust it, the board builds every absolute URL it emits on http://.
That is not only an OAuth problem. The same fault sends sign-in emails with http:// links, which is what a closed Fider issue from July 2025 turned out to be, resolved in the thread by the reporter adding the missing header. The OAuth callback is just the place where it fails loudly instead of quietly.
Caddy sets X-Forwarded-Proto for you. Nginx does not, and that difference is the whole bug for a large share of the people reading this.
The fix, in order
1. Add the forwarded headers to your proxy. For nginx, inside the location block that proxies to the board:
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;2. Tell the application its own public address. Most self-hosted boards have an explicit setting for this, named something like BASE_URL, HOST_URL or APP_URL, and setting it correctly overrides the guesswork entirely. Set it to the full https:// origin with no trailing slash.
3. Reload the proxy and restart the application, then re-run the curl above and confirm the redirect_uri now begins https://.
4. Copy that exact string into the provider's console as an authorised redirect URI. Do not retype it. A trailing slash you added by hand is a fresh mismatch.
5. Wait a minute or two before testing. Both providers can take a short while to propagate a new redirect URI, and an immediate retest produces the same error and sends people back to editing config that was already correct.
One payment, no subscription, unlimited products.
How do you know it worked?
The sign-in completes and you land back on your board. That is the whole test, and it is worth doing in a private window so no existing session masks a failure.
If it still fails, the error message will have changed, and the new message matters. redirect_uri_mismatch still means the string does not match. invalid_client means the client ID or secret is wrong. access_denied means the consent screen refused, which for Google usually means the app is in testing mode and your account is not on the test users list. Do not keep editing redirect URIs when the error has stopped talking about them.
Same error, different cause
| What differs | What you see | Fix |
|---|---|---|
| Scheme | Registered https, sent http | Forwarded headers, and the app's own base URL setting |
| Trailing slash | /callback against /callback/ | Register the exact string the board emits |
| Case | /Callback against /callback | Match the case of the running application's path |
| Host | example.com against www.example.com | Register both, or redirect one to the other before sign-in |
| Port | https://example.com:443/... | Drop the default port; register the canonical form |
| New custom domain | Everything worked until yesterday | Register the new hostname, and keep the old one until links stop arriving |
| Wrong client | Correct URI, still refused | Check you are editing the same client ID the board is using, not the test one |
The custom-domain row is worth pausing on. Moving a board onto your own domain changes every callback URL it emits, and Frill.co's own custom-domain documentation ends by warning its customers about precisely that. If you have just done that move, or are stuck partway through it, your custom domain is stuck on Verifying is the adjacent failure.
The scale of the generic problem is worth knowing too: the Stack Overflow question on Microsoft's version of this error stands at 145,939 views, so if this feels like something you should have got right first time, a great many people did not either.
What if you would rather not run a callback at all?
Then the honest observation is that this failure mode belongs to applications that authenticate people, and not every support centre needs to. Docket is a static site in your own repository, so it has no OAuth client, no callback route and no session to protect: readers post without accounts, and the admin side is your git host, which already has whatever sign-in your team uses. That removes this error rather than solving it, which is a real difference and not the same as being better.
If you do want sign-in in front of a board, the case for it, and the case against, are in putting a request board behind your SSO.
Frequently asked questions
Can I register a wildcard redirect URI?
No. Neither Google nor Microsoft accepts wildcard characters in a redirect URI, so a board answering on several hostnames needs an entry for each. Google's validation rules also forbid raw IP address hosts, URL fragments and path traversal segments.
Why does it work on localhost but not in production?
Because localhost is the documented exception to the HTTPS rule on both providers, so a plain http://localhost callback is allowed. As soon as the board is on a real hostname, the scheme rule applies, and a proxy that never forwards the scheme starts producing exactly this error.
Do I need to change anything in the provider console at all?
Usually only once, to add the correct URI. The common mistake is to keep adding variations to the console to satisfy whatever the board is sending, which leaves a list of http:// entries that will be rejected anyway on Microsoft and that widen your attack surface on Google. Fix what the board sends first.
Is X-Forwarded-Proto safe to trust?
Only from a proxy you control. The header is just text from the client's point of view, so an application that trusts it from anywhere can be lied to. Every proxy worth using overwrites it on the way through rather than passing on whatever arrived, and your application should be configured to trust it from the proxy's address only.
The error mentions an out-of-band flow. What is that?
Google's older copy-and-paste OAuth flow, which it has deprecated and no longer supports. If your board is old enough to use it, no redirect URI change will help; the integration needs updating to a standard redirect flow.