Authentication

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."

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.

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.

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."

The Stripe connection configured here is the same one 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.

Sessions

?tab=sessions — Session Management: "Configure signing keys and JWT settings for your application." See 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:

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

{
  "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:

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 protected] is used, [email protected] is blocked for sign-up and for adding to an existing account.
• Block sign-ups that use disposable email addresses — rejects known throwaway domains.

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.

Related