Authentication establishes who is making a request. Authdog handles sign-in, verifies the result with the configured identity provider, and gives your app a session to validate. To add sign-in to an app, see [Sign up & sign in](/docs/authentication) or choose a [quickstart](/docs/quickstarts). ## How it works Your app sends the user to Authdog. Authdog completes the configured sign-in method and starts a session. On later requests, your app validates that session instead of handling the user's credentials.
Your user Selects a sign-in method
Authdog
Creates a trusted session
1 Verify identity 2 Create or link user 3 Issue JWT and cookie
Your app Validates the session

No passwords in your app

The resulting user identity is available to [authorization](/docs/concepts/authorization), [organizations](/docs/concepts/organizations), and [provisioning](/docs/concepts/provisioning). ## Sign-in methods Enable one or more methods in each environment: - **Password** — email and password. - **Social login** — OAuth with providers such as Google, GitHub, Microsoft, and Apple. See [Integrations](/docs/integrations) for supported providers. - **Magic link** — a one-time link or code sent by email. - **Enterprise SSO** — SAML 2.0 or OIDC connections to customer identity providers. - **Multi-factor authentication** — a second factor, such as TOTP, after primary sign-in. Only methods enabled for the current environment appear on its sign-in screen. You can use different settings in development, staging, and production. ## Enterprise SSO and domain routing Add each customer identity provider as a connection on your environment. A connection contains its SAML metadata or OIDC discovery settings. Authdog can select a connection from the user's email domain. The discovery endpoint returns the matching connection and sign-in URL: **Request** ```bash curl --get "https://identity.authdog.com/api/v1/sso/discover" \ --data-urlencode "environmentId=" \ --data-urlencode "email=jane@acme.com" ``` **Response** ```json { "connectionId": "...", "providerId": "okta", "signinUrl": "https://identity.authdog.com/..." } ``` Use this result to send enterprise users to their company sign-in page without adding customer-specific routing to your app. ## After sign-in After Authdog accepts the sign-in result, it: 1. Creates the user, or links the identity to an existing user with the same verified email. 2. Issues a signed JWT session in the `authdog-session` cookie. API clients can use the token as a bearer token. 3. Sends events such as `user.signed_in` and `user.created` to configured [webhooks and integrations](/docs/integrations). Your backend validates the session on each request; it does not check the original credential again. See [Sessions & tokens](/docs/concepts/sessions-tokens) for validation details. ## Machine-to-machine authentication For service-to-service calls, an [M2M application](/docs/integrations) exchanges a client ID and secret for an access token using the OAuth 2.0 client credentials grant. This flow has no interactive sign-in or session cookie. ## Configuration - Configure sign-in methods, social providers, and MFA on the environment. - Add enterprise SSO connections to the environment, or let customers configure them through the admin portal. - Use the hosted [Account portal](/docs/account-portal), or build the UI with [custom flows](/docs/custom-flows) and [components](/docs/components). ## Related - [Sessions & tokens](/docs/concepts/sessions-tokens) — how the issued session is validated - [Authorization](/docs/concepts/authorization) — what an authenticated user is allowed to do - [Provisioning](/docs/concepts/provisioning) — how enterprise users are created before they ever sign in