New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JWT 2.0 #14508

wezell opened this Issue May 29, 2018 · 1 comment


None yet
2 participants

wezell commented May 29, 2018

A number of improvements to our jwt impl

@wezell wezell added the Epic label May 29, 2018

@jgambarios jgambarios added this to the Cody Current milestone May 29, 2018

@wezell wezell closed this Jul 17, 2018


This comment has been minimized.


jgambarios commented Jul 25, 2018

5.x changes

1. Creation of the secret

  1. If the property json.web.token.hash.signing.key is used and does not have the default value we use the value in that property in order to create a file with the secret we will use to sign the token.
  2. If the property json.web.token.hash.signing.key is not set or have the default value we search in the assets folder a file with the secret. The location of the file is: assets_folder/server/jwt_secret.dat
  3. If the property json.web.token.hash.signing.key is not set or have the default value and there is no assets_folder/server/jwt_secret.dat file meaning there is not a secret provided by the client, in that case we generate one assets_folder/server/jwt_secret.dat.

Basically if using the default configuration for the JWT secret dotCMS will autogenerate one for the client, or if the client want it can provide one, using the json.web.token.hash.signing.key or the jwt_secret.dat file.

2. Issuer validation

Another change for the JWT in 5.x is that we are validating the issuer of the token, where the issuer is the cluster id, that means you can not share a token between different installations of dotCMS, the token can be only used in nodes of the same cluster where the token was generated.

Recommendations for the secret creation if the user want to provide one (From Chris)

FWIW, the JWT RFC 7518 specifies that the secret keys should be the same size or larger than the hash output (>256 bits for SHA 256)

There is a significant brute force vulnerability if you use a secret key that is too small
512 bits for secret key recommended (64 bytes)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment