Most of the secure path is already on. Sessions, tokens, keys, and provisioning already behave this way, before you turn anything extra on.
Per-environment key isolation and rotation
Every environment has its own signing keys, connections, and user store. A leaked credential or a mistake in one environment can't reach another. Signing keys rotate on a managed schedule. The environment's public key (pk_...) lets clients verify sessions without ever handling a private key.
Short-lived signed sessions
Sign-in issues a signed JWT, delivered as the authdog-session cookie (HttpOnly, SameSite=Lax, Secure in production) or as an Authorization: Bearer token. Sessions are short-lived and signed, so a stolen token has a small window and can't be forged. See Sessions and tokens.
Edge session validation
Sessions are validated at the edge, close to the user, before the request reaches your origin. The check is stateless against the environment's public key, so it stays fast and doesn't depend on a central session store.
MFA and breach-aware passwords
Turn on TOTP MFA when you want a second factor after the first sign-in. The password policy is breach-aware: passwords known from public breaches are rejected, so a compromised password never lands in your user store.
Enterprise SSO
You can hand authentication to a customer's identity provider over SAML 2.0 or OIDC. Okta, Entra ID, JumpCloud, Ping Identity, and BeyondTrust are supported directly. Customers keep their own MFA, session, and lifecycle policies. See Enterprise SSO for connection setup.
Provisioning and deprovisioning
Automated lifecycle keeps access in step with the source of truth. SCIM 2.0 and HRIS feeds create and update users, and they deactivate them when they leave. Offboarding in the identity provider revokes app access, with no manual step. See Provisioning.
Audit events
Sign-ins, role changes, provisioning updates, and other identity events are recorded. You can read them through the Events API for auditing, alerting, and downstream sync. See Audit logs.
Lidar threat detection
Lidar correlates authentication activity per environment and raises Signals for patterns such as brute force, impossible travel, bots, and MFA fatigue. Tune detectors under Lidar > Monitors in the console, then triage findings under Signals. Detection runs inside Authdog. If you also want the same trail in Datadog, Splunk, or Sentinel, use SIEM forwarding. See Lidar and Lidar in the console.
Bot protection
Hosted flows can require a Google reCAPTCHA or Cloudflare Turnstile check. You configure it per environment under Authentication > Add-ons. Sign-in, sign-up, waitlist, password reset, magic link, one-time code, and MFA verification can each be protected on their own. See Bot protection.
Webhook signature verification
Outbound webhooks are HMAC-signed with an X-Authdog-Signature: t=...,v1=... header, and delivery is retried. Verify the signature and check the timestamp before you act on a payload, so you only trust events that actually came from Authdog.