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)](/docs/concepts/authentication).

## Enable sign-in methods

Authentication methods are configured **per environment** in the [Authdog console](https://console.authdog.com). 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](/docs/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](/docs/components)** — drop prebuilt, themeable sign-in widgets into your own pages.
- **[Custom flows](/docs/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:

```tsx
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](/docs/backend) for the server-side gate, and [Sessions & tokens](/docs/concepts/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](/docs/permissions) — control what a signed-in user can do.
- [Users](/docs/users) and [Organizations](/docs/organizations) — manage the accounts behind the sessions.