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 or choose a quickstart.
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.
No passwords in your app
The resulting user identity is available to authorization, organizations, and 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 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
curl --get "https://identity.authdog.com/api/v1/sso/discover" \
--data-urlencode "environmentId=<env>" \
--data-urlencode "[email protected]"Response
{
"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:
- Creates the user, or links the identity to an existing user with the same verified email.
- Issues a signed JWT session in the
authdog-sessioncookie. API clients can use the token as a bearer token. - Sends events such as
user.signed_inanduser.createdto configured webhooks and integrations.
Your backend validates the session on each request; it does not check the original credential again. See Sessions & tokens for validation details.
Machine-to-machine authentication
For service-to-service calls, an M2M application 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, or build the UI with custom flows and components.
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