back to all blogsSee all blog posts

Simpler OpenID Connect Client configuration using issuer claims in Open Liberty

image of author
Michal Broz on Sep 27, 2022
Post available in languages: 日本語 ,

Open Liberty expands the OpenID Connect Client 1.0 feature to include support for using the issuer claim from the JWT or JWS access token for selecting which openidConnectClient configuration to use for a JWT inbound propagation request. This release also includes an important security vulnerability (CVE) fix, as well as many notable bug fixes.

In Open Liberty

Along with the new features and functions added to the runtime, we’ve also made updates to our guides.

View the list of fixed bugs in

Run your apps using

If you’re using Maven, here are the coordinates:


Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[,)'

Or if you’re using Docker:

FROM open-liberty

Or take a look at our Downloads page.

Ask a question on Stack Overflow

Use issuer claim for selecting which configuration to use for a JWT inbound propagation request (OpenID Connect Client 1.0)

Starting in, the OpenID Connect Client 1.0 feature supports using the issuer claim from the JWT or JWS access token for selecting which openidConnectClient configuration to use for a JWT inbound propagation request. Prior to this release, complicated authentication filters were required if more than one issuer was used for the same resource. Instead, the OpenID Connect Client 1.0 feature can now be configured with simpler openidConnectClient elements for each required issuer.

A Liberty OpenID Connect Relying Party will automatically use the issuer claim from a JWT or JWS access token to select the openidConnectClient configuration with a matching issuerIdentifier attribute.

The following server.xml file example shows two Open ID connect client configurations, with an authentication filter configured to route requests to the RP2 configuration. If a request with an issuer claim value of https://hostname/op1 is presented, the RP1 configuration is selected unless the rp2filter applies to the request.

    <openidConnectClient id="RP1" issuerIdentifier="https://hostname/op1"  ... />
    <openidConnectClient id="RP2" issuerIdentifier="https://hostname/op2" authFilterRef="rp2filter" .../>
    <authFilter id="rp2filter">

Open Liberty selects the openidConnectClient configuration to use for a JWT request according to the following algorithm:

  1. If the authentication filter for a openidConnectClient configuration matches the request, choose that configuration.

  2. Check the issuer claim from the JWT against the issuerIdentifier attributes from of all openidConnectClient elements. If the issuer claim from the JWT matches the issuerIdentifier attribute in only one openidConnectClient configuration element, choose that configuration.

  3. If the issuer claim from the JWT matches the issuerIdentifier attribute in multiple openidConnectClient configuration elements, choose the first configuration that matches.

  4. If the issuer claim from the JWT does not match the issuerIdentifier attribute of any openidConnectClient configuration elements, choose one of the configuration elements in a nondeterministic manner.

For more information about OpenID Connect Client, refer to the OpenID Connect Client specification.

Security vulnerability (CVE) fixes in this release

CVE CVSS Score Vulnerability Assessment Versions Affected Version Fixed Notes



HTTP header injection -

See issue #2245

For a list of past security vulnerability fixes, reference the Security vulnerability (CVE) list.

Notable bugs fixed in this release

We’ve spent some time fixing bugs. The following sections describe just some of the issues resolved in this release. If you’re interested, here’s the full list of bugs fixed in

  • JDBC connection not validated when numConnectionsPerThreadLocal is used

    When a JDBC datasource is configured with validationTimeout, the connection pool should validate a connection before it is passed back to the application. If the connection is invalid (e.g. after a database failover event), other connections in the pool should be purged according to the purgePolicy configuration. The application should therefore rarely receive an invalid database connection.

    However, if the connection manager is configured with numConnectionsPerThreadLocal=1, once a connection is stashed as a ThreadLocal, it isn’t validated before being used by the application, which results in a SQLException. Also, if the application calls isValid on the connection and the connection is determined to be invalid, the connection manager does not apply the purgePolicy logic to other connections in the pool, so clients may see multiple errors until each of the worker threads is used.

        <dataSource id="fhirDatasourcePglocalDefault" jndiName="jdbc/fhir_ibmfhirpg_default" type="javax.sql.XADataSource" statementCacheSize="200" syncQueryTimeoutWithTransactionTimeout="true" validationTimeout="30s">
            <jdbcDriver javax.sql.XADataSource="org.postgresql.xa.PGXADataSource" libraryRef="sharedLibPostgres"/>

    After the fix, with validationTimeout configured, the connection is validated before use and the connection pool is purged of bad connections according to purgePolicy.

  • JobOperator.getRunningExecutions output includes job executions that aren’t running

    A bug caused the Liberty Java batch JobOperator.getRunningExecutions() API call returns all job execution IDs associated with a running job instance, instead of just those job executions IDs that are running.

    After the fix, when JobOperator.getRunningExecutions() is called for that job name, both the original (stopped) and the new (restarted) execution IDs are returned.

  • Removed hideMessage logging attribute not dynamically picked up during server configuration update

    Removal of message ID prefixes from the hideMessage logging attribute was not honored on a running server.

    This issue is now resolved and the configuration of the running server is properly updated to no longer hide the messages that were removed from the attribute.

  • Missing NLS strings for allowAuthenticationFailOverToAuthMethod options

    The AllowAuthenticationFailOverToAuthMethod option descriptions all had untranslated NLS constants. This was due to the constants missing from the NLS file for the metatype.

    With the fix, all the AllowAuthenticationFailOverToAuthMethod option descriptions are now properly translated.

  • Session timing issue during server shutdown

    Due to a session cache service timing issue during server shutdown, it was possible that the invalidation thread hits in the middle of cacheservice teardown. This could occur due to the cache instance not being checked when processing invalid listeners.

    The issue has been resolved in this release.

  • FFDCIgnore not honored on or after

    Starting in, when a resource adapter with a 1.0 spec deployment descriptor was installed, the @FFDCIgnore annotation was ignored causing an FFDC to be incorrectly emitted.

    After the fix, the FFDC is no longer created.

New and updated guides since the previous release

As Open Liberty features and functionality continue to grow, we continue to add new guides to on those topics to make their adoption as easy as possible. Existing guides also receive updates in order to address any reported bugs/issues, keep their content current, and expand what their topic covers.

GraphQL Client Guide

Get Open Liberty now