Releases

This release improves Environment Link configuration and claim transform diagnostics.

Environment Links now expose their technical name through the advanced creation options, while claim logging provides better visibility into _local: and _internal: claims before automatic filtering.

New Features and Improvements

Environment Link Technical Name

When creating an Environment Link, select Show advanced to view or change the prefilled Technical name.

The technical name is used for both the authentication method and the application registration created in the connected environment.

Claim Transform Logging

When claim logging is enabled, output logs now include _local: and _internal: claims before automatic filtering, including claims created by the final transform.

This applies to both authentication methods and applications. Claims forwarded from the transform continue to follow the existing filtering rules.

This release adds configurable claim value types across users, Access Structures, applications, claim transforms, and external integrations, making it easier to work with structured claims such as booleans, numbers, JSON objects, and arrays.

It also improves Control API error responses with clearer field-level validation details and request IDs for troubleshooting, includes updated dependencies with security fixes and improvements, and fixes refresh token lifetime limits so absolute lifetimes can again be configured up to four years.

New Features and Improvements

Configurable Claim Value Types

You can now select String, Boolean, Number, JSON object, or JSON array for user claims, Access Structure claims, static OAuth/OIDC application claims, and OAuth claim transforms through the Control Client and Control API.

Map transforms preserve the input value type by default, with an option to explicitly select another type. External Claims API and Directory Connector integrations also support explicit claim value types.

Access Structures combine JSON array contributions with the same claim name into a single array, making it easier to issue structured group and permission claims.

Invalid configured values are rejected when saving. If an invalid value is encountered at runtime, FoxIDs logs a warning and issues the value as text.

The Control Client layout has also been updated with value type selectors next to the corresponding claim and value fields.

Improved Control API Error Messages

Control API errors now identify the affected fields and include messages from inner exceptions without exposing stack traces.

Identical validation messages are shown only once, together with all relevant field names. A request-id response header has also been added to make it easier to locate corresponding diagnostic logs.

Validation and argument errors return HTTP 400, while unexpected server failures return HTTP 500. Middleware exception responses now use text/plain; charset=utf-8 instead of application/json.

Dependency Security Updates

Updated NuGet packages to incorporate security fixes and improvements from newer dependency versions.

Bugs Resolved

Refresh Token Lifetime Limits

Fixed an issue where the maximum configurable absolute lifetime for refresh tokens was incorrectly limited to one year. The maximum has now been restored to four years.

The configured inactivity timeout remains capped at one year, including for refresh tokens with unlimited absolute lifetimes. Each successful refresh renews the inactivity period without resetting the absolute lifetime.

This release improves migration support, external user handling, and NemLog-in flexibility, while also updating dependencies with the latest security fixes.

It adds Auth0 bcrypt password hash import, conditional external user creation through claim transforms, and an option for users to decide whether their CPR number should be saved after NemLog-in authentication. Several issues affecting OAuth token responses, fresh self-hosted installations, and Extended UI redirects have also been resolved.

New Features and Improvements

Auth0 Password Hash Support

Added support for importing bcrypt password hashes from Auth0 through the Control API and FoxIDs Seed Tool, allowing migrated users to retain their existing passwords.

Conditional External User Creation

Added support for skipping automatic external user creation for an individual login by setting _internal:skip_external_user_creation to true in claim transforms.

Existing external users continue to be handled as usual.

Optional CPR Saving in NemLog-in

Added an optional setting that allows users to choose whether their CPR number should be saved for future logins.

When enabled, the CPR entry page displays an unchecked checkbox. Users who leave it unchecked can complete the login without saving their CPR number or creating an external user.

The setting is disabled by default.

Dependency Security Updates

Updated NuGet packages to incorporate security fixes and improvements from newer dependency versions.

Bugs Resolved

Correct HTTP Status Codes for OAuth Token Errors

Fixed token endpoint error handling to return the appropriate HTTP status codes:

• HTTP 400 for OAuth request errors such as invalid_grant
• HTTP 429 for plan limit errors
• HTTP 500 for unexpected failures

