The Security screen is where you manage sign-in methods, the session behavior each one produces, and login protections like restriction rules and account lockout.
Overview
Settings › Security is the Identity Providers manager — the screen for configuring the methods people use to sign on to your environment. It combines three related jobs: turning sign-in methods on and off, tuning the session behavior each method produces, and controlling who's allowed to log in at all. Platform-wide protections that don't have a settings screen — cookies, headers, redirect checks, MFA rate limits — live in the companion page, Platform Security Behavior.
Use Cases
Add an SSO method alongside the built-in Email ID and Password sign-in.
Extend how long a session lasts, or issue refresh tokens so users stay signed in for longer.
Restrict a sign-in method to one active session at a time, across devices.
Lock login down to users who match specific attributes, such as a department.
Tune how many failed password attempts lock an account, and for how long.
Sign-In Methods
The Security screen shows your tenant's Domain, with a copy button — you'll need it when configuring SSO on the provider side — and the list of sign-in methods, each with an on/off toggle. The built-in method is Email ID and Password, where admins add new users manually; any SSO methods you add appear alongside it, showing who added them and when. Click New Identity Provider to add a method.
There's no "primary" or "default" method to set — the login page shows the built-in Email ID and Password form plus a button for every method that's switched on. This screen also doesn't control what the login page asks for: the identifier field is always Username, so switching a method — say, to OTP — won't turn it into a phone-number field.
Note: you need View permission on Identity Providers to see this screen; Create gates the New button, Edit gates the toggle and the edit form, and Delete gates deletion.
Enabling and Disabling a Sign-In Method
Flip the toggle on its row to enable or disable a method — this requires Edit permission on Identity Providers. The login page only offers methods that are switched on, so a disabled method disappears from it immediately. Disabling a method does not end sessions already created through it — signed-in users stay signed in until their session expires or they log out.
To remove a method permanently, use Delete Identity Provider from its row menu: "Are you sure you want to delete this Identity Provider?" Two guardrails are enforced by the admin UI: you can't delete the last remaining sign-in method, and built-in standard methods can't be deleted at the platform level — only toggled off.
Session Settings per Sign-In Method
Editing a sign-in method exposes Additional Settings that govern sessions created through it. The built-in Email ID and Password method shows a short list; added methods (SSO, LDAP, and other provider types) show the full set below.
Setting | Description | Default |
|---|---|---|
Session Expiry Time | Session duration in minutes. Effectively an inactivity window — active users within the last few minutes before expiry get silently re-extended. | 1 day, if left empty |
Enable Refresh Token | Keeps users logged in longer without re-prompting for credentials; adds Refresh Token Expiry Time. | Off; 30 days once enabled |
Restrict Multiple Sessions | Allows only one active session per user across all browsers and devices; a new login deletes all other sessions and pushes a real-time logout. | Off |
Single Tab Session | Limits each user to one browser tab per session; opening a second tab logs the whole session out. | Off |
Partitioned Cookies Disabled | Controls whether cookies use the experimental "Partitioned" attribute, relevant only to embedded and guest sessions. | Off (partitioning applies to embedded/guest sessions) |
JIT Provisioning | Automatic user provisioning for first-time IDP sign-ins, alongside User Attributes Sync — covered in the SSO documentation. | — |
Keep External Session | For embedded/external session methods — keeps the user's existing external session active instead of creating a new one; treated as machine-driven and excluded from last-login and login webhooks. | — |
Save your changes with Save; success shows "Identity Provider saved successfully".
Login Restriction
On any added sign-in method, turn on Login Restriction to control whether users must match specific criteria to log in, and define Login User Criteria Match as conditions on user attributes, standard or custom. The check runs on every login, after credentials succeed but before a session is created: a user who authenticates but fails the criteria is rejected with "User criteria check failed".
This applies to existing users too, not just new ones — tightening the criteria locks out non-matching users at their next login, though their current sessions continue until they expire. It's per sign-in method, so you can restrict one SSO method to a department while leaving another open. Related but separate: when JIT Provisioning is on, its own criteria filter decides whether a first-time SSO user may be auto-created at all.
Account Lockout
Failed password logins are counted per user, shared across devices and IPs. After the allowed number of consecutive failures — 5 by default — the account state is set to Locked and every further login fails with "User is temporarily locked", even with the correct password. A successful login before the limit resets the counter to zero.
Three knobs tune this, set as properties of the sign-in method rather than shown on the settings form directly:
Allowed max login failures: the threshold, default 5.
Failure attempt reset duration: a window in minutes after which the failure counter expires on its own; no default — unset means failures only clear on a successful login or a lockout.
User lockout duration: how long, in minutes, the lock lasts. If set, an automatic unlock job flips the account back to Active when it elapses (only if it's still Locked). If unset, the lock is indefinite until an admin sets the user's State back to Active.
Show remaining login attempts: optional; appends "… Remaining Attempts: N" to the wrong-password error. Off by default.
Every failed attempt and every lockout is recorded: failed attempts appear in the audit log and user activity reports with source IP, lockouts raise a "user locked" audit event, and a login-failure webhook fires with the reason, username, and IP.
Security Settings for Application Users
Sign-in methods, session settings, and lockout apply to anyone who logs in through them — platform builders and end users of published apps alike. Two extra scoping rules apply to apps: an identity provider can belong to a specific app, so methods added inside an app's settings only appear on that app's login page, and an app can be configured to accept only its own identity providers — with that restriction on, tenant-level methods are refused for that app's login even if someone crafts the login URL by hand.
Notes
A few habits keep sign-in configuration safe as you add more methods:
Add a replacement sign-in method and confirm it works before disabling the one it's replacing.
Turn on Restrict Multiple Sessions for sensitive methods where one active session per user matters.
Use Login Restriction to scope SSO methods to the right population instead of leaving every method open to everyone.
Set a lockout duration explicitly if you don't want locked accounts to require manual admin intervention.
Check the audit log and login-failure webhooks periodically rather than only after an incident.
Configured deliberately, the Security screen is where you draw the line between convenient access and a login surface you can defend.