Releases

This release introduces several improvements to the Control API and Control Client, focusing on usability, data precision, and authentication management. Key updates include better ordering and filtering in APIs, enhanced refresh token handling, passwordless tenant creation, and refinements in login behavior and SMS configuration.
A breaking change affects the RefreshTokenGrants Control API naming conventions - see details below.

New features and improvements

• Improved ordering of applications and authentication methods
  Applications and authentication methods are now ordered by display name. If a display name is not provided, ordering falls back to technical name, and then by type in both the Control API and Control Client.

• Enhanced filtering by custom SP client ID
  Added support for filtering authentication methods by the optional custom SP client ID.

• More precise refresh token grant cleanup
  Refresh token grants are now deleted when a user is deleted, disabled, request for password change, or request for set a password using an email or SMS confirmation code.
  The cleanup process is now more accurate by also considering the authentication method type.

• Certificate management improvements
  In the Control Client, signing certificates can now be downloaded or copied in Base64 format.

• UI improvement for application creation
  Applications are now added to the list in Control Client only after the creation UI is closed, ensuring a cleaner user experience.

• Passwordless tenant creation
  The Control Client and Control API now support creating a tenant with an initially passwordless admin user.

• Improved API input handling
  All filter* parameters across the Control APIs are now trimmed before processing. This ensures that extra spaces in client inputs no longer cause empty or mismatched results.

• ⚠️ Breaking Change - Renamed fields in RefreshTokenGrants API
  To improve consistency and clarity, the following fields have been renamed:

  • authMethod → upPartyName
  • filterAuthMethod → filterUpPartyName

• SAML 2.0 login improvements

  • The login hint in SAML 2.0 query parameters is now space-trimmed and converted to lowercase.
  • The identification step is now selected based on the login hint, ignoring automatic selection.

• GatewayApi SMS label support
  Added support for configuring a label in GatewayApi SMS settings. This label is now included in API calls to GatewayApi when sending SMS messages.

Delivers finer-grained controls and a smoother setup experience in the Control Client: independently toggle SMS and email for password set/reset flows per authentication method and per user; gain full audit visibility with before/after diffs; enforce plan thresholds via tenant-scoped distributed locking; accepts a username query parameter from the SAML relying party; create applications inline with a live preview of generated values; and benefit from an improved environment selector; and improve translations for dynamic HTML links using placeholder URLs. Also fixes an issue where session links could be invalid when whitespace was present.

New features

• Granular SMS/email controls for password set/reset
  Independently enable or disable SMS and email for password set/reset flows at both:

  • The authentication-method level
  • The per-user level
    This provides precise control over how password communications are delivered.

• Comprehensive audit logging with diffs
  Every create, update, save, and delete on master and tenant documents now emits a “System‑Level Data” audit event, providing a chronological trail of configuration activity. Audit entries include a concise, serialized before/after diff so teams can quickly see exactly what changed without manual comparisons.

• Tenant‑scoped distributed locking for plan thresholds
  Introduces tenant‑scoped distributed locking to guard track and user creation when a plan enforces threshold limits, preventing race conditions and ensuring consistent enforcement.

• SAML login hint (username) passthrough Accepts a username (besides login_hint/LoginHint) query parameter from the SAML relying party used by Microsoft Entra ID.

• Inline application creation with live preview
  The “New application” modal has been removed. Application creation is now embedded directly in the page and shows application information as you type, keeping key values (e.g. authority, client ID, secret, scopes, and metadata) visible and continuously updated.

• Improved environment selector in Control Client
  The environment selector has been refined for a clearer, more consistent selection experience.

• Translations for dynamic HTML links using placeholders
  Dynamic HTML <a> elements are translated without embedding the href URL directly. Instead, translations use numbered placeholders such as {0}, {1}, etc., which are substituted with the correct URLs at runtime.

Bugs fixed

