Secure Undertow Client Apps with OIDC Using pac4j
Learn how to connect an Undertow application to an OIDC provider using undertow-pac4j v6.1.0 on Java 17 with configuration steps and code examples.
Stock photo for illustration only, not from the actual event
- Uses undertow-pac4j v6.1.0, Undertow v2.4, and Java 17 in a Maven project
- Adds three core handlers: SecurityHandler, CallbackHandler, and LogoutHandler
- Supports OIDC providers like Keycloak, Google, Microsoft Entra ID, and Okta
- Handles sessions via SessionAttachmentHandler with HttpOnly JSESSIONID cookies
Connecting an Undertow application to an OpenID Connect (OIDC) provider can be achieved seamlessly by utilizing the undertow-pac4j library. By adding three essential handlers—SecurityHandler, CallbackHandler, and LogoutHandler—to the PathHandler, developers can establish robust security and authentication workflows.
This setup leverages undertow-pac4j v6.1.0, Undertow v2.4, and Java 17, following configuration patterns similar to the Spring Boot OIDC guide. The OIDC provider manages the login interface and user authentication, which can range from enterprise solutions like Keycloak, Google, Microsoft Entra ID, and Okta to public demo servers provided by pac4j.
To begin, create an empty Maven project targeting Java 17 or later, with a pom.xml file configured for the Java 17 compiler and an execution plugin to run the App class. Next, create src/main/java/org/example/SecurityConfigFactory.java to build the pac4j configuration and OIDC client, reading metadata from the discovery URI while appending ?client_name=OidcClient to the callback URL.
Integrating pac4j with Undertow spares developers from implementing custom authentication logic and session management from scratch. The handler-based architecture separates security concerns cleanly, minimizing common vulnerabilities associated with manual token and session handling.
For session management, the SessionAttachmentHandler wraps protected, callback, and logout paths to attach the Undertow SessionManager and SessionConfig to every request, utilizing an HttpOnly JSESSIONID cookie. Default components such as FrameworkAdapterImpl automatically supply necessary web contexts and session stores if undefined.
Regarding protected paths, SecurityHandler.build redirects anonymous users to the OIDC provider while passing authenticated traffic through. Meanwhile, CallbackHandler processes authorization codes, exchanges them for access and ID tokens, validates the tokens, and stores user profiles. Local logouts are handled via LogoutHandler with session destruction enabled.
Stock photo for illustration only, not from the actual event
Once configured, compile and run the application using mvn clean compile exec:java from the project root directory. Accessing http://localhost:8080/protected will redirect users to the identity provider for authentication before returning them to the protected greeting page.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment