The **Authentication** module is where you decide how people sign in to your application. Its subtitle says exactly that: _"Configure how users sign in to your application."_

![Authentication methods](/content/console/authentication.methods.png)

Everything here is **per environment**. The rail on the left groups the tabs into three blocks — the configuration tabs, an **ACCESS** block, and a **RELATED** block linking out to Authorization, Branding, Domains, and Redirects.

## Analytics

`?tab=analytics` — sign-in volume, success and failure rates, and method mix for the selected time range. Use it to confirm a newly enabled method is being picked up before you make it the default.

## Methods

`?tab=methods` — the four top-level ways in. Each is a card with an **Enabled** / **Disabled** badge and a single button.

| Method | What it is |
|--------|-----------|
| **Single Sign-On** | Sign in with SAML and OIDC identity providers like Entra ID, Okta, and Google Workspace. **"Manage"** opens connection setup. |
| **Email + Password** | Classic credentials. The [password policy](#policies) is enforced while this is on. |
| **Passkeys** | WebAuthn credentials — faster, easier, and more secure than passwords. |
| **Magic Auth** | A unique six-digit code sent to the user's email address. |

> **Tip**
>
> Passkeys and Magic Auth both remove the password from the flow. Enabling
> passkeys alongside Email + Password is the low-risk first step: existing users
> keep their password, new devices get offered a passkey.

## Providers

`?tab=providers` — the connection catalog, titled **"Connections"**: _"Configure external identity providers and social logins."_ Counters at the top show how many are **Available** versus **Configured**.

Filter by protocol with the **OAuth 2.0**, **Enterprise**, **SAML 2.0**, and **OpenID Connect** tabs, then page through the catalog (20 per page by default, adjustable to 10/20/50/100). Over sixty providers ship in the catalog — Apple, Amazon, AWS, Bitbucket, Box, Coinbase, Discord, DigitalOcean, DocuSign, Dropbox, and many more, including identity-verification providers such as 1Kosmos BlockID and Asignio.

Click **"Enable"** on a provider to enter its client ID, client secret, and any provider-specific fields. Enterprise providers (Okta, Entra ID, JumpCloud, Ping, BeyondTrust) additionally accept metadata URLs and domain routing so a user's email domain picks the right connection.

## Features

`?tab=features` — capabilities layered on top of the methods.

| Feature | What it controls |
|---------|-----------------|
| **Hosted UI** | Whether users sign in through Authdog's customizable hosted pages instead of your own screens. |
| **Sign-up** | Whether users can create their own accounts. |
| **Invitations** | The expiry period for invitations to join an organization (default: 7 days). |
| **Multi-factor auth** | Requires non-SSO users to set up MFA to sign in. |
| **Localization** | Shows the hosted UI and auth emails in the user's browser language, with a configurable fallback (default: English (US)). |
| **User impersonation** | Lets dashboard team members sign in as any user of your app. Gated — contact Authdog to enable. |
| **JWT template** | Augments session tokens with custom metadata. See [JWT Claims](#jwt-claims). |
| **Trusted domain reminder** | Shows _"Only sign in if you recognize this address"_ with the identity host URL on hosted sign-in and sign-up pages. |

## Add-ons

`?tab=addons` — third-party integrations that hook into the authentication flow. _"If you're interested in using an add-on not listed here, contact us."_

| Add-on | What it does |
|--------|-------------|
| **Google Analytics** | Attributes sign-ups to traffic sources and surfaces drop-offs during authentication. |
| **Segment** | Sends hosted authentication events to your Segment destinations. |
| **Stripe** | Provisions access tokens with entitlements and syncs seat counts for per-seat billing. |
| **Google reCAPTCHA** | Protects hosted auth pages against bots and abuse — sign-in, sign-up, waitlist, magic link, one-time codes, and MFA. |

The Stripe connection configured here is the same one [Billing](/docs/console/billing) uses for plans and subscriptions.

## Clients

`?tab=clients` — the **OpenID clients** registered for this environment.

The table lists Name, Client ID (truncated), Environment, MCP Server, Scopes, Created date, and row actions. Click **"Create client"** to register a new one and pick its grant types, redirect URIs, and scopes (`openid`, `profile`, `email`, and any custom scopes you define).

M2M projects get a `client_credentials` client automatically at creation; MCP servers get one bound to the server.

> **Caution**
>
> Client secrets are displayed once at creation. Store them in your secret
> manager — or in [Vault](/docs/console/vault) — before closing the dialog.

## Sessions

`?tab=sessions` — **Session Management**: _"Configure signing keys and JWT settings for your application."_ See [Sessions](/docs/console/sessions) for the full walkthrough of key rotation.

In short: three counters (Total Keys, Keys Used Today, Revoked Keys), a **Signin Keys** table listing each key's ID, type, use, algorithm, status, and dates with **"Use Key"** / **"Revoke"** actions, a **JWT Settings** card for **Token Lifetime** and **Clock Skew**, and a live **Claims Preview** of the token body.

## JWT Claims

`?tab=jwt-claims` — map custom claims into the access tokens issued at sign-in. You edit a JSON object where each key is the claim name written into the token and each value is its source. The editor validates as you type and reports, for example, _"1 claim valid and ready to save."_

Available sources:

| Source | Yields |
|--------|--------|
| `roles` | The user's role slugs, direct plus inherited via groups. |
| `groups` | The user's group slugs. |
| `email` | Primary email address. |
| `displayName` | Display name. |
| `givenName` / `familyName` | First and last name. |
| `username` | Username. |
| `externalId` | Stable external user id. |
| `metadata` | A value from user metadata — requires a `"key"`. |
| `static` | A fixed literal — `{ "source": "static", "value": "..." }`. |

Use a source as a bare string, or as an object when it takes options:

```json
{
  "roles": "roles",
  "dept": { "source": "metadata", "key": "dept" },
  "tier": { "source": "static", "value": "pro" }
}
```

Click **"Save claims"** to apply. New claims appear in tokens issued from the next sign-in onward — existing tokens are not rewritten.

## Restrictions

`?tab=restrictions` — who is allowed to get in at all.

**Sign-up mode** is a three-way choice:

| Mode | Behaviour |
|------|-----------|
| **Public** | Anyone can sign up. |
| **Restricted** | Sign-ups disabled. Access only via invite, manual creation, or enterprise SSO. |
| **Waitlist** | Sign-ups disabled, but people can join a waitlist. |

**Email restrictions** control which addresses qualify, via an **Allowlist** (only these domains may sign in) or a **Blocklist** (these domains may not).

**Additional email restrictions** adds two rules:

- **Block email subaddresses** — addresses containing `+`, `=`, or `#` are allowed, but only one distinct subaddress per base email. Once `email+one@domain.com` is used, `email+two@domain.com` is blocked for sign-up and for adding to an existing account.
- **Block sign-ups that use disposable email addresses** — rejects known throwaway domains.

> **Tip**
>
> An allowlist is the right default for enterprise deployments: it guarantees
> only your customer's domains can reach the app, regardless of sign-up mode.

## Policies

`?tab=policies` — the enforcement rules, across seven sub-tabs: **Password**, **Countries**, **Rate limiting**, **Bot detection**, **Brute force**, **Breached passwords**, and **Device risk**.

**Password policy** is enforced whenever Email + Password is enabled. Set a **Minimum length** (recommended: 10–14 characters) and require any of **Lowercase**, **Uppercase**, **Number**, and **Symbol**. A **"Test a password"** box evaluates a candidate against the current settings — including unsaved edits — and shows which requirement each character class satisfies.

The remaining sub-tabs set thresholds for geographic restrictions, request rate limits, bot scoring, brute-force lockout, breached-credential rejection, and device-risk challenges. The detections they drive surface as signals in [Lidar](/docs/console/lidar).

## Related

| Read | To learn how to |
|------|-----------------|
| [Users](/docs/console/users) | Manage the users these settings apply to |
| [Sessions](/docs/console/sessions) | Rotate signing keys and tune token lifetimes |
| [Authorization](/docs/console/authorization) | Decide what users may do once signed in |
| [Branding](/docs/console/branding) | Style the hosted sign-in experience |
| [Lidar](/docs/console/lidar) | Triage the detections these policies produce |
| [SSO](/docs/sso) | Set up enterprise SAML and OIDC connections |