Sign-in is where stolen passwords, bots, and scripted probes show up first. Authdog already issues a short-lived signed session, isolates keys per environment, and records the attempt. The rest of this section is the controls you turn on when a specific threat shows up in your traffic.
Use the tables to jump to the setting. Each row is a threat you can name, and the Authdog control that answers it.
Attack protection
These controls live on the environment. Open Authentication > Policies for thresholds, Authentication > Add-ons for a CAPTCHA, and Users > Settings for account enumeration.
| Threat | What it looks like | Authdog control |
|---|---|---|
| Credential stuffing | A list of stolen passwords tried against your users. | Device risk challenges an unrecognized device. Breached passwords reject known-bad passwords. Bot protection slows scripted sign-in. |
| Brute force | Many guesses against one account. | Brute-force protection locks the account after repeated failures and can add a progressive delay. Default is 5 failures and a 15-minute lockout. |
| Bot sign-ups | Automated clients creating accounts. | Bot detection scores sign-in and sign-up. reCAPTCHA or Turnstile challenges the hosted flows you select. |
| Account enumeration | Probes that learn which emails already have an account. | Prevent account enumeration hides whether an email is registered. |
| Compromised passwords | A user picks a password that already appeared in a breach. | Breached-password checks compare with k-anonymity and, by default, hard-block on sign-up and password change. |
| Spam accounts | Throwaway mailboxes and + aliases farming trials or a waitlist. |
Block disposable addresses, limit subaddresses, and use an allowlist, a blocklist, restricted sign-up, or a waitlist. |
Lidar raises Signals for the same patterns (brute force, bots, impossible travel, MFA fatigue) so you can triage what the policies already blocked.
Web security
The session cookie and the redirect rules are on before you configure a policy.
| Threat | What it looks like | How Authdog responds |
|---|---|---|
| Cross-site scripting | A script on your page tries to read the session. | The authdog-session cookie is HttpOnly. A short-lived JWT limits how long a stolen bearer is useful. |
| Cross-site request forgery | Another site submits a request with the user's browser. | The session cookie is SameSite=Lax, and Secure in production. |
| Open redirect | An authorization code is sent to an attacker's host. | Redirect URIs must match a verified domain exactly. |
| Stolen session | A token leaks from logs or a client. | Sessions expire. The next userinfo check honors revocation and key rotation. |
| Forged webhooks | A caller pretends an event came from Authdog. | Outbound webhooks carry X-Authdog-Signature: t=...,v1=.... Verify it before you act. |
| Lookalike sign-in page | A user types a password on a host they don't recognize. | The trusted-domain reminder shows the identity host on hosted sign-in and sign-up. |
Details and the headers you still set on your own app are in Web security.
More controls
- Session security sets token lifetime, idle timeout, and whether one user can hold sessions on several devices.
- MFA account recovery is how you reset a second factor after the authenticator is gone.
- Geo blocking rejects sign-in and sign-up from countries you mark on the map.
- Machine authentication keeps jobs and agents off user cookies.
- Rotate your API keys swaps signing keys without dropping in-flight tokens, and replaces a leaked client secret.
- Legal compliance is where your terms, privacy URL, audit trail, and DPA request sit.
What is already on
You don't enable these. They are how every environment behaves:
- Its own signing keys and user store. A leaked credential in
devcannot validate inproduction. Clients verify with the environment public key (pk_...) and never see the private key. - Edge checks. The session is validated close to the user, against that public key, before the request needs a central session store.
- Enterprise SSO and provisioning. SAML or OIDC hands authentication to the customer's identity provider. SCIM and HRIS deactivate users when they leave. See Enterprise SSO and Provisioning.
- An audit trail. Sign-ins, role changes, and provisioning updates are events you can read and forward. See Audit logs.
Next steps
- Turn on attack protection for the flows attackers hit first: sign-up, waitlist, and password reset.
- Review session security before you lengthen token lifetime.
- If a signing key or client secret has been copied, rotate it before you do anything else.
Related
| Read | To learn how to |
|---|---|
| Attack protection | Set lockout, bot, and breached-password policies |
| Bot protection | Put reCAPTCHA or Turnstile on a hosted flow |
| Lidar | Triage the Signals those policies produce |
| Sessions and tokens | See how the session JWT is issued and checked |