• Invalid session link due to untrimmed spaces
  Fixed an issue where leading or trailing spaces caused session links to be treated as invalid. Whitespace is now trimmed before link generation.

Delivers finer-grained controls and a smoother setup experience in the Control Client: independently toggle SMS and email for password set/reset flows per authentication method and per user; gain full audit visibility with before/after diffs; enforce plan thresholds via tenant-scoped distributed locking; create applications inline with a live preview of generated values; and benefit from an improved environment selector.

New features

• Granular SMS/email controls for password set/reset
  Independently enable or disable SMS and email for password set/reset flows at both:

  • The authentication-method level
  • The per-user level
    This provides precise control over how password communications are delivered.

• Comprehensive audit logging with diffs
  Every create, update, save, and delete on master and tenant documents now emits a “System‑Level Data” audit event, providing a chronological trail of configuration activity. Audit entries include a concise, serialized before/after diff so teams can quickly see exactly what changed without manual comparisons.

• Tenant‑scoped distributed locking for plan thresholds
  Introduces tenant‑scoped distributed locking to guard track and user creation when a plan enforces threshold limits, preventing race conditions and ensuring consistent enforcement.

• Inline application creation with live preview
  The “New application” modal has been removed. Application creation is now embedded directly in the page and shows application information as you type, keeping key values (e.g. authority, client ID, secret, scopes, and metadata) visible and continuously updated.

• Improved environment selector in Control Client
  The environment selector has been refined for a clearer, more consistent selection experience.

Enhances the FoxIDs Control Client with clearer list views and improved usability. Internal and external users now display a proper name derived from standard claims. The Applications, Authentication Methods, Internal Users, and External Users lists have been refined for consistency and readability. Initial data seeding for OpenSearch and supported databases (MongoDB, PostgreSQL, Azure Cosmos DB, and the file-based store) has been improved to make setup more reliable.

New features

• Internal and external user display names in lists
  The Control Client now shows an user’s display name by reading the standard claims name, given_name, and family_name (when available).

• Applications and Authentication Methods lists improvements
  Refined layouts and consistency in the Control Client to make these lists easier to read and manage.

• Internal Users and External Users lists improvements
  Clearer columns and navigation in the Control Client for more intuitive user management.

• Improved initial seeding for OpenSearch and databases
  More robust initial seeding for OpenSearch and for MongoDB, PostgreSQL, Azure Cosmos DB, and the file-based store to reduce setup friction and improve reliability.

Adds support for SAML relying parties to supply a login hint via the login_hint/LoginHint query parameter (commonly used by Microsoft Entra ID and Okta) that passes through to the downstream login experience when the SAML request does not include a NameID. Introduces inline asset options so logos, images, and icons can be embedded using data: URIs, reducing external requests and simplifying CSP. Also adds an in‑app CSS snippet generator to streamline styling of the login UI.

New features

• SAML login hint passthrough
  Accepts a login_hint/LoginHint query parameter from the SAML relying party. When the SAML request omits a NameID, this value is treated as a generic identifier hint and carried through the authentication flow (for example, pre‑populating the username field), preserving whatever the relying party provides.

• Inline images via data URIs in CSS
  Embed the logo or other images directly in your styles using data: URIs to avoid external HTTP requests, simplify deployment, and improve load performance.

• Inline icon configuration
  Configure the application icon (for example, favicon) using an inline data URI such as data:image/png;base64,... to embed the icon without hosting separate files.

• In‑app CSS snippet generator A built‑in generator link next to the login UI styling field opens a modal where administrators can preview template styles and append them directly to their CSS with one click.

Introduces a dynamic login dialog that supports configurable, context-aware UI elements - similar to the Extended UI - so teams can tailor the login experience without code changes. MFA pages now display the user identifier (username, email, or phone number) to maintain context and improve UI consistency. Adds built‑in HTML and CSS validation and sanitization to protect against unsafe markup and styles. Also improves the SeedTool to continue processing CSV imports when a problematic line is encountered, logging the issue to the console instead of aborting.

