What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To secure a JAX-RS application with OpenID Connect (OIDC) using pac4j, first choose the authentication flow: use an indirect OIDC client for browser login and redirects, or a direct header client when API callers already send bearer tokens. Then select the pac4j integration module for your JAX-RS runtime, configure the provider, and register the callback and profile-injection components required by that runtime.
Choose the authentication flow and JAX-RS runtime
Browser login and API bearer-token authentication are different designs. Browser login redirects a user to an identity provider and needs state retained across the redirect. An API request with an existing access token instead sends an Authorization: Bearer header and does not need a browser redirect or local login session. The pac4j JAX-RS guide demonstrates both patterns; follow its official JAX-RS integration guide for the runtime-specific setup.
| Decision | Browser login | Bearer-token API |
|---|---|---|
| Request pattern | Redirect to the identity provider, then return to the callback | Caller sends an access token in the Authorization header |
| pac4j approach | Indirect OidcClient |
Direct HeaderClient using the OIDC profile creator |
| Session handling | Session support is needed to retain login state | The guide uses a no-op session store |
| Callback | Register the externally reachable callback URI with the provider | Set the OIDC callback URL to notused in the guide’s pattern |
Choose the integration artifact that matches the actual JAX-RS runtime line: the guide lists jersey3-pac4j, jersey4-pac4j, resteasy6-pac4j, and resteasy7-pac4j. Its standalone example uses Java 17 or later, Maven, Jersey 4 with Grizzly, jersey4-pac4j 8.0.0, and pac4j-oidc 6.5.8. Treat these as example versions, not a compatibility guarantee; check the pac4j dependency documentation and release information against your project’s runtime and dependency versions.
Configure OIDC browser login
Set provider discovery and client credentials
Register an OIDC client application with your identity provider and obtain its client ID and secret. In pac4j, configure an OidcConfiguration with those credentials and the provider’s discovery URI, typically ending in /.well-known/openid-configuration. Discovery metadata supplies protocol endpoints such as authorization, token, user-info, and JWKS endpoints; the pac4j OIDC documentation describes the generic client and provider-specific alternatives.
#1 Best Overall
Construct an OidcClient from the configuration and add it to a pac4j Config together with the callback base URL, for example new Config(baseUrl + "/callback", new OidcClient(oidcConfiguration)). Keep the client name consistent: the generic client is named OidcClient in the guide.
Register the exact callback URI
Register the full externally reachable callback URI with the identity provider, including pac4j’s client-name query parameter: https://your-public-host.example/callback?client_name=OidcClient. Replace the example host and path with the application’s public URL. Include any application context path, and account for a reverse proxy if the URL seen by the identity provider differs from the internal application address. A redirect URI mismatch commonly means the provider registration does not exactly match the URI pac4j uses, including the query parameter.
Wire the JAX-RS runtime and protect resources
Register the runtime feature that provides request and session access, pac4j’s Pac4JSecurityFeature, and the runtime-specific profile injector. Add callback and logout resource methods annotated with @Pac4JCallback and @Pac4JLogout. Protect a resource or class with @Pac4JSecurity(clients = "OidcClient"), and use @Pac4JProfile where the application needs the authenticated profile.
- Jersey with Grizzly: the guide registers
Pac4JGrizzlyFeature,Pac4JSecurityFeature, andPac4JValueFactoryProvider.Binder. - Servlet deployment: register
Pac4JServletFeature(config)to provide access to the container’sHttpSession. - RESTEasy with CDI: use the security feature and
Pac4JProfileInjectorFactory, rather than Jersey’s value-factory binder. - Dropwizard: the pac4j bundle handles much of the servlet/security feature registration and profile injection.
Use the exact feature and injection setup for your runtime. If @Pac4JProfile is not populated, check that the runtime-specific value factory or injector is registered.
Rank #3
Use a direct client for API bearer tokens
When callers already possess an access token, configure a direct-client path instead of sending them through interactive login. The guide adds pac4j-http for HeaderClient, sets the OIDC callback URL to notused, initializes the OIDC client, and configures the header client to read the Authorization: Bearer prefix. The header client uses the OIDC client’s profile creator to validate the token through the provider’s user-info endpoint; the example uses a no-op session store.
This pattern is for an API request that already carries a token. It is not the browser callback-and-session flow. If the API returns 401, check that the token is for the expected issuer/provider and that it has the required openid scope, then confirm the provider accepts it at its user-info endpoint.
Quick Recap
Keep demo security settings out of production
- Remove unsigned ID-token allowance. The guide’s demo includes
setAllowUnsignedIdTokens(true); remove that setting when using a real provider so signature verification uses the provider’s JWKS. - Retain browser state. A login loop or lost state can indicate that the indirect OIDC client lacks session support. Use the appropriate Grizzly or servlet feature for the deployment.
- Review session identifier renewal. The Grizzly example sets
renewSession = falseand warns about session fixation. The guide recommends a servlet-backed runtime withrenewSession = truefor deployment, or validating renewal behavior against the Grizzly version before enabling it. - Use provider-specific configuration only when appropriate. pac4j documents provider-specific clients as well as the generic discovery-based client. If switching client type, keep the client name aligned in the callback registration and
@Pac4JSecurityconfiguration.
Verify the integration before deployment
- Confirm the dependency module matches the deployed Jersey or RESTEasy version, and check that the versions resolve together for the project’s Java version.
- Verify the discovery URI is the provider’s OIDC metadata endpoint and that the client ID and secret belong to the registered application.
- Compare the callback URI configured in pac4j with the provider’s registration character for character, including scheme, host, path, context path, and
?client_name=OidcClient. - For browser login, confirm the runtime supplies session access and that callback and logout resource methods are registered.
- For protected resources, confirm the security annotation names the configured client and the runtime-specific profile injector is installed.
- For bearer-token APIs, verify the caller sends the expected bearer token and that the provider accepts it through the configured user-info flow.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →
