The Scenario: A web-app user wants to create an authorised view of a private asset. The user has authenticated and has a jwt token. The app wants to make a fresh secondary jwt token, which can be verified as having been created with the original token.
FYI: My use case is signing a url – adding the second jwt token to the url, to allow controlled public viewing of the private asset.
How should the app do that?
E.g. is there a recommended way to set secret and alg for this 2nd token?
Advertisement
Answer
In theory, to use one jwt to sign another, you’d use the HS256 algorithm, with the first jwt as the secret. In practice, this approach leads to a couple of issues, outlined below:
Firstly, only the server and the original token-holder will be able to verify the authenticity of this token, and in order for the server to perform verification, you’ll need to persist the original token somewhere. This is outside the scope of your question, but it does begin to complicate the implementation, since now both tokens mush share a lifespan, and the original token needs to be available wherever the second token might be used. That might not be an issue for your use case but it does somewhat limit portability, as well as future-proofing if, for example, another party needed to verify the token (such a use case can be achieved without too much overhead by using RS256 and asymmetric keys instead of the HS256/symmetric key method).
Secondly, JWTs are commonly transient values with short lifespan. This is usually due to the nature of their use: since they are shared between a client and server, they are not strictly speaking “secret” values, and the longer they live, the greater the chance that they may have been compromised. In using them as secret material for other tokens, you now require a longer lifespan for those tokens, and you are potentially introducing a security vulnerability wherein the “secondary” tokens could be spoofed by an attacker who gets their hands on one of these “primary” tokens. In order mitigate this specific threat, secret material should be something that is not transmitted over the network.
Perhaps you might consider using the same token generation procedure (same algorithm & secret) for both tokens, and simply include an identifier for the “issuer” (a unique identifier for the user who holds the original token) as part of the second token. Using this method, you don’t need to worry about which verification process to use for a given token (since it’s now the same for both), nor do you have to worry about token lifespan or key spoofing through a stolen token.