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.

Accounts with no email address

With Require email address off (the default), a user who signs in through MitID — or any provider that returns no email claim, or one whose address came back unverified — gets an account with no email on it. That is a supported state, not an error, and two things behave differently for those users:

• <UserDashboard> asks them to add an address instead of telling them to check their inbox. Nothing was emailed, so there is nothing to verify or resend.
• Account deletion is unavailable until they add one. Deletion is confirmed through a one-time link we email to the address on file, so the flow has nowhere to send it; the dialog says so and the server refuses the request.

They can add an address themselves under Email addresses in <UserProfile>; it goes through the normal verification, and both behaviours above resolve once it is verified. Turn Require email address on if your app cannot support email-less accounts at all — but note that it makes MitID sign-in impossible.

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 → Sessions 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.

Multi-session

The same page has a Multi-session toggle. When on, end users can be signed in to several accounts at once in one browser and switch between them:

• <UserButton> picks it up automatically: its menu lists the other signed-in accounts and gains an Add account item that opens the standard sign-in card in a dialog.
• Signing out ends only the current account’s session; the SDK switches to the most recently used remaining account, and the user lands signed out only when no accounts remain.
• For custom UI, use the headless useSessionList() hook.
• Switching or adding an account changes who is signed in, so the SDK reloads the page by default (to signInUrl, else /) to rebuild caches for the new user. Opt into an in-page swap with onActiveSessionChange.

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.