Modern Authentication, Authorization, and Certificates
Modern Authentication, Authorization, and Certificates
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.
Authentication providers
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.
Authorization
Authorization remains mostly unchanged from version 16. Connexion is configured to associate a authentication identity with an authorization permission set. This let’s you associate identities with permissions. Version 16 only supported Active Directory / Windows authentication users and groups, where version 26 supports generic identities, and therefore works with any authentication provider.
Central certificate management
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.
Two storage approaches support different operating models:
Mode | Use |
|---|---|
Managed payload | Connexion stores the certificate payload and protected password so every eligible node can resolve it |
External reference | Connexion stores the reference and lets the Windows certificate store, Linux certificate directory, Kubernetes Secret, cert-manager, or another platform mechanism own the payload lifecycle |
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.
Windows, Linux, and clusters
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.
Protecting sensitive configuration
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.