Hash crypto & JWT

Update JWT Claims by Issuing a New Token and Handling the Old One

Understand why editing a JWT invalidates its signature, how an issuer replaces claims, and what happens to previously issued tokens after a role change.

By Uddhav Gopani, FounderPublished 27 September 2026Updated 29 September 2026

Changing a claim changes the signed message

A signed JWT is not an editable server session record. Its signature or message authentication code protects the encoded header and payload. If a client changes a role, expiration or subject in the payload while keeping the old signature, a correct verifier rejects the altered signed content.

To update claims, the authorized issuer creates and signs a new token after checking current account state and the applicable grant. A browser decoder can display or re-encode JSON, but it cannot turn a requested role change into a permission the issuer has approved.

Compare two claim sets without treating them as credentials

{
  "sub": "example-user",
  "aud": "https://api.example.com/notes",
  "role": "reader",
  "iat": 2000000000,
  "exp": 2000000300
}

{
  "sub": "example-user",
  "aud": "https://api.example.com/notes",
  "role": "editor",
  "iat": 2000000120,
  "exp": 2000000420
}

These are fictional claim objects, not complete tokens. They illustrate a later issuance after an authorized role change. The later object needs its own signature and must be issued under the service's real policy. Copying it into a token editor does not establish that the user has become an editor.

The subject and audience remain consistent in this example because the identity and destination did not change. Do not rewrite those fields merely to make a token accepted by another service. A different audience or account can require a different authorization flow.

Take replacement claims from authoritative state

The issuer should obtain roles and permissions from the source of truth appropriate to the application. A client can request an operation, but should not be allowed to choose its own trusted role by submitting a JSON field. Validate the actor's authority to change the underlying account before issuing credentials reflecting that change.

A refresh flow also needs an intentional policy for current permissions. Blindly copying all claims from the old access token can preserve a role that has been removed. Conversely, adding every newly available privilege without the required authorization process can expand the grant beyond what the client was approved to use.

Decide what previously issued tokens can still do

Issuing a replacement token does not automatically erase every earlier token. A resource server that validates signatures and expiry locally may continue accepting an older, otherwise valid token until its lifetime ends. A role removal requiring immediate enforcement therefore needs more than simply returning a new token to one client.

Possible designs include checking current authorization state, using an appropriate revocation mechanism or accepting a deliberately bounded delay until short-lived credentials expire. Each design has availability, latency and storage implications. State the intended behavior rather than describing all JWT deployments as instantly revocable.

OAuth token revocation and token introspection define related protocol mechanisms. Their applicability depends on the authorization server and resource server. An endpoint cannot gain those behaviors solely by adding a jti claim to a token.

Replace the client state without hiding failures

Deliver the new credential through the established secure session flow and update the client state coherently. Avoid leaving one request queue using the old token while another reads the replacement from a different store. Concurrent tabs or processes need a coordination design appropriate to their architecture.

Never log both complete credentials to prove that they differ. Use synthetic fixtures in tests and approved diagnostic identifiers in operations. If a user signs out during an asynchronous replacement request, ensure that its late response cannot restore a session the interface has already cleared.

Test issuance, tampering and the old-token policy

Verify that a legitimately issued replacement validates under the intended key and profile. Alter the old payload without resigning and assert rejection. Then present the unmodified old token after a role removal and confirm the specific acceptance or revocation behavior the application promises.

The JWT Decoder is useful for comparing synthetic old and new claim objects. It does not establish either object's trust or perform the account change. Keep authorization tests at the issuer and resource-server boundaries, where the actual permission decision occurs.