Can I overwrite the logout endpoint?

We have a requirement to add the Cache-Control: no-store, no-cache header to the logout resource?

What is the best way to achieve this?

Can I re-implement/extend the logout resource?

1 Like

The built-in OIDC endpoints are not part of an SPI implementation, and can’t be overridden.

1 Like

Thanks for the response.

I have never tried it, but you may be able to add a header from another extension by

  1. Check to see what the request URI is and match it to the logout endpoint. You can do that with session.getContext().getUri()
  2. Update the HTTP response with session.getContext().getHttpResponse() which has a setHeader method, documented here HttpResponse (Keycloak Docs Distribution 26.1.4 API)

Perhaps another option would be to add the desired header value on the reverse-proxy level, when processing the response(s) from Keycloak!?

2 Likes

why not change the core code and recompile keycloak? @dasniko isn’t that a valid solution? because I recall 4 years ago that the email section didn’t serve my needs, so i changed the code and recompiled the jars and deployed it to wildfly.

Sorry to say, I think that’s the worst possible solution. Forking keycloak core means you have to maintain your changes with every version release. Even with the slower pace of major releases, that’s a lot of work to make sure you are maintaining and testing it properly.

I think @dasniko 's solution is the most elegant, as you can do it without changing anything in Keycloak or in an extension.

I did a test on my suggested solution, and it works properly. If you are already building an extension for other reasons, it’s a valid solution that doesn’t require forking keycloak core.

2 Likes

Nothing to here for @xgp s comment.
Not just because something is technically possible, it is a good solution.

1 Like

No problem guys, I appreciate your thoughts and answers, thank you!

Why not adding its own logout endpoint with your logic?

As an alternative, you can deploy a simple JAX-RS filter into Keycloak. This example does exactly what you’re looking for, but for UserInfo endpoint (you will need to change that to LogoutEndpoint).

Pros:

  • deployed as an add-on, no changes to Keycloak code needed
  • self-contained solution, not depending on reverse proxy
  • no need to configure URL patterns (which might potentially change), the filter will be always bound to the correct endpoint

Cons:

Good luck!

3 Likes

Thank you. This is what we are doing at the moment. I was just hoping for a solution closer to the service.

This looks good. I will give it a try. Thank you!