Token error responses are now also included in message traces.

Fix for Tenant Seeding on Fresh Self-Hosted Installations

Fixed a NullReferenceException that prevented master/main tenant seeding on fresh self-hosted installations.

[#1701](https://github.com/ITfoxtec/FoxIDs/issues/1701)

Fix for URL Patterns in Extended UI

Fixed redirects through Extended UI and external user creation forms to preserve the authentication method's configured URL pattern.

This prevents session and logout information from being lost when using dot or tilde URL patterns.

This release refreshes the FoxIDs visual identity with an updated logo and browser icon, and improves refresh token and active session lifetime alignment.

New Features and Improvements

Updated FoxIDs logo

Updated the FoxIDs logo and browser icon with a cleaner design. Added cache versioning so browsers automatically load the latest default logo and icon.

Fixed a lifetime mismatch between refresh tokens and active sessions

An active session could previously expire while its associated refresh token was still valid. This could cause token renewal to fail and require the user to sign in again. When a refresh token is issued or renewed, the active session is now extended as needed to cover the token’s remaining validity. This does not extend the user’s browser sign-in session.

This release adds on-demand Directory Connector synchronisation, keeping FoxIDs user accounts aligned with the authoritative external directory throughout authentication and session flows.

Users, identifiers, claims, account status, and password requirements can now be synchronised when needed, including during sign-in, password recovery, session reuse, and refresh-token requests. The Active Directory connector has also been extended to support the same synchronisation behaviour.

New Features and Improvements

On-demand Directory Connector Synchronisation

Directory Connector now supports on-demand synchronisation, keeping FoxIDs accounts aligned with the authoritative external directory during sign-in, password recovery, session reuse, and refresh-token requests.

Synchronisation can create accounts when needed and update email addresses, phone numbers, usernames, attributes, claims, and password requirements. Disabled or deleted directory accounts are reflected in FoxIDs at the next synchronisation, revoking their active sessions and refresh token grants.

Users can also set a password at their first sign-in using an email or SMS confirmation code, even before their first successful login. This supports both forgotten-password scenarios and initial password setup when the corresponding recovery method is enabled.

Active Directory Connector

The Active Directory connector now supports on-demand synchronisation, including account status, password expiry, and requirements to set or change a password.

This release introduces major improvements to claim transformation, impersonation, session handling, and application context in FoxIDs. New capabilities include impersonation with full session and audit support, application request parameters, _session: claims, targeted user and Claims API lookups, and preservation of JSON claim value types across authentication flows.

It also strengthens security with protected claims, improves internal claim handling, reduces session cookie size by moving shared session data to the database, and improves SAML single logout consistency.

The release also removes the long-obsolete up_party and up_party_type claims. Applications and integrations still using these legacy claims must migrate to auth_method and auth_method_type.

Phasing out

Removal of obsolete authentication method claims

The legacy up_party and up_party_type claims, including their SAML equivalents, have been marked obsolete since FoxIDs 1.3.0 (11 March 2024). Their built-in support has now been removed.

This is a breaking change only if your applications, claim transforms or integrations still depend on the legacy names. No action is required if you already use the current claims.

Use these JWT claims:

For SAML, the replacements under http://schemas.foxids.com/identity/claims/ are:

• upparty → authmethod
• uppartytype → authmethodtype

The current claims identify the last authentication method used.

New Features and Improvements

Impersonation

Added an Impersonation claim transform for authentication methods. Applications receive the target user's identity and an act claim identifying the original authenticated user.

Load the target through an internal user query, a Claims API, or both. Configure claim transforms to check the authenticated user's permission and any requirements for the target before selecting impersonation.

Use a _session: claim to retain the target reference, and configure transforms to reload and check the target at each application login. Starting, changing or ending impersonation changes the sid and revokes the previous active session and refresh token grants. Continuing with the same target retains the session ID.

For linked internal target accounts, account disablement, deletion and Access Structure access revocation also apply to the impersonated session. The Control Client and Control API show the original and impersonated users in active sessions and refresh token grants. Audit events record when impersonation starts, changes or ends.

Application request parameters

Applications can now pass request parameters to claim transforms as _local:params:{name} claims. Configure Allowed request parameters on the application registration, for example profile_id or departments. Space-separated values automatically produce multiple claims.

Supported requests include OpenID Connect authorisation, SAML 2.0 and WS-Federation sign-in, and OAuth 2.0 / OpenID Connect client credentials and token exchange.

During browser login, parameters are available from authentication-method first-level transforms through Extended UI and application transforms. Map a parameter to a _session: claim when its value should be retained for subsequent application logins.

Session claims

Added _session: claims for retaining values for the same authenticated user across application logins through the same authentication method.

Session claims are restored before first-level claim transforms, remain available through Extended UI, and are saved after successful second-level transforms. They are bound to the original authenticated user and follow the authentication method's session lifetime. Sessions must be enabled; they are enabled by default.

Copy a session value to an _internal: claim when it is needed in application transforms. Session claims are not issued in tokens or assertions.

Targeted claims from user queries and Claims API

Added an optional Target to Query internal user and External claims API tasks. Selected claims are loaded into a local namespace, such as _local:target:sub and _local:target:email, for subsequent checks and transforms.

Multiple queries and API calls can populate the same target using the existing Add and Replace actions. An internal user query with a Target retains the login's original local account association.

Internal user queries also include forwarded Access Structure claims and local membership helpers, enabling checks on the target user's access before impersonation or other processing.

Improved internal claim handling

Internal _internal: claims are preserved across claim transform sets, Extended UI steps and JWT/SAML conversion without requiring entries in Forward claims.

Configured claim transforms can create internal claims and map them to ordinary output claims. JWT/SAML protocol mappings cannot create reserved claim types, and additional filtering prevents reserved claims from being issued through JWT output or static client claims.

Claim value types and JSON support

Claim value types, including JSON objects, arrays, booleans and numbers, are preserved through Map transforms, sessions, Extended UI, authorisation codes and refresh token grants. OpenID Connect UserInfo returns values with their corresponding JSON types.

JWT-to-SAML mapping carries JSON values as text in string attributes. SAML-to-JWT mapping recognises valid JSON objects and arrays in string values and restores their JSON types.

The act claim is issued as a JSON object, and token exchange preserves existing actor chains. Its default SAML mapping is http://schemas.foxids.com/ws/identity/claims/act, which can be changed in the environment's claim mappings.

Protected claims

Added protection for FoxIDs-managed claims controlling sessions, token validity and authentication-method routing, including sid, iss and auth_time.

Protected claims cannot be configured as transform or dynamic UI outputs, used in custom JWT/SAML mappings, or supplied as static application, scope, user or Access Structure claims.

Protected claims returned by Claims API, Extended UI validation API, External Login API and Directory Connector API are discarded.

Smaller session cookies and improved session handling

Session tracking and logout information shared between applications are now stored in the database. The corresponding browser cookie contains only a small reference, reducing cookie size when users sign in to multiple applications.

SAML single logout uses the values recorded when each application signed in, without rerunning claim transforms. This ensures consistent logout even if the application's configuration subsequently changes.

Bugs Resolved

Authenticator app code autofill

Updated the authenticator app code field to use autocomplete="one-time-code", improving recognition by password managers that support autofilling verification codes.

New Features and Improvements

Browser PIN

FoxIDs now supports Browser PIN as a built-in additional factor in both simple two-factor mode and Advanced multi-factor. A user registers the current browser and protects it with a numeric PIN. The protected browser cookie and knowledge of the PIN complete the factor; Browser PIN cannot be used as primary authentication.

A registration is shared by the environment's Login authentication methods. Each user can register up to five browsers, while a browser holds one current registration for that user, environment and host. FoxIDs does not store the PIN, a PIN hash or other PIN verification data on the user.

Users can select Browser PIN setup while completing another available factor. If Browser PIN is the only available factor and the user has no existing Browser PIN registrations, the first registration can follow the primary sign-in directly. Later registration or replacement requires verification with a different factor, a configured Authentication Action, or administrator removal of the existing registrations.

Environment settings control the PIN length, rejection of weak PINs, sliding cookie lifetime and optional absolute lifetime. Advanced multi-factor can notify a backend when a Browser PIN is registered or updated. Control API operations support listing, removing and synchronising registrations between FoxIDs deployments. Successful Browser PIN authentication contributes the AMR value browser-pin.

Authentication Actions

FoxIDs now supports Authentication Actions, which start an action flow using a configured authentication method from a dynamic link.

The supported action types are Register authenticator app and Register Browser PIN. Authentication Actions require the user to authenticate again before the action continues. When a requested, first-factor or session user is known, FoxIDs verifies that the action resolves the same internal user.

When Advanced multi-factor is disabled, registering a new authenticator app replaces the existing registration. When Advanced multi-factor is enabled, the new registration is added if capacity is available.

Registering a Browser PIN replaces the registration represented by the current browser cookie. If the browser has no registration for the user, FoxIDs adds one if capacity is available.

Require Authentication Each Time

Authentication methods and individual profiles can now enable Require authentication each time. FoxIDs then bypasses an existing authentication-method session and requests a new authentication whenever the method or selected profile is started.

Enabling the setting on an authentication method applies it to the base method and all profiles. Enabling it on an individual profile applies it only when that profile is selected.

FoxIDs sends the corresponding authentication request to external identity providers. Login and External Login authentication methods bypass their existing authentication-method sessions. Authentication Actions always require authentication each time.

Dynamic Link Elements

Added separate URL link element, Authentication action link element, and Authentication method link element types.

Link text and destination are configured independently, allowing the visible link text to be translated. Authentication method link elements let you select an authentication method and, optionally, one of its profiles.

Authentication action and authentication method links can also be embedded in Text/Markdown, HTML, Large Text/Markdown, and Large HTML content. Authentication method destinations use one of these formats:

• foxids://authentication-method/<authentication-method-name>
• foxids://authentication-method/<authentication-method-name>+<profile-name>

URL destinations are validated as absolute http, https, or mailto: URLs. Links in HTML, Markdown, and Large content are validated when the configuration is saved.

Start Authentication Methods from Dynamic Links

A dynamic link can now start a selected authentication method during a Login authentication flow.

Following the link starts a new authentication sequence with the selected method and optional profile. After authentication is completed, the current application login continues.

Authentication method links are supported on identifier, password, passwordless-code, user-creation, and Extended UI pages owned by a Login authentication method.

Show Dynamic Elements on Selected Pages

Dynamic elements now support a Show on configuration, including the new link elements.

Elements can be shown only on selected pages, such as username, password, passwordless, user creation, MFA, authenticator app registration and recovery code, Browser PIN registration, and Extended UI pages. Authentication action and authentication method link elements offer only the pages supported by their destinations.

This makes it possible to tailor dynamic content to specific stages of the authentication flow.

Optional password change during sign-in

Login authentication methods can now show a Change password checkbox during password sign-in. Enable Show change password option to make it available.

The checkbox has its own movable Change password option element in the Login UI, making its placement fully customisable.

The option is enabled for new Login authentication methods created in the Control Client. Control API create and update requests default to false to preserve existing behaviour.

Optional MFA login during sign-in

Login authentication methods can now show a secondary Log in with MFA button during password sign-in. Enable Show MFA login button to let users request MFA for the current sign-in when MFA would otherwise be optional.

When MFA is already required by the Login authentication method or requested with urn:foxids:mfa, enabling the setting changes the primary button from Log in to Log in with MFA instead of adding a secondary button. If the setting is disabled, the normal Log in button remains visible, while MFA is still required after password validation.

The displayed buttons never depend on whether the entered account exists or has a user-specific MFA requirement. This prevents the password page from disclosing account or MFA information before authentication. The corresponding Control API property is enableMfaLoginButton and defaults to false.

Set Password Extended UI

Added a Set password Extended UI module for users who have been verified by an authentication method and need to set a password on an internal FoxIDs account.

The page shows the account's username, email address or phone number according to the identifier configuration on the Login authentication method. The user can set a password without entering the current password or select Continue without setting a password. Both choices continue the normal login flow.

Claim transforms identify exactly one active internal user through _internal:set_password_user_id, either by mapping a trusted user ID claim or by using Query internal user. FoxIDs uses the selected account for the password update and the continued login. The login is rejected if it is already associated with a different internal account.

The authentication method or selected profile must enable Require authentication each time.

Internal Claims in Claim Transforms

Added the protected _internal:* claim namespace for trusted values that need to pass between internal claim-transform sequences.

Internal and external user queries now expose the stable user ID as _local:internal_user_id and _local:external_user_id.

Protection of the reserved _local:* and _internal:* namespaces has also been strengthened. Claims in these namespaces cannot be supplied by external sources, stored on users, or returned to applications.

More Flexible Regex Map Claim Transforms

Regex map claim transforms now accept exactly one capture group, which can be unnamed or use any valid group name. The capture group no longer has to be named map.

Existing saved expressions continue to prefer the map group when present. Otherwise, the first capture group is used.

Regex syntax and capture-group count are validated when the claim transform is saved or updated, providing clear errors for invalid expressions.

Authentication Method Profiles Retained Across Sessions

Authentication method profiles are now included in session tracking.

When a valid FoxIDs session is reused, FoxIDs retains the previously selected profile if it is still allowed by the application. If the profile is no longer allowed, FoxIDs follows the application's current authentication method selection rules instead of silently selecting another profile.

This behaviour is consistent across supported authentication flows and single logout.

Improved Enum Validation in the Control API

The Control API now consistently rejects undefined enum values before they reach application logic.

Existing persisted configurations remain readable and backward compatible.

Improved Control Client Session Expiration Handling

The Control Client now checks active login sessions every 10 minutes.

If the session can no longer be renewed, the current page is blurred and a dialog prompts the user to log in again. This provides a clearer and more predictable experience when an administrative session expires.

Automatic exposure of default resource scopes

Scopes added to the default resource of an OAuth 2.0 or OpenID Connect client are now automatically exposed by the application’s resource. FoxIDs creates the resource when the first scope is added. Removing a client scope does not remove it from the resource; this must be done explicitly on the OAuth 2.0 Resource tab.

Bugs Resolved

Directory Connector Error Handling

Fixed a null reference exception that could occur when a Directory Connector API returned an empty error response.

FoxIDs now reports a clear contract error that includes the HTTP status code, making connector issues easier to diagnose.

This release improves browser error handling, Directory Connector integration, API localisation, claim processing, and platform security across FoxIDs.

User-facing error pages now keep technical diagnostics in the logs while showing clearer messages and additional troubleshooting identifiers. Directory Connector integrations can return a dedicated login_rejected response with an optional localised UI message, and selected FoxIDs culture settings are now forwarded to connected APIs.

The release also strengthens handling of claims returned by external APIs, reduces the amount of unauthenticated Control Client configuration exposed before login, tightens Content Security Policy (CSP), and improves health check responses by removing internal error details from HTTP responses while preserving diagnostics in the logs.

In addition, SAML metadata generation and Home Realm Discovery (HRD) behaviour have been corrected in specific edge cases.

New Features and Improvements

Improved Browser Error Pages

Technical diagnostics are kept in the logs while helpful user messages remain visible.

The Sequence ID, when available, is now shown alongside the Operation ID, making troubleshooting easier.

Directory Connector Login Rejection and API Localisation

Added support for login_rejected with an optional uiErrorMessage that is shown directly on the login form.

If the message is missing or blank, FoxIDs uses the existing general login error while keeping diagnostic details in the logs. Directory Connectors must verify the supplied credentials before returning login_rejected.

Directory Connector, External Password, and Extended UI now send the selected FoxIDs culture in the Accept-Language header, allowing connected APIs to return messages in the same language as the login page.

Improved Handling of Empty Claims from External APIs

FoxIDs now ignores claims with a missing, null, empty, or whitespace-only type or value in responses from:

• Claims API
• Extended UI
• External Login
• Directory Connector

When trace message logging is enabled, received claims are logged before filtering to support troubleshooting. Long trace messages are truncated.

Control Client Settings and Content Security Policy

Before login, the Control Client now returns only the configuration required to start the login process. Other settings require an authenticated session and access to the relevant tenant.

The Content Security Policy (CSP) has also been tightened to further restrict dynamic JavaScript execution and allowed content.

Improved Health Check Responses

Health check endpoints now return fixed messages and HTTP status codes without exposing internal error details.

Failed component checks continue to return HTTP 503, allowing monitoring systems to detect operational issues.

Bugs Resolved

SAML Metadata Generation After Metadata Import

Fixed an issue where SAML metadata generation could fail with SAML binding '0' not supported after metadata import.

Unspecified bindings now default to HTTP-POST, and existing zero values are normalised when configurations are loaded and saved. Explicitly configured bindings are preserved.

Correct Home Realm Discovery After Authentication Method Changes

Fixed a rare issue where an existing session could cause a local password prompt instead of the expected OpenID Connect redirect after changing an application's allowed authentication methods.

Home Realm Discovery (HRD) now resumes correctly when the previous Login session has expired or its cookie is missing.

This release improves authentication reliability, identifier flexibility, and OpenID Connect configuration management across FoxIDs.

FoxIDs can now detect and stop likely authentication loops, supports a broader set of valid usernames while retaining existing email compatibility, and keeps automatically managed CORS origins aligned when OIDC redirect URIs change. It also resolves an issue where existing users could not always be found through additional email or username identifiers.

New Features and Improvements

Authentication Loop Detection

FoxIDs now detects repeated browser-based sign-ins to the same application and stops likely authentication loops before another authentication method is started.

Detection is enabled by default for OpenID Connect, SAML 2.0, and WS-Federation applications and is tracked separately for each application registration. Only successful authentication responses are counted.

By default, the next request is blocked after 5 successful responses within 20 seconds. Both the limit and observation period can be configured per environment.

More Flexible Usernames and Email Addresses

FoxIDs now supports a broader, controlled set of characters and internal spaces in usernames, including usernames provided through Directory Connectors and Active Directory.

Existing email address formats remain supported. Email identifiers can be up to 100 characters, while usernames can be up to 60 characters.

Leading and trailing whitespace is still removed before validation and matching.

OIDC Redirect URI Changes Update CORS Origins

When an OpenID Connect application registration is created in the FoxIDs Control Client, the redirect URI origin can be added automatically as an allowed CORS origin.

Changing the redirect URI now also updates matching CORS origins that are managed automatically. CORS origins that have been edited separately are preserved.

Bugs Resolved

User Lookups Through Additional Identifiers

Fixed an issue where FoxIDs could fail to find an existing user when the supplied email address or username was stored as an additional identifier.

This could prevent an existing login session from being reused. User lookup now correctly considers additional identifiers.

This release improves SAML troubleshooting and enhances MFA assurance handling for NemLog-in.

FoxIDs now provides more useful diagnostics when SAML messages are missing required binding data, while the NemLog-in template can issue the OpenID Connect amr claim with the value mfa when NemLog-in reports a Substantial or High level of assurance.

New Features and Improvements

Improved SAML Error Diagnostics

FoxIDs now logs incoming query and POST data as message traces when SAML authentication, logout, or single logout messages fail because required binding data is missing.

If the request data cannot be read, FoxIDs logs a warning instead.

This provides better troubleshooting when message tracing is enabled, without changing SAML protocol handling or session behaviour.

NemLog-in MFA Assurance

The NemLog-in template now issues the OpenID Connect amr claim with the value mfa when NemLog-in reports a level of assurance (LOA) of Substantial or High.

These assurance levels guarantee multi-factor authentication, whether the user authenticated directly with MitID or through a trust relationship with another highly trusted identity provider. FoxIDs therefore asserts mfa without claiming a specific authentication method.

The configuration is applied when a NemLog-in authentication method is created or updated through the template.