back to all blogsSee all blog posts

Spring Boot 3.0 support and new security capabilities in Open Liberty

image of author
Laura Cowen on Sep 19, 2023
Post available in languages: 日本語 , 简体中文 ,

You can use Spring Boot 3.x capabilities in your Liberty applications with the new Spring Boot Support 3.0 feature. You can also now authenticate your OpenID Connect clients using the Private Key method, which is more secure than using client secrets, and if you use LTPA or JWT cookies, you can now use different cookies for different applications, according to their context root.

And finally, happy birthday! Open Liberty is now 6 years old. See our history in maker projects.

In Open Liberty

View the list of fixed bugs in

Run your apps using

If you’re using Maven, include the following in your pom.xml file:


Or for Gradle, include the following in your build.gradle file:

buildscript {
    repositories {
    dependencies {
        classpath ''
apply plugin: 'liberty'

Or if you’re using container images:


Or take a look at our Downloads page.

Ask a question on Stack Overflow

Spring Boot 3.0 support

The Liberty Spring Boot Support 3.0 feature provides a more complete support for running Spring Boot 3.0 applications on Liberty. It also provides the capability to thin the application when you create applications in containers.

Prior releases of Liberty provided support for Spring Boot 1.5 and Spring Boot 2.0 applications. Liberty also supported Spring Boot applications packaged as a WAR file, as demonstrated in this recent blog post. With Open Liberty, you can deploy Spring Boot 3.x applications by enabling the springBoot-3.0 feature, with support for both JAR and WAR file types.

To run a Spring Boot 3.x application on Liberty, you must be running with Java 17 or higher. Additionally, if your application uses the Jakarta Servlet feature, it must be Jakarta Servet 6.0. Configure these features in the server.xml file, as shown in the following example:


As with previous versions of the Spring Boot Support feature, you can put Spring Boot application JAR files in the /dropins/spring/ directory. Alternatively, specify the Spring Boot configuration elements in the server.xml file. For example:

 <springBootApplication id="spring-boot-app" location="spring-boot-app-0.1.0.jar" name="spring-boot-app" />

If you have used previous versions of the Spring Boot Support feature and are now migrating your application to use Spring Boot 3, note the following requirements:

Private Key JWT authentication support for OIDC clients

OpenID Connect clients in Liberty now support the private_key_jwt client authentication method with OpenID Connect token endpoints.

OpenID Connect clients are required to provide authentication data to the OpenID Connect provider when they invoke the provider’s token endpoint. Clients can authenticate using several different methods, but most of those methods require a client secret. The private_key_jwt authentication method enables clients to use asymmetric keys to create signed JSON Web Tokens (JWTs) to authenticate instead of client secrets. OpenID Connect clients that use this authentication method are no longer required to have a client secret.

Enable this capability in your client application using the private_key_jwt option for the tokenEndpointAuthMethod attribute, and the tokenEndpointAuthSigningAlgorithm and keyAliasName attributes in either the openidConnectClient or oidcLogin elements in the client’s server.xml file.

For example, when you use the OpenID Connect Client feature, include the following configuration:

<openidConnectClient tokenEndpointAuthMethod="private_key_jwt" keyAliasName="privateKeyJwtAliasRS512" ... />

If you are using the Social Media Login feature, include the following configuration:

<oidcLogin tokenEndpointAuthMethod="private_key_jwt" tokenEndpointAuthSigningAlgorithm="E512" keyAliasName="privateKeyJwtAliasES512" ... />

The tokenEndpointAuthSigningAlgorithm attribute specifies the signing algorithm to sign the JWT that is used for client authentication. The keyAliasName attribute points to the key to use to sign the JWT, and must also be the alias for the public key that corresponds to the private key. The private key must be in the keystore that is specified by the SSL configuration that is referenced by sslRef in the OIDC client configuration. The public key must be in one of the following locations:

  • The truststore that is specified by the trustStoreRef attribute

  • The truststore that is specified by the SSL configuration that is referenced by sslRef

  • The keystore that is specified by the SSL configuration that is referenced by sslRef

For more information about the configuration options, see the docs:

For more information about JWT authentication, see:

In previous releases, LTPA and JWT cookies always had the cookie path set to /, so that any request made to any path on the domain included the cookie. You can now set the LTPA or JWT cookie path to the application context root. With this configuration, you can use different LTPA and JWT tokens for different applications.

Enable the useContextRootForSSOCookiePath attribute in the webAppSecurity element. For example, add the following line to the server.xml:

<webAppSecurity useContextRootForSSOCookiePath="true"/>

For more information about LTPA in Open Liberty, see the docs:

Get Open Liberty now