6

I have the following setup with a keycloak authentication server and an application:

  1. user logs in on application client side, send un/pw to server
  2. application server sends un/pw to keycloak server for a token
  3. keycloak server sends a token back to application server
  4. application server outputs web page with sensitive data

I want to use RS256 to sign my tokens. When I try to get a token on the client side, they are correctly signed with RS256, but as soon as I try to get one on the server, HS256 is used. How can I set keycloak to use RS256 in both cases?

I use the /auth/realms/{REALM_NAME}/protocol/openid-connect/token endpoint and keycloak 10.0.1.

Keycloak configuration:

  • keys
    • realm keys are HS256, AES, and RS256 (listed in this order) all with a priority of 100 (EDIT: even if I set the RS256 key priority to a higher value, HS256 is used)
    • default signing algorithm for the realm is set to RS256
    • as a last try, - I made every other key passive in the realm. When signing a token, keycloak just generated a "fallback hs256" key to use instead of the active rs256.
  • client
    • access token signature algorithm and ID token signature algorithm for the client are set to RS256
    • the client is public
    • Valid redirect URIs contain the domain where the application server is currently running (which is localhost but my computer has a domain name)
    • Web origins is set to "+" (which as far as I'm aware copies entries from valid red. uris)

Google seems to return no results related to my problem. Restarting the keycloak server (after modifying any settings) also doesn't seem to bring any results.

5
  • I'm not familiar with Keycloak, but: is the generated token ever verified by anybody other than its issuer? I'm guessing not, because generating a "fallback HS256" key wouldn't even work then. However, your "problem" makes perfect sense if no other party needs to verify the token. Verifying asymmetric signatures (RS256) is expensive, and using RS256 only makes sense when you have verifiers that know the public key but not the private one (preventing them from making signatures). If the issuer and verifier are the same, symmetric (HS256) is faster, simpler, and at least as secure.
    – CBHacking
    Jun 23, 2020 at 8:58
  • @CBHacking Company requirement is that the keycloak server remains a standalone authentication server, so it can be used by any future application. Fro this reason the issuer and the verifier will always be different.
    – sisisisi
    Jun 23, 2020 at 9:19
  • I'm seeing similar behaviour on 8.0.1 too
    – declension
    Sep 7, 2020 at 16:47
  • Did you find a solution for your problem? We are facing the same issue...
    – Carl Bosch
    May 31, 2021 at 13:59
  • @CarlBosch Unfortunately not yet, we solved the issue by changing the architecture to avoid this bug. But if I find something, I'll add an answer and tag you.
    – sisisisi
    Sep 16, 2021 at 17:06

1 Answer 1

2

I don't know if it's the same in your case, but when I run into the same problem I realized that the token I was generating on the server had token category INTERNAL, in which case it is hardcoded to HS256 as you can see in the keycloak source code.

In my case the solution was to implement a custom token with different TokenCategory.

public class RoleAdminAccessToken extends DefaultActionToken {
    public final static String TOKEN_TYPE = "custom-token-type";

    public RoleAdminAccessToken(String userId, int absoluteExpirationInSecs, String compoundAuthenticationSessionId) {
        super(userId, TOKEN_TYPE, absoluteExpirationInSecs, null, compoundAuthenticationSessionId);
    }

    private RoleAdminAccessToken() {
        // Required to deserialize from JWT
        super();
    }

    @Override
    public TokenCategory getCategory() {
        return TokenCategory.ACCESS;
    }
}

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .