JIT Provisioning, Login Restriction, attribute mapping, and session controls are the settings every identity provider shares, regardless of whether it's SAML, OpenID, LDAP, OTP, or a custom method.

Overview

This page covers concepts shared across every SSO method on the platform — it isn't specific to one provider. Whatever the identity provider type, every method has the same four cross-cutting concerns under Additional Settings, plus an attribute-mapping section for connected providers: JIT Provisioning (auto-create accounts on first sign-in), Login Restriction (who's allowed to sign in through this method), attribute mapping and sync (how the provider's data fills user profiles), and session and login-protection settings (how long sessions last and how they're guarded). It also covers how you add, edit, enable, and delete methods on the Settings › Security screen. For a specific provider's own fields, see its dedicated page — LDAP Configuration, OTP Configuration, and so on.

JIT Provisioning and User Matching

JIT Provisioning creates a platform account automatically the first time someone signs in through the method, so you don't need to pre-create users.

• Matching is by username. The account is found by the username the provider produces — for SAML the Username Attribute Statement or the NameID, for OpenID the Username JSON Path. If a user with that username already exists, that account is used; no new account is created, and matching is never done by email. So if the provider sends a different username than an existing local account, you can end up with a second account even when the email matches.

• JIT Provisioning User Criteria is evaluated against the incoming profile; only matching people get auto-created, others fail with "User criteria check failed".

• Auto-created users get their name (from the Name mapping, or First + Last), email, phone, and mapped custom attributes from the provider, and are flagged as SSO users.

• With JIT off, only pre-existing users can sign in; an unknown username fails.

Note:

JIT is off by default on most identity provider types, but on by default for OTP.

Login Restriction vs. JIT Criteria

Login Restriction turns on a Login User Criteria Match rule. The difference from JIT criteria is when each one runs:

• JIT Provisioning User Criteria is checked only when creating a new user.

• Login User Criteria Match is checked on every login, including existing users.

Both fail with "User criteria check failed". Use Login Restriction to limit a method to, say, a department or region regardless of how the account was created — for example, allow SSO only for users whose department is Sales.

Mapping and Syncing Attributes

• Default Attributes: Map the provider's fields to the core identity: Name, First Name, Last Name, Email, Username, and Phone Number. For SAML these are attribute statements (attribute names); for OpenID they're JSON paths into the user-info response. The Username mapping is the login identity.

• User Attributes Sync: Turn this on to reveal Attribute Mapping, where you pair User Fields with the provider's attributes or JSON paths. On each sign-in, the mapped values are written to the profile. The sync is one-way and selective: mapped attributes follow the provider and overwrite any local edits on every login, while everything not in the mapping is preserved — teams, roles, account state, locale, and any unmapped custom attributes keep their local values. Multi-value user fields receive all the values the provider sends. For SAML and OpenID, these per-login profile updates ride on the JIT Provisioning switch — with JIT off, the platform only matches the user and doesn't rewrite profile fields.

Session and Login-Protection Settings

Under Additional Settings, each method controls the sessions it creates:

• Session Expiry Time (in minutes): how long a session lasts; if unset, the platform default applies (typically 1 day). Activity quietly renews it, so in practice a session ends after the user is away for the full window.

• Enable Refresh Token (labeled Perpetual Login) with Refresh Token Expiry Time (in days) (default 30) — the browser silently renews the session until the refresh token itself expires.

• Restrict Multiple Sessions: allows only one active session per user at a time, across all browsers and devices. A new sign-in ends the user's other sessions in real time.

• Single Tab Session: one browser tab per session; opening a second tab ends the first.

• Partitioned Cookies Disabled: session cookies behave as normal shared cookies instead of using the experimental Partitioned attribute — only relevant to embedded apps.

• Keep External Session / External Session Expiry Time: for the embedded and token types — see External Session Configuration.

Note:

Account lockout (max failed attempts — default 5 — the failure-reset window, the lockout duration, and whether remaining attempts are shown) applies to the password-family methods but isn't on this form for added providers; it's a method property.

Managing Identity Providers

On Settings › Security, the screen is split into two labelled sections: Domain (with a copy button — you need it for SSO setup) and Identity Providers. Each provider row has an on/off toggle and, revealed on hover, edit (pencil) and delete (trash) buttons, each shown only with the matching permission. The built-in method is Email ID and Password; its provider name is read-only and shows on the login page.

• Add: the "+" button pinned at the top of the Identity Providers list opens the form — pick the type first, then fill that type's config; the form changes to match the type. A newly created provider is saved switched off, so it doesn't accept logins until someone flips its toggle on.

• Enable/disable: flip the toggle — a disabled method disappears from the login page immediately, but existing sessions continue until they expire.

• Delete: from the row menu. Two guardrails: you can't delete the last remaining method, and the built-in standard methods can't be deleted at the platform level — only toggled off.

• There's no "primary/default" method — the login page shows the built-in form plus a button for every method that's on.

Note:

Permissions gate everything on this screen — View to see it, Create for the New button, Edit for the toggle and the config form, Delete for deletion, all scoped to Identity Providers.

Per-App Identity Providers

Yes — alongside the platform-wide methods, you can create identity providers scoped to a specific app (interface), and an app can be set to accept only its own identity providers rather than the platform-wide ones. Use this to give a published app a different sign-in experience — its own SSO or a custom/anonymous method — without changing how people sign in to the platform itself.

Notes

These four settings apply the same way on every method, so getting them right once pays off across your whole identity provider list:

• Remember that user matching is always by username, never by email — align your provider's username mapping with existing platform usernames before rollout.

• Use Login Restriction, not JIT criteria, when you need a rule enforced on every login rather than only at account creation.

• Leave attributes you manage locally — teams, roles, custom fields — out of the mapping, since anything mapped is overwritten on every sign-in.

• Set Session Expiry Time and Refresh Token deliberately per method rather than relying on the platform default.

• Test a newly added identity provider while its toggle is still off, and only enable it once configuration is verified.

• Confirm you have at least one other enabled method before disabling or deleting one — you can't remove the last remaining method.