Using client secret to signing tokens instead of realm keys

Getting advice
,
1

Hello together,

I already want to thank you for your advices and hints.
Currently I am trying to fetch a token from the token endpoint of keycloak with a java app using pac4j and nimbus.

The app is configured with HS256 as preferred signature algorithm.
I configured keycloak with a client id and a secret and also entered both into the configuration of pac4j.

When I try to authenticate with keycloak I receive the following error message:
Signed JWT rejected: Another algorithm expected, or no matching key(s) found
The reason for that is, that the kid and the client secret (which is used by nimbus) do not match.

So there are basically 2 approaches which I have tried.

  1. I tried to add a 2nd secret to pac4j which fits the kid defined in the realm keys for hmac-generated

    image
    image1287×188 15.5 KB

  2. I tried to change the kid which is sent by keycloak to the client secret.

Unfortunately I have not managed to force keycloak to use the client secret instead of the generated kid.

Is there are any chance or another approach how I can connect these two applications?

Again thank you very much and best regards,
Timo

2

Not sure why Nimbus would be using client secret as key to validate the JWT Token.

I used Pac4J a little and it could do the jwt validation ok, but I was using it as an OIDC client, so not sure how to configure it in your use case.

I suppose you can download the keys yourself from the jwks_uri endpoint. For keycloak, that would be:

<KEYCLOAK_BASE_URL>/realms/<REALM_NAME>/protocol/openid-connect/certs

See item 4 of this doc: pac4j: security for Java on how to use a JWK endpoint for key validation.

3

Thank you very much.
I think this is a good hint. To be honest I do also not know why it is taking the secret instead of going to such an endpoint.
But this is a good approach.

Basically I also just want to use it as an OIDC client. But it turns out it’s not working out of the box for me with such weird issues.

Thanks again

Edit: In pac4j there is a class TokenValidator() which sets up an IDTokenValidator with the oidc configuration, the jws algo, cliend id and secret (Tokenvalidator.java, Line 74)
I guess I should not use this one.