OAuth provider fix

Fix provider dashboard redirect URI settings.

Use this when the app sends the right production callback but the provider dashboard is missing it, stores it in the wrong field, or belongs to a different OAuth client.

Provider field map

Provider	Correct field to inspect	Common wrong field
Google	Authorized redirect URIs	Authorized JavaScript origins only
GitHub	Authorization callback URL	Homepage URL
Microsoft / Azure	Authentication platform redirect URI	Wrong Web vs SPA platform
HubSpot	App Auth redirect URL	Old app/domain setting after deployment
WordPress plugin	Provider redirect/callback field	Plugin documentation example or old staging URL

Before and after dashboard setting

Before

Provider dashboard:
https://staging.example.com/oauth/callback

Production app sends:
https://example.com/oauth/callback

After

Provider dashboard:
https://example.com/oauth/callback

Production app sends:
https://example.com/oauth/callback

Pattern to verify in your environment.

Before you apply this fix

Capture the app-sent redirect_uri from the actual authorization URL.
Confirm the provider dashboard belongs to the same client ID the app uses.
Confirm you are editing production, staging, or localhost intentionally.
Confirm the callback URL does not contain a secret, token, authorization code, or private data.

Verification checklist

Provider accepts the authorization URL without redirect mismatch.
Browser returns to your app or plugin callback route.
The callback receives a code or provider error that is no longer redirect-related.
Any next failure is classified separately: token exchange, invalid client, scope, or user permission.

Common false positives

Editing the right-looking provider project but the app uses another client ID.
Adding an origin when the provider needs the full callback path.
Assuming a provider will follow your website’s HTTP to HTTPS redirect before comparing callback values.
Leaving a staging callback in a production app because both domains share the same codebase.