Job oauth-redirect-uri-mismatch-sign-in-fails · revised 11 October 2026
Fix one social sign-in that fails with a redirect or callback error
One named sign-in provider completes login in the environments we agree: the provider accepts the callback and your app starts a signed-in session. You review and release the change.
You might be seeing
- The provider page shows an error naming a redirect URI mismatch instead of the consent screen
- Sign-in works on localhost or one environment and fails on another address
- The user returns to the app callback but is shown the login page again, with no session created
No passwords, keys, card details or admin invites needed to start.
What usually happened
The address your app sends to the provider as its return address is not exactly one of the callback addresses registered for that environment, or the app rejects the return because the stored state or code-verifier value is missing when the user comes back. Either way the sign-in cannot complete. The job traces one safe test sign-in to the first failing step and repairs only that step.
Who it’s for: A founder or product owner whose web app offers sign-in through one OAuth or OpenID Connect provider (for example Google or GitHub), and whose users are stopped at a provider error or return to the app still signed out.
Usually starts when: Sign-in worked on one address and fails after a domain change, a preview or staging deployment, a new environment or a change to the provider app. The provider shows a redirect mismatch message, or the user returns to your callback and no session starts.
The result: In each agreed environment a test user starts sign-in with the named provider, returns to your callback without a provider error and lands signed in as that user. Altered or missing state values are rejected. You receive the change, the exact list of callback addresses to register, and redacted before and after evidence.
Check whether this job fits
Answer these from your own provider console and browser. They check whether this fixed job fits; they do not need your secrets, source code or customer data.
Checks you can run yourself
Compare the two addresses character by character
Copy the callback address from the provider error page or from the browser address bar at the moment of the error. Place it beside the list in the provider console without editing either.
Look for: Differences in http versus https, a www prefix, port number, path, capital letters or a trailing slash. The provider compares the whole string.
What you get
- A pull request with the callback and handler change and a note explaining the cause
- The exact callback addresses to register for each environment, written for the person who holds the provider console
- Redacted before and after evidence for each agreed environment, including the authorisation request address with secrets removed
- Reversal steps and any limits found
Included
- One OAuth or OpenID Connect authorization-code sign-in with one named provider, in up to three agreed environments (for example local, preview and production)
- Trace one safe test sign-in and compare the redirect address your app sends with the callback addresses listed for that provider app
- Correct how the app builds its callback address for each environment, and give you the exact list to register with the provider
- Repair the app's callback handling where it drops or fails to check the state value or the code verifier, so the return completes
- Re-test each agreed environment with a test account and record redacted evidence
Not included
- Adding a new sign-in provider, or switching sign-in library or identity service
- Provider-side review or verification of your app, consent-screen publishing, or provider account recovery
- Single sign-on for business customers through SAML or directory sync
- Merging duplicate user accounts, account linking rules or user-data migration
- Changing, viewing or rotating your client secret: you keep and set it yourself
- Production deployment and changes to the provider console, which stay with your account holder
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
In each agreed environment a test user starts sign-in with the named provider, reaches the provider's sign-in page without a redirect mismatch error, and returns to the app signed in as that test user.
Evidence: A redacted screen recording or screenshots for each environment, plus the signed-in test user shown in the app.
The return address in each authorisation request matches, character for character, one of the callback addresses registered for that environment's provider app.
Evidence: The redacted authorisation request address and the registered list side by side for each environment.
A return with a missing or altered state value is rejected and creates no session; where the sign-in uses a code verifier, a return without it is also rejected.
Evidence: The test names, inputs and results, and the redacted response for each rejected case.
The diff contains no secret or token, and the existing sign-in tests, or an agreed manual check of any other provider, still pass.
Evidence: The full changed-file list, a secret scan of the diff and the test results.
Sign-off. You or your authorised maintainer review the evidence for each environment, confirm the production callback list and a test sign-in there, sign off in writing and merge. Payment follows sign-off.
If it fails. If the agreed test sign-in does not pass in an agreed environment, you do not pay for this fixed scope. If the cause is a provider status, an account problem or a different fault, we explain what we found and stop. Wider work needs a new written agreement.
When it fits, and when we stop
It fits when
- The app uses a standard authorization-code sign-in with one provider, with or without a library
- Someone on your side can edit the provider app's callback list, or apply the exact list we return
- A test account at the provider exists, and at least one non-production environment can run the sign-in with it
- The source can be inspected through an agreed company-controlled route after scope is agreed
- An authorised maintainer on your side reviews and merges the change
We stop and tell you if
- The provider reports a missing app review, a suspended app or restricted test users: that is a provider-account matter, so we explain the evidence and stop
- The failure is in the provider's own service, or sign-in is through an enterprise single sign-on connection
- The sign-in can only be tested with real customer accounts or production secrets
- The cause turns out to be a wider session or cookie fault after the provider returns, which is a different job
What could go wrong
Before merge, closing the pull request leaves your app unchanged. After merge, your maintainer can revert the commit. Callback addresses added in the provider console can be removed by your account holder; leaving an unused address registered is harmless but should be tidied.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A wider callback list or a loosened check would let a sign-in code be sent to an address you do not control. | We give your account holder only exact addresses to register, never wildcards where the provider allows exact ones, and the state and code-verifier checks stay on. The reviewer looks for any loosened check. |
| The test sign-in uses a real customer account or a production secret. | Only a test account and a non-production provider app are used. If that is impossible we stop. |
| The fix passes on the test environment but the production console list differs. | The register-this list is per environment, and acceptance includes your account holder confirming the production list and a test sign-in there. |
An independent reviewer checks that the failing step was reproduced, that state and code-verifier checks are intact, and that no secret appears in the diff or evidence. Your maintainer reviews and merges, and your account holder controls the provider console.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Your developer can compare the address the app sends with the provider's authorised list. GitHub's OAuth documentation describes how its redirect matching works. docs.github.com
- Google documents the rules for authorised redirect URIs and the redirect_uri_mismatch error. Reading them costs nothing and may solve a simple typo. developers.google.com
Questions
Do you need my client secret?
No. You keep it. We use a test account and, where possible, a separate non-production provider app whose secret you set yourself.
Can you just add a wildcard so every preview address works?
Not as a shortcut. Some providers forbid wildcards, and where they are allowed they widen where a sign-in code can be sent. We would propose a stable test address instead.
What if the provider has blocked my app?
A provider review or restriction is outside a code repair. We explain what the evidence shows and stop; your account holder resolves it with the provider.
Will you change my production console?
No. We give your account holder the exact list to register, and they apply it.
Send an enquiry
Send us
- Which provider, which environments fail, and the exact wording of the provider error, with no account details
- The callback addresses you believe are registered and the address in the browser when the error appears, with secrets and tokens removed
- Which framework or sign-in library the app uses and its version, if known
- Do not send client secrets, tokens, source code, an access invitation or customer data in the first enquiry
Later, once you agree
- The source through an agreed company-controlled route, with a branch for the pull request
- A provider test account and, if possible, a separate provider app for non-production use, with its secret held by you
- Your written approval of which environments we may test and who edits the provider console
- The name of the person who reviews and merges
You own the app, the provider developer account and the client secret. We read the source and work on a branch through a company-controlled identity, never a personal login. We never hold your client secret or sign in as a customer. Your account holder applies console changes and deploys.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “oauth-redirect-uri-mismatch-sign-in-fails” as the subject.