Authdog

Sign up & sign in

Last updated Oct 18, 2026
View as Markdown

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 flow

Configure 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}/device starts the grant. The client is confidential and uses HTTP Basic auth.
  • POST {issuer}/token with grant_type=urn:ietf:params:oauth:grant-type:device_code polls 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 --poll

The person who approves needs a user session in that same environment.

Next steps

Learn more