Authentication & session configuration

Each environment decides how its users authenticate and how long their sessions last. You configure this from the dashboard under Authentication; the SDK reads the environment’s public config on load and renders the sign-in / sign-up surfaces to match, and the server enforces the same rules on every request.

User & authentication

Authentication → User & authentication exposes four independent toggles:

• Email sign-up — allow new users to create an account with email and password. Off makes sign-up OAuth-only: the SDK hides the email form on <SignUp> and shows just the provider buttons.
• Email sign-in — allow users to sign in with email and password. Off makes sign-in OAuth-only: the SDK hides the email form on <SignIn>.
• Verify email at sign-up — require a 6-digit emailed code before the account is created. When off, <SignUp> skips the code step entirely: the account and session are created immediately and the user is signed in with an as-yet-unverified email.
• Require email address — every user must carry an email. When on, a sign-in from a provider that returns no email (some OAuth providers, or MitID) is rejected. Off by default, because MitID and email-optional providers otherwise cannot create an account.

Avoiding lock-out

You cannot disable both email sign-up and sign-in unless an OAuth provider is enabled to fall back on — otherwise users would have no way to authenticate. The dashboard warns inline, and the API refuses the change with a clear error.

Sessions

Authentication → Session lifetime controls how long a signed-in session stays valid, with two independent limits (at least one must be set):

• Inactivity timeout — the session expires after this much inactivity. It slides forward on activity, so an active user stays signed in.
• Maximum lifetime — a hard cap on session age regardless of activity.

With only a maximum set (the default is 30 days), sessions have a fixed lifetime. Add an inactivity timeout to expire idle sessions sooner while keeping active ones alive.

To customize the claims inside the session token, use JWT templates.

How the SDK reacts

The SDK fetches the environment’s public config once on load, so <SignIn> and <SignUp> render the right surfaces without any extra configuration in your app. If you build your own UI with the headless hooks, useSignUp resolves to a success status directly (no code step) when verification is disabled — signing the user in automatically unless you pass autoSignIn: false — and you can read the enabled methods from the auth context to render conditionally.