Connexion v26 replaces several Windows- and transport-specific security mechanisms with a cross-platform identity, permission, certificate, and configuration-protection model.

The result is a more consistent security boundary across the desktop client, services, APIs, Gateway, Linux, containers, and MCP.

Connexion now discovers and uses authentication through a provider catalog instead of hard-coded branches in each transport.

The built-in authentication choices exposed to administrators are:

• Windows Integrated authentication — uses the signed-in Windows identity and is available on Windows deployments.

• Connexion-managed local usernames and passwords — provides identities managed directly by Connexion and does not require an external identity provider.

• OpenID Connect (OIDC) — delegates interactive sign-in to a configured standards-compliant identity provider.

Servers advertise the authentication providers they support during the initial connection handshake. Clients can then choose an appropriate configured provider.

OpenID Connect, identity providers, and bearer tokens

Microsoft Entra ID, Okta, Auth0, and similar services are examples of identity providers that can support OpenID Connect. They are configured through Connexion's OpenID Connect option rather than as separate authentication modes. After a successful OIDC sign-in, the identity provider issues a token that Connexion transmits as a bearer token. In this context, bearer token describes how the OIDC token is carried; it is not a separate administrator-selectable sign-in provider.

The provider infrastructure can also load external authentication plugins. This allows you to plugin custom authentication providers, should your organization use something specific (and not supported by Connexion).

Authentication answers who the caller is. It does not by itself decide what that identity may do.

Open

Enabled authentication providers are set in the configuration wizard. Each provider requires an administrator credential which is used to connect and configure additional authentication via the UI. Multiple providers can be enabled, and each UI will cycle between providing credentials for each supported provider.

Connexion maps authenticated users and groups to authorization permission sets. v26 supports generic identities from the configured authentication providers, extending the Windows and Active Directory model used in v16. Permissions are enforced by the services for queue operations, message access, package management and certificate actions, including Gateway paths.

Open

Mapping between external groups and internal roles.

Certificates can now be managed as configuration-database entities instead of requiring every device to point to a thumbprint or file that was manually installed on one machine.

The certificate management view provides a central place to monitor certificate expiry and replace certificates while preserving existing device references.

Two storage approaches support different operating models:

Devices reference a managed certificate key. Connexion also tracks certificate usage so administrators can see which devices and purposes depend on a certificate before rotating or deleting it.

Certificate import, update, export, deletion, and device assignment require the Manage Certificates permission and are audited.

Open

Manage certificates centrally

The platform certificate service resolves certificates through the appropriate host implementation:

• Windows certificate stores on Windows.

• PEM, PFX, CRT, or P12 files from the configured certificate directory on Linux.

• Managed certificate payloads shared through the configuration database.

• External references aligned with the deployment platform.

This allows the same device configuration to move with channel ownership in a multi-active deployment instead of depending on an untracked certificate installed on the previous host.

v26 removes the dependency on Windows DPAPI for product configuration.

Sensitive values such as database connection strings, OIDC secrets, certificate passwords, metrics credentials, and bootstrap passwords are protected using cross-platform mechanisms:

• Standalone Windows and Linux installs use an ASP.NET Core Data Protection key ring stored with the installation's protected settings.

• Container/database-bootstrap deployments use protection derived from the shared configuration database identity so cluster nodes targeting the same database can read the same protected configuration.

Standalone configuration files are not automatically portable to another host because their key ring is local. Container/database-backed configuration is designed for cluster portability.

Protection applies to persisted configuration. The running process must still hold usable plaintext values in memory when connecting to a database or external service.

Current v26 development improves mutual-TLS identity validation, OIDC identity matching and local-password group membership. Application-server peers authenticate with a shared cluster secret. Protected-setting handling and credential redaction have also been strengthened across service, client and diagnostic paths.

Administrators can replace a managed certificate while preserving its key and device references. Certificate validity timestamps are handled consistently in UTC, and setup checks improve detection of unusable certificate configurations.