Before a company adopts a SaaS tool, its security lead's review checklist almost always asks the same questions: can password login be turned off, can an API key's permissions be scoped down to the minimum, is there protection against repeated failed logins, and what happens to an account after an employee leaves.
These questions used to get addressed piecemeal across separate releases. This update brings several related changes together. As a Flashduty account grows, sign-in methods, integration keys, and membership changes all become things a security review will ask about. The four changes below cover login, key authorization, self-hosted environments, and member management. Coverage differs between SaaS and self-hosted deployments, noted in each section.
Enforce SSO, turn off password login
After configuring SAML2.0, OIDC, or CAS under Platform Management → Single Sign-On, you can turn on "Members can only sign in via SSO." Once enabled, every member of the account must authenticate through the identity provider, and password or verification-code login is rejected. This toggle is on by default the first time you configure SSO, and can be turned off if needed. Self-hosted deployments also support LDAP under the same toggle.
App Keys move from all-access to scoped permissions
Previously, an App Key could only be created with access to every API. Now, when creating or editing a key, you can choose custom permissions and select the specific API permission points that key actually needs; calls outside that scope are rejected. Even a key with full permissions stays bounded by its creator's current role permissions. Existing keys can also have their scope edited after the fact, which pairs well with rotating keys regularly to keep each key's exposure limited to what the business actually needs.
Self-hosted: brute-force protection on login, configurable session length
In self-hosted deployments, exceeding the failed-login limit now triggers a CAPTCHA, reducing the risk of password brute-forcing. Session expiration is also now configurable, so a team can set login session length according to its own security policy instead of a fixed default. Both of these are currently available only in self-hosted deployments, not on SaaS.
Stricter identity mapping, more thorough member deletion
For SSO, the user ID mapping field is now optional, and the provider_key identity dimension has been removed, reducing login issues caused by identity provider field changes. When multiple new members sign in via SSO for the first time at once (JIT account creation), account creation is now serialized to avoid duplicate accounts under concurrency. Deleting a member from the Team & Members page now comes with more complete cleanup logic, reducing leftover associated data after deletion.
Getting started
The SSO enforcement toggle is under Platform Management → Single Sign-On, see the SSO documentation for setup steps. Scoped App Keys are created under Account Settings → APP Key, see the Open API documentation for authentication and permission details. Member deletion is under Platform Management → Member Management, see the team and member documentation for details.
For brute-force protection and session length configuration in self-hosted deployments, contact our support team for deployment guidance.