[question] Adding to jwt claim

[acidtonic]

I'm using the library and it's working great. I'm using it for simple authentication and I have no issues there. However I am curious about adding more claims to an existing token.

I have a login facility, but I am looking into adding a second "environment" pivot and I don't want to tie the environment to the login of the user, but rather allow the user to add/remove claims to the token which effects their environment without logging in and out to change it.

So after I create the token for login, can I keep the existing token and simply append a new claim for environment and sign again? Or should I throw away the first token and give them a new one with everything added? Or should I keep it separate and return a different token for the environment claim and then deal with the user having to send more than one token which seems wrong?

I was looking for a way to add a claim to an existing token, is that possible? I believe the right answer is to just send a new token with all the claims but figured I'd ask if I am understanding this correctly.

Appreciate the work. Thanks

[prince-chrismc]

Your understanding matches mine :)

It's not possible to append claims after a token has been signed.

The signature includes both the header and payload, according to the RFCs... changing the payload would cause a discrepancy... that should result in the token being rejected.

[Thalhammer]

Chris is perfectly right that you can't modify a token without resigning it. I think its perfectly valid to have multiple tokens. That said I think you should verify if what you try to do makes sense. JWT's aren't really designed to be used as a replacement for server session data, they are designed for scenarios where you only have a static login info and otherwise have a stateless api design, or to share trust between different services (separate login & api). My question is: Is the environment name something that shouldn't be user changeable or is expensive to verify ?

If so you could consider it a second login and create a second token per environment, However I wouldn't replace the original token and instead create a second one that grants access for the specified user assuming it also presents a valid login token (I.e. one token proofs user permissions, the second environment permissions).

However if its easy to check if the passed env is valid for user x, why not pass env as a normal url param/header and verify it on each resource.
If the list of environments is somewhat tightly bound, why not enumerate them on login and put the list of valid options in the token (against you can then verify the env variable).

Both of the last options safe you the hassel of having to manage multiple tokens and/or changing tokens after login.