Authdog can require a Google reCAPTCHA check on its hosted authentication flows, cutting off automated sign-up, credential stuffing, and one-time-code abuse at the front door. It is configured per environment as an add-on, so development and production can run different keys, or no protection at all.
Bot protection filters traffic before it authenticates. It complements, but does not replace, Lidar detections and rate limiting.
Enable reCAPTCHA
Create a reCAPTCHA site in the Google reCAPTCHA admin console first, and add the domain that serves your Authdog authentication pages. Then, in the Authdog console:
- Select the project and environment.
- Open Authentication > Add-ons.
- Select Google reCAPTCHA.
- Choose the version: v3 (score-based, invisible) or v2 (checkbox challenge).
- Enter the site key and the secret key.
- For v3, set the minimum score to accept.
- Select which auth flows to protect.
- Enable the add-on and save.
The add-on cannot be enabled without a site key. The site key is public and is rendered on the auth pages; the secret key is encrypted at rest, never returned to the browser, and is only decrypted server-side to verify tokens.
Protected flows
Attach a check to any of these actions:
| Action | Flow |
|---|---|
signin |
Email and password sign-in |
signup |
Email and password sign-up |
waitlist |
Waitlist registration |
magic_link |
Magic link request |
otp_verify |
One-time code verification |
otp_resend |
One-time code resend |
mfa_verify |
MFA challenge verification |
Selecting no actions protects all of them, an enabled add-on defaults to its broadest coverage.
Only the signin, signup, and waitlist pages can render a visible checkbox, so those are the only actions v2 protects. The rest need a token issued without a visible challenge, which means v3.
v2 versus v3
v3 scores every request from 0.0 (likely a bot) to 1.0 (likely a person) without any user interaction, and Authdog rejects requests scoring below your configured minimum. The default minimum is 0.5; a value outside 0.0–1.0 falls back to it. When Google echoes an action name, Authdog also requires it to match the flow being attempted, so a token minted on one page cannot be replayed on another.
v2 shows the "I'm not a robot" checkbox and returns a pass or fail with no score. Use it when you want a visible, explainable challenge on your sign-in and sign-up pages.
Start v3 at a permissive minimum, watch how real traffic scores, and tighten from there. Set the bar too high and you reject legitimate users on shared networks and privacy-hardened browsers.
Verification behavior
Authdog verifies every token server-side against Google's siteverify endpoint, forwarding the client IP when it is known.
The check fails closed when a token is missing or Google reports it invalid, when a v3 score is under the minimum, or when the echoed action does not match. The user sees a verification error and the attempt does not proceed.
The check fails open when the add-on is enabled but the secret key is missing or cannot be decrypted. A configuration mistake must not lock every user out of an environment, so the flow continues without a CAPTCHA. Verify a new configuration with a real sign-in in a non-production environment rather than assuming that "enabled" means "enforcing".
Rollout
- Configure and test in development first.
- Enable v3 on
signupandwaitlist, the flows attackers hit first. - Add
signin,magic_link, and the one-time-code actions once real-traffic scores look healthy. - Repeat in production with production-specific keys. Keys are per environment and are not copied between them.
Confirm your reCAPTCHA site lists every domain that serves your auth pages, including any custom domain. A domain mismatch makes Google reject every token, and every protected attempt then fails closed.