@patrick-primesign - while I leave the final comment for the core team, here is something I noticed:

You make this protected so a derived class can access it. At the same time you're passing it in to some methods. Can we be consistent to only pass it to methods, as I would assume it would make the code simpler to follow?

As you've been adding protected methods / making methods protected, it might be good to add some Javadoc to them explaining how they are intended to be used.

@ahus1 yeah, I agree, we needed it in our implementation for getRawBearerToken(), which normally would use the http headers.
I will add response and headers as parameters getRawBearerToken, to make it more readable or consistent.
Javadoc I will also add.

I pushed some changes to the commit.

The logic is hard to understand as denyRequest() might have already been called.

Actually we don't use this, so I will remove it, as the only reason it is there is that we possibly could use it. :)

Instead of wrapping this here, I'd suggest only to change the line above:

Status status = extractStatusFromResponse(response);

... and then someone can override the one method extractStatusFromResponse.

Or thinking one step further, add the status to the BackchannelAuthCallbackContext, and it can be part of the extendable verifyAuthenticationRequest(). If doing that, the rest of the code can be left as is.

For our use case this unfortunately doesn't make sense. We don't verify the request itself, we have to check other things (from the database), e.g. our own timeout and other factors which will turn the status to UNAUTHORIZED if they are not met.

Seems legit. The method extractStatusFromResponse should extract some kind of status from the response. But Keycloak might have a saying as well, without checking on any status from the response.