feat: create new JWT tokens and invalidate older for multitenancy

[TimoGlastra]

Tokens will now include an iat value which is also stored in the wallet record. If the iat of the JWT doesn't match the user won't be authorized. This means when a new token is created (using the multitenant apis) the old token becomes invalid.

Looking for some input if this is a desired approach. It is a breaking change as previously you would always get the same token, while now you always get a new token revoking the older tokens.

[codecov-commenter]

Codecov Report

Merging #1725 (9d103a9) into main (186c3f4) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main    #1725   +/-   ##
=======================================
  Coverage   95.26%   95.26%           
=======================================
  Files         528      528           
  Lines       33109    33118    +9     
=======================================
+ Hits        31541    31550    +9     
  Misses       1568     1568           

[MonolithicMonk]

I love the iat approach due to its ability to communicate a token's state at creation. This obviously gives the end user the flexibility to manage the token based on a deterministic variable.

However this deterministic quality is lost due to the inability to retrieve current token.

A more optimal solution will be to use the stored iat value inside the wallet record as a trigger to generate a new token. This way a user can retrieve a iat record within a wallet then use their own logic to determine if it should be updated or not. The updated wallet iat should then generate the new token

[TimoGlastra]

Thanks for the feedback @MonolithicMonk!

How would that exactly work with updating the iat value inside the wallet record? Through the update endpoint? One problem I see with this approach is that the iat doesn't actually reflect any issued token. So I can change the iat value (thus revoking the existing token).

However if we start rotating e.g. the JWT Secret based on the iat (e.g. everything above iat 94000 use the new key) allowing the user to provide this value could lead to issues.

[MonolithicMonk]

Thanks for the feedback @MonolithicMonk!

How would that exactly work with updating the iat value inside the wallet record? Through the update endpoint? One problem I see with this approach is that the iat doesn't actually reflect any issued token. So I can change the iat value (thus revoking the existing token).

However if we start rotating e.g. the JWT Secret based on the iat (e.g. everything above iat 94000 use the new key) allowing the user to provide this value could lead to issues.

I see your general point regarding iat being arbitrary. One way to pin down a concrete revocation / rotation time table is to include the exp property with a default value or a user defined value.

So a developer can a write script that retrieves all wallet records where exp > iat and update the iat record with now() and a new exp which should create a trigger the token creation mechanism you just wrote

[MonolithicMonk]

And yes this update should occur using the current update endpoint. Although the iat in the record doesn't reflect a token, updating its value should be trigger to generate a new token

[ianco]

I think this is a good approach. Regarding it being a breaking change - this just means that any existing tokens will be invalid and the tenant will need to request a new token, right?

[TimoGlastra]

Regarding it being a breaking change - this just means that any existing tokens will be invalid and the tenant will need to request a new token, right?

No, existing tokens will still be valid until a new token is created (we could easily swap it to invalidate all existing tokens). The breaking change in mostly in behaviour. Previously whenever you called the get token endpoint you would get the same token. Now it will always be a new token, invalidating the old token.

[ianco]

Regarding it being a breaking change - this just means that any existing tokens will be invalid and the tenant will need to request a new token, right?

No existing tokens will still be valid until a new token is created (we could easily swap it to invalidate all existing tokens). The breaking change in mostly in behaviour. Previously whenever you called the get token endpoint you would get the same token. Now it will always be a new token, invalidating the old token.

That sounds fine to me.

[TimoGlastra]

Ok. added a short note to the docs that creating a new token will invalidate the old token.

[swcurran]

Based on previous reviews from @andrewwhitehead and @ianco , and conversation with @MonolithicMonk . Most recent commit was a minor doc update.

[pstuermlinger]

Thank you all who worked on this feature! I'm impressed how fast you implemented a solution after the topic came up on Discord.