New features

• Dynamic login dialog with configurable elements
  The login UI now supports dynamic elements aligned with the behavior available in the Extended UI. Administrators can enrich and tailor the login page - for example, by adding custom links or informational messages. This enables:

  • Customizing the login experience based on user context or tenant configuration
  • Dynamically showing or hiding fields or messages depending on authentication requirements

• MFA pages show the user identifier
  Multi‑factor authentication pages now display the user’s identifier (username, email, or phone number) to provide clear context during verification and improve UI consistency across the authentication flow. The identifier is read‑only.

• HTML validation and sanitization
  Validates incoming HTML and removes disallowed elements and attributes (for example, script tags, inline event handlers, or javascript: URLs).

• CSS validation and sanitization
  Sanitizes inline styles by stripping unsafe constructs (for example, expression(), javascript: in url(), and disallowed imports)

• SeedTool: resilient CSV processing
  SeedTool no longer stops when it encounters a problematic line (for example, a user row) in a CSV file. Instead, it continues with the next line and logs information about the problematic line to the console, improving robustness for bulk imports.

Adds granular controls for the External Password API so you can independently enable calls to the Validation and Notification endpoints on specific events (login and password change). Previously, each endpoint could only be enabled or disabled globally.

New features

• External Password API - Validation endpoint: per-event toggles
  You can now enable or disable calling the Validation endpoint on:

  • User login
  • Password change

• External Password API - Notification endpoint: per-event toggles
  You can now enable or disable calling the Notification endpoint on:

  • User login
  • Password change

• Previous behavior
  Before this change, it was only possible to enable or disable each of the two endpoints in general, without controlling when they were invoked.

Resolves an issue where the login hint was not propagated or displayed on the login page, preventing expected prefill behavior and slightly increasing user friction.

Bugs fixed

• Login hint not displayed
  Fixed a defect where a provided login hint was neither passed from the login page nor shown to the user on the login page. The value is now correctly carried forward and rendered, improving usability and reducing input errors.

Fixes an issue in bulk user uploads where the "change password on next login" flag was not applied when a user's password was provided as a hash. This ensures consistent post‑provisioning security behavior regardless of whether plaintext passwords or pre‑hashed passwords are uploaded.

Bugs fixed

• Bulk upload: missing "change password on next login" flag for hashed passwords
  Previously, when users were imported in bulk with a password hash (rather than a plaintext password), the system failed to mark them for a required password change on next login (when that behavior was expected/configured). The logic now applies the flag consistently, ensuring security policies are enforced uniformly for all imported users.

This release expands SAML 2.0 boolean value handling to accept all XML Schema–compliant boolean literals (true, false, 1, 0) and improves startup behavior by executing the FoxIDs Control seeding process immediately at application start rather than deferring it until the first HTTP request.

New features

• Expanded SAML 2.0 boolean handling
  Boolean attributes in SAML 2.0 messages now accept the full set of XML Schema boolean literals: true, false, 1, and 0 (previously only true and false). This improves compatibility with identity providers or tooling that serialize boolean values numerically.

  Rationale and specification references:
  The SAML 2.0 specification examples typically show the string values "true" and "false" (for example, the NameIDPolicy AllowCreate attribute). However, the SAML protocol schema (http://docs.oasis-open.org/security/saml/v2.0/saml-schema-protocol-2.0.xsd) defines such attributes with the XML Schema boolean type. According to the W3C XML Schema Datatypes specification (https://www.w3.org/TR/xmlschema11-2/#boolean), valid lexical representations for a boolean are true, false, 1, and 0. Supporting all four forms ensures full standards compliance and broader interoperability.

• Immediate seeding on application startup
  The FoxIDs Control application now performs its seeding process during startup instead of waiting for the first incoming HTTP request. This:

  • Eliminates the initial user-facing delay on the first request
  • Surfaces configuration or data initialization errors earlier in the deployment lifecycle