Upgrading from 11.3.X to 11.4.0#

Deprecations#

Twitter authenticator#

The Twitter authenticator is now deprecated and will be removed in a future release. It acts as an OAuth 1.0a client, a legacy protocol that Twitter (now X) is expected to drop support for. A replacement authenticator based on OAuth 2.0 is planned but not yet available, so no committed timeline for removal can be given at this point. If you rely on the Twitter authenticator, avoid building new integrations on top of it and plan to migrate once an OAuth 2.0 alternative is released.

Configuration breaking changes#

Profile endpoint types#

A profile endpoint’s endpoint-type was not being validated, which allowed configuring endpoints of unsupported types for a specific profile. Requests to such endpoints would fail at runtime.

This has been fixed in 11.4.0, which means existing configurations may become invalid, causing the server to refuse to start up. For this reason, when migrating, we recommend starting the server in a Staging Environment with the exact endpoints used in Production. If the server fails to start, remove the endpoint that caused the error and try again.

Removing endpoints that cause an error does not affect any functionality since such endpoints would never have worked as expected.

Token Issuance Authorizer on the openid scope#

The openid scope is now exempt from Token Issuance Authorization : a Token Issuance Authorizer can no longer be assigned to the openid scope, and decisions targeting openid made by the Global or Post-Claims-Resolution authorizer are ignored, so the scope is always issued when requested and allowed.

A configuration from 11.3 that assigns a token-issuance-authorizer to the openid scope fails validation after the upgrade; remove that assignment before upgrading.

Ephemeral client authentication methods#

The No Authentication client authentication method for Ephemeral clients was not validated against the capabilities it can actually be used with, nor against the OAuth Profile. Configurations that would never work at runtime were therefore accepted. Two rules are now enforced when the configuration is committed:

  • The Client Credentials and OAuth Token Exchange capabilities require a confidential client, so they cannot be enabled for Ephemeral clients when No Authentication is the only allowed client authentication method. Allow Asymmetrically Signed JWT as well, or remove those capabilities.
  • Allowing No Authentication requires the OAuth Profile itself to allow No Authentication as a client authentication method.

As with the endpoint validation above, a configuration that breaks either rule becomes invalid and the server refuses to start. Breaking the first rule costs no functionality, since a public Ephemeral client was already rejected at registration time if it requested client_credentials or the oauth token exchange grant type. The second rule can affect working setups, because before 11.4.0 the OAuth Profile’s No Authentication setting was never consulted when an Ephemeral client registered. Fix the second rule by enabling No Authentication on the OAuth Profile.

Delayed Refresh Token Revocation#

A refresh-token-revocation/grace-period setting was added to the Token Service configuration in version 11.3. This feature requires that a data-source supporting Persistent Jobs be configured (directly in the Persistent Jobs configuration, or via default Caching Services), but this was not validated.

From 11.4, the configuration will be validated so that this feature can only be enabled if a suitable data-source is configured.

New $CspUtil Template Variable#

The Curity Identity Server templates now have access to a new $CspUtil helper variable, alongside the existing $RegexUtil. Its combine method merges two Content-Security-Policy directives that share the same name, taking the union of their sources and removing duplicates. The default settings-defaults.vm template now uses $CspUtil to combine the img-src directive configured under “Look and Feel” (which carries a configured logo’s origin) with the img-src directive set by authenticators that render inline data: images, such as the TOTP, BankID, and Duo device-registration QR codes.

If you maintain a customized settings-defaults.vm, update it to merge the two directives with $CspUtil so that your templates also benefit from this fix.

JDBC Data Source#

PostgreSQL: removed index from the buckets table#

Previously existing index over attributes was removed, as it is not used, to avoid performance penalty related to index updates. Refer to schema-migration for details on how to apply this change to your database schema.

SDK Changes#

HTTP Client#

A new setting, max-http-header-line-size (under facilities/http ), limits the size of a single HTTP header line (the header name plus the : separator plus the header value) on all outbound traffic handled by clients created through the HttpClient SDK service. The limit applies in both directions: outbound requests and their responses whose header line would exceed it are rejected.

The default is 8192 bytes. If your deployment relies on upstream services that send (or expect) larger header lines, raise this value. No action is required if the default is sufficient.

SAML2 Authenticator - empty Audience treated as no audience#

In the SAML2 Authenticator’s AudienceRestriction validation (introduced in 11.3.0), an AudienceRestriction whose Audience elements are all empty (for example <saml:Audience/>) names no audience and is now treated as if the condition were absent: it is accepted when require-audience-restriction is false and rejected when it is true (the default). When at least one non-empty Audience value is present, that value is always validated, as before.

Non-experimental Components#

The following SDK types/methods are no longer marked as experimental:

  • se.curity.identityserver.sdk.attribute.CredentialAttributes.
  • se.curity.identityserver.sdk.authorization.OAuthObligation and its nested types.
  • se.curity.identityserver.sdk.config.annotation.DefaultService.
  • se.curity.identityserver.sdk.service.AccountManager#withCredentialManager.

Persistent Jobs#

New last_heartbeat column in the jobs table#

The jobs table, which backs Persistent Jobs , has a new nullable last_heartbeat column, used to detect and recover jobs left running by a node that crashed. Refer to schema-migration for details on how to apply this change to your database schema.

If the database schema is not upgraded, persistent jobs keep running in a compatibility mode that behaves like version 11.3: jobs are claimed and executed as before, but crash recovery is disabled — a job left in a RUNNING state by a crashed node is not re-executed. The server logs a warning when it detects the missing column.

Note that the schema is only probed once per node: after migrating the database, restart the server (each runtime node) for crash recovery to become active. A node that started against the old schema keeps running in compatibility mode until it is restarted.

Automatic cleanup of completed jobs#

Completed jobs are now automatically deleted after a configurable retention period, 12 hours by default. In 11.3, finished jobs were kept indefinitely. To keep the previous behavior, set the new retention-period setting to 0. Failed jobs are never deleted automatically. See Persistent Jobs for details.

Changed retry behavior#

The default value of max-retries was raised from 1 to 3. In addition, retries of tasks that fail with a retriable error are now deferred with an exponential backoff derived from the polling interval; previously, a failed job was eligible for re-execution on the next poll.

Was this helpful?