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 wire-up of the hosted sign-in flow with the browser SDK looks like this:
import { createAuthdogClient } from "@authdog/javascript";
const authdog = createAuthdogClient({
publicKey: process.env.NEXT_PUBLIC_PK_AUTHDOG,
});
authdog.handleRedirectCallback(); // consume ?token= after the redirect back
authdog.signIn(); // send the user to the hosted sign-in flowConfigure 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.