Custom logout which style to use: REST endpoint or Jakarta filter

Getting advice
1

Hello,

I need to implement some custom logout functionality that needs access to the browser request/response context. The first idea I had was to implement a server REST api endpoint that mimics the builtin methods for logout protocol/openid-connect/logout and also handles my custom logout requirement.

Another idea from a super smart teammate was to simply implement a Jakarta filter that intercepts the logout

@Provider
@Priority(1000)
public class LogoutRequestFilter implements ContainerRequestFilter {
    @Override
    public void filter(ContainerRequestContext requestContext) throws IOException {
        String path = requestContext.getUriInfo().getPath();
        if (path.contains("protocol/openid-connect/logout")) {
           //... custom logout logic here
       }
}
// keycloack logout logic runs next.......

This seems like a much better implementation than a custom REST endpoint. It does not involve configuring META-INF.services with an SPI name. I have not seen Keycloak extended in this fashion before. Is there any downside to this ?

Thanks!

2

There isn’t a good way to load filters into Keycloak, and they also haven’t created any way to hook into the logout flow (the same way you can hook into the login flows with Authenticators). If you need to modify the logout behavior, I don’t think it is possible. If you want it to have a side-effect, you can do it by implementing EventListenerProvider, where you can have access to the request and response via the [KeycloakContext](https://www.keycloak.org/docs-api/latest/javadocs/org/keycloak/models/KeycloakContext.html).

3

Thanks for the response. The Jakarta filter works, I am just wondering what the downside of such an implementation would be?

4

Thanks for that information. I didn’t know you can add a Jakarta filter to Keycloak. Can you show how you did that?

5

You implement the filter as shown in my initial post, include it in the .JAR and it just works. This is extension outside of the sanctioned model for server development so I was wondering about any downside. I guess if the architecture moved from Jakarta to some other app engine (as it has in the past moved from WildFly=>Jakarta) then this implementation style would not longer be valid.

This is also useful for the /TOKEN endpoint when you want to issue an SSO cookie from another auth system but dont want to do so in IsValid() of the userstorage SPI or authenticator becuase the authcode has not been exchanged for tokens (with all the commensurate protections like PKCE).

Thanks!
-Jon