Authentication

Authentication answers a single question: who is this request coming from? Authdog handles the entire flow — presenting a sign-in experience, verifying credentials against one or more identity sources, and issuing a session your app can trust on every subsequent request.

This page explains the model. If you just want to wire sign-in into an app, start with Sign up & sign in or a quickstart.

The mental model

Authdog sits between your application and the identity sources your users authenticate with. A user proves who they are once — with a password, a social account, a magic link, or a corporate IdP — and Authdog turns that proof into a session. Your application never handles raw credentials; it only ever validates the session Authdog issued.

Everything that follows sign-in — authorization, organizations, provisioning — keys off the identity established here.

Ways users can authenticate

A single Authdog environment can enable any mix of these methods:

• Password — classic email + password with secure hashing and breach-aware policies.
• Social / OAuth2 — sign in with Google, GitHub, Microsoft, Apple, and dozens more providers. See the OAuth provider catalog.
• Passwordless & magic links — email a one-time link or code instead of a password.
• Enterprise SSO — federate to a customer's own IdP over SAML 2.0 or OIDC. Okta, Microsoft Entra ID, JumpCloud, Ping Identity, and BeyondTrust are first-class, alongside generic SAML and OIDC connectors.
• Multi-factor (MFA) — layer TOTP or another second factor on top of any primary method.

Which methods appear on the sign-in screen is per-environment configuration, so staging and production can differ without code changes.

Enterprise SSO and domain routing

Enterprise customers bring their own identity provider. In Authdog each customer IdP is a connection on your environment, configured with the provider's metadata (SAML entity/ACS URLs or an OIDC discovery document).

To route users to the right connection automatically, Authdog matches the email domain they enter. Given an email, the discovery endpoint resolves which connection (if any) should handle it:

GET /api/v1/sso/discover?environmentId=<env>&[email protected]
// -> { "connectionId": "...", "providerId": "okta", "signinUrl": "https://identity.authdog.com/..." }

This is what powers "we'll redirect you to your company login" behavior without hardcoding anything per customer.

What a successful sign-in produces

When a credential checks out, Authdog:

1. Upserts the user into the environment's user store, linking the identity to any existing account with the same verified email.
2. Issues a session — a signed JWT delivered as the authdog-session cookie (and readable as a bearer token for API clients).
3. Emits events (user.signed_in, user.created, …) that flow to your webhooks and integrations.

From here your backend simply validates the session on each request — it never re-checks the original credential. That validation model is covered in Sessions & tokens.

Machine-to-machine authentication

Not every caller is a human. For service-to-service calls, an M2M application uses the OAuth2 client credentials grant: it exchanges a client ID and secret for an access token, with no interactive sign-in and no session cookie. Same identity platform, no browser involved.

Where authentication is configured

• Sign-in methods, social providers, and MFA — per environment in the console.
• Enterprise SSO connections — under an environment's connections, or delegated to customers via the admin portal.
• The hosted experience — the Account portal renders sign-in, sign-up, and MFA screens for you; or build your own with custom flows and the component reference.

Related

• Sessions & tokens — how the issued session is validated
• Authorization — what an authenticated user is allowed to do
• Provisioning — how enterprise users are created before they ever sign in