Add sign-up and sign-in to your app in an afternoon. This page is the practical checklist — enable the methods you want, pick how the UI is rendered, and wire up the resulting session. For the underlying model, see Authentication (concept).
Enable sign-in methods
Authentication methods are configured per environment in the Authdog console. Turn on any combination of:
- Password — with a breach-aware password policy.
- Social OAuth2 — Google, GitHub, and other providers.
- Passwordless — magic links delivered by email.
- MFA — TOTP authenticator apps, promptable after primary sign-in.
- Enterprise SSO — SAML 2.0 / OIDC via Okta, Entra ID, JumpCloud, Ping, or BeyondTrust.
Each environment has its own signing keys, connections, and user store, plus a public key (pk_...) your frontend uses to talk to that environment.
Choose how the UI is rendered
You have three options, from least to most custom:
- Hosted Account portal — Authdog renders sign-in, sign-up, and MFA screens for you. Redirect users there and they come back signed in. Zero UI code.
- Components — drop prebuilt, themeable sign-in widgets into your own pages.
- Custom flows — call the flow primitives directly and build the entire experience yourself.
A minimal mount of a hosted sign-in component looks like this:
import { SignIn } from "@authdog/components";
export default function SignInPage() {
return <SignIn publicKey={process.env.NEXT_PUBLIC_AUTHDOG_PK} />;
}Configure social and enterprise connections
Social OAuth2 providers and enterprise SSO connections are set up in the console under the environment's Connections. For social, register the provider's client ID/secret. For enterprise SSO, exchange SAML/OIDC metadata with the customer's IdP — see the SSO providers catalog for per-provider setup.
Because connections are scoped to the environment, your development and production environments stay fully isolated.
The session
A successful sign-in issues a signed-JWT session that Authdog sets as the authdog-session cookie (HttpOnly, SameSite=Lax, Secure in production). Clients that can't use cookies can send it as Authorization: Bearer <token>.
Your backend validates this session on each request rather than trusting it blindly — see Backend requests for the server-side gate, and Sessions & tokens for the token model and lifetimes.
Sign-out
Sign-out lives in the same portal or component you used for sign-in. It expires the authdog-session cookie and redirects back to your app. If you build custom flows, call the logout primitive and clear the cookie server-side.
Next steps
- Permissions — control what a signed-in user can do.
- Users and Organizations — manage the accounts behind the sessions.