Add sign-up and sign-in without building the credential screens yourself. Turn on the methods you want, choose how the UI is rendered, and wire up the session Authdog issues.
The model behind those steps is Authentication.
Enable sign-in methods
You configure methods per environment in the Authdog console. Turn on any combination of:
- Password, with a breach-aware password policy.
- Social OAuth2, including Google, GitHub, and other providers.
- Passwordless, with magic links delivered by email.
- MFA, with TOTP authenticator apps prompted after the first factor.
- Enterprise SSO, over SAML 2.0 or OIDC, through 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.
Where to go deeper
These topics are configured on the environment. The links match what ships today:
| Topic | Where to read |
|---|---|
| Passkeys (WebAuthn) | Passkeys, Authentication → Methods |
| MFA (TOTP, SMS, backup codes) | MFA, Authentication → Features |
| Magic link and email OTP | Authentication → Methods, Notifications |
| SMS / WhatsApp OTP sign-in | Authentication → Methods (requires an SMS provider) |
| Waitlist and invite-only signup | Users → Settings, signup mode restrictions |
| Identity linking and reauthentication | Account Portal, Custom flows |
| Enterprise SSO connections | SSO providers catalog, Authentication → Providers |
| Admin Portal (embeddable) | Account Portal |
Choose how the UI is rendered
You have three options, from least custom to most:
- Hosted Account Portal. Authdog renders sign-in, sign-up, and MFA. Send people there, and they come back signed in. You don't write that UI.
- Components. Drop prebuilt, themeable sign-in widgets into your own pages.
- Custom flows. Call the flow primitives and build the experience yourself.
A minimal hosted sign-in 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
Set up social OAuth2 providers and enterprise SSO under the environment's Connections. For social login, register the provider's client ID and secret. For enterprise SSO, exchange SAML or OIDC metadata with the customer's identity provider. The SSO providers catalog has a setup page for each one.
Connections belong to the environment, so development and production stay fully separate.
The session
A successful sign-in issues a signed JWT. Authdog sets it as the authdog-session cookie (HttpOnly, SameSite=Lax, Secure in production). Clients that can't use cookies send it as Authorization: Bearer <token>.
Validate that session on each request. Don't trust it just because it showed up on the request. See Backend requests for the server-side check, and Sessions and 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 sends the user back to your app. If you built a custom flow, call the logout primitive and clear the cookie on the server.
Device authorization (RFC 8628)
Use the device flow when the client has no browser, or no comfortable keyboard: a TV, a CLI, a printer. The client requests a device code and a user code, shows a verification URL, and polls until someone who is already signed in to the same environment approves or denies the request.
Per-environment issuer paths:
POST {issuer}/devicestarts the grant. The client is confidential and uses HTTP Basic auth.POST {issuer}/tokenwithgrant_type=urn:ietf:params:oauth:grant-type:device_codepolls for tokens.GET {issuer}/device/verify?user_code=…is where the user enters the code. When sign-in is configured, that page sends them through the environment's sign-in flow first.
Poll errors follow RFC 8628: authorization_pending, slow_down, expired_token, access_denied, and invalid_grant. This grant doesn't issue refresh tokens. Discovery advertises device_authorization_endpoint on the environment's issuer document.
You can try the poll with the CLI:
ISSUER=https://id.example/oidc/$ENVIRONMENT_ID \
CLIENT_ID=... CLIENT_SECRET=... \
authdog device authorize --pollThe person who approves needs a user session in that same environment.
Next steps
- Permissions covers what a signed-in user is allowed to do.
- Users and Organizations cover the accounts behind those sessions.