Summary

I wanted to extend JwtAuthenticationConverter in the resource server and override convert method to return my own implementation of AbstractAuthenticationToken from the Jwt.

Actual Behavior

Currently the method in JwtAuthenticationConverter is final as below

public final AbstractAuthenticationToken convert(Jwt jwt) {
        Collection<GrantedAuthority> authorities = extractAuthorities(jwt);
        return new JwtAuthenticationToken(jwt, authorities);
    }

Expected Behavior

I am thinking that final could be removed so that I can override convert method as below in MyJwtAuthenticationConverter which extends JwtAuthenticationConverter .

public AbstractAuthenticationToken convert(Jwt jwt) {
        Collection<GrantedAuthority> authorities = extractAuthorities(jwt);
        return new MyJwtAuthenticationToken(jwt, authorities);
    }

I am planning to extend JwtAuthenticationToken for MyJwtAuthenticationToken

@jzheaux , was there a reason you made the method public? If yes and that should be final, I will implement MyJwtAuthenticationConverter without extending JwtAuthenticationConverter, but very similar to it. Please let me know your comments.

Comment From: jzheaux

Good question, @ajmalch, thanks for reaching out. I think you have the right idea in implementing the Converter interface yourself.

The reason is that it's good to favor composition over inheritance. The existing construct encourages that approach.

UPDATE: Note that in 5.2 the majority of the logic in this converter it moved out to a granted authorities converter, so hopefully that will reduce copy-pasting if it comes to that.

In the meantime, consider doing:

public MyConverter implements Converter<Jwt, AbstractAuthenticationToken> {
    JwtAuthenticationConverter converter = new JwtAuthenticationConverter();

    public AbstractAuthenticationToken convert(Jwt jwt) {
        JwtAuthenticationToken token = converter.convert(jwt);
        // your custom work to translate it into your custom token
    }
}