Auth Plugin Setup Errors and How to Fix Them

• Most Auth Plugin setup errors trace back to a mismatched OAuth callback URL, email deliverability, or a misconfigured Protected Pages rule.
• redirect_uri_mismatch almost always means the callback URL in your Google (or GitHub) OAuth app doesn't exactly match the one Auth Plugin gave you.
• A magic link that never shows up is usually a spam-filtering problem, fixed with SPF and DKIM DNS records, not a bug in the link itself.
• An invalid OTP code is nearly always a typo, a reused code, or a code that's been replaced by a newer one.
• Protected Pages not redirecting almost always traces back to a missing or misconfigured Sign In page, not a broken shield.

If you're here because you pasted an exact error into Google, this covers the setup errors people hit most often with Auth Plugin: what causes each one and how to fix it. Auth Plugin's main setup guide has a shorter troubleshooting section already; this one goes deeper into the errors that guide doesn't fully cover.

Most setup errors trace back to one of three places: OAuth credentials that don't match between Google or GitHub and Auth Plugin, email delivery getting caught by spam filtering, or a Protected Pages rule pointing at the wrong target. Once you know which bucket you're in, the fix is usually quick.

The sections below go error by error, in the order people actually run into them: during OAuth setup, during passwordless login, and during page protection.

Because the redirect URL registered in your Google Cloud Console doesn't exactly match the callback URL Auth Plugin gives you. Google checks this string exactly, character for character, so a trailing slash or a copy-paste error is enough to trigger the mismatch.

To fix it: open your OAuth 2.0 Client ID in Google Cloud Console, go to Authorized redirect URIs, and confirm the URL there matches the one shown under Settings > OAuth in Auth Plugin exactly, with no extra characters. Save in Google Cloud Console, then re-test the sign-in flow. Don't retype the URL by hand; copy it directly from Auth Plugin's OAuth settings to avoid the typo that usually causes this in the first place.

Yes, the underlying cause is identical: a callback URL registered in your GitHub OAuth App that doesn't match what Auth Plugin expects. GitHub's OAuth App settings have their own "Authorization callback URL" field, separate from Google's console, but the fix follows the same pattern: copy the exact URL from Auth Plugin's OAuth settings into that field.

Auth Plugin's public documentation doesn't currently walk through GitHub's setup screens step by step the way it does for Google, so if you need exact screen-by-screen guidance beyond the callback URL field itself, that's worth confirming directly with the Auth Plugin team. The mismatch principle itself is the same as Google's, so checking the callback URL first is still the right starting point.

Usually because it's landing in spam, not because it failed to send. Email providers are cautious about automated login emails, and without the right DNS records in place, a real magic link can look suspicious to a spam filter.

Fix it by adding SPF and DKIM DNS records for your sending domain. This is the same root cause covered briefly in Auth Plugin's general setup guide, and it's worth checking your spam folder first before assuming anything is broken on Auth Plugin's side. If links consistently land in spam even after DNS records are correct, check Settings > Branding to confirm your support email and sender details are filled in rather than left blank, since a missing sender identity can also hurt deliverability.

Magic links are single-use and time-limited by design, so this message means the link is past its window or has already been clicked once. Requesting a fresh link resolves it immediately.

Auth Plugin doesn't publish an exact expiration window for magic links, so if you need that number documented for your own users, confirm it directly with the Auth Plugin team rather than assuming a specific figure. What's safe to tell your users generally: if a link is more than a few minutes old, requesting a new one is faster than troubleshooting the old one.

Almost always one of three things: a typo entering the digits, a code that's already been used once, or a newer code that was requested after the first one, which invalidates it. OTP systems are built to accept only the most recent unused code, so requesting a second code without realizing it silently kills the first.

The fix is simple: request one fresh code, enter it carefully, and avoid clicking "resend" more than once before trying the code you already have. Auth Plugin doesn't publish exact numbers for code expiration or maximum failed attempts before a lockout, so treat any specific timing or retry-limit claim as something to confirm with the Auth Plugin team rather than a promise to make to your own users.

This usually means one of two things: the Sign In page target configured in your Protected Pages rule doesn't exist or was renamed, or the page you expected to be protected doesn't actually match your rule's pattern. Auth Plugin's Protected Pages rules use regex-style URL matching, checked on every page load, so a pattern that's slightly off (missing a wildcard, pointing at the wrong path) will silently let a page through instead of erroring loudly.

Check two things in order: that your Sign In page's URL still matches what's configured as the redirect target, and that your protected URL pattern actually matches the page you're testing. A pattern written for /dashboard won't catch /dashboard/settings unless it's written to include it.

If magic links, password resets, or OTP codes aren't arriving at all, not just landing in spam, start with Settings > Branding and Email Preview. A support email or app name left blank, or a branding field misconfigured, can affect how transactional emails are sent, and Email Preview lets you check what's actually going out before assuming the send itself failed.

If the preview looks correct and emails still aren't arriving, that points back to the deliverability fix above: SPF and DKIM records on your sending domain. Auth Plugin doesn't publish a distinct "emails not sending at all" troubleshooting flow separate from the spam-filtering issue, so treat this as the same root cause with a different symptom until you've confirmed otherwise with the team.

Copy every URL directly instead of retyping it, test OAuth and Protected Pages in production (not just preview) before calling setup done, and set up SPF and DKIM before your first real user ever requests a magic link. Most Auth Plugin setup errors are one of these three categories, and all three are avoidable with a slower first pass through setup.

If you're setting Auth Plugin up for the first time rather than debugging an existing install, Auth Plugin's full setup guide is the better starting point; this post is for once something's already gone wrong.

What does redirect_uri_mismatch actually mean?
The callback URL registered with Google or GitHub doesn't exactly match the one Auth Plugin expects. Fix it by copying the URL directly from Auth Plugin's OAuth settings into your OAuth app's configuration.

Why do magic links go to spam?
Missing SPF and DKIM DNS records on your sending domain make automated login emails look suspicious to email providers. Adding those records fixes it.

Why does my OTP code say it's invalid even though I typed it correctly?
Requesting a new code invalidates the previous one. If you requested more than one code, only the most recent is valid.

My Protected Pages rule isn't redirecting logged-out visitors. What's wrong?
Check that your Sign In page target still exists at the configured URL, and that your protected URL pattern actually matches the page you're testing.

Does upgrading plans fix setup errors?
No. Setup errors are configuration issues, not plan limits. Check the pricing page only if you're hitting an actual identity or site limit, which shows a different, explicit message.

Most Auth Plugin setup errors come down to three root causes: a mismatched OAuth callback URL, email deliverability without SPF/DKIM, or a Protected Pages rule pointing somewhere it shouldn't. Fix the specific error using the sections above, and where Auth Plugin hasn't published an exact number (expiration windows, retry limits), confirm it directly with the team rather than guessing. If setup keeps failing after checking all of the above, that's the point to reach out for support rather than keep troubleshooting blind.