Repository navigation
Organise payload issuing and validation code #921
Description
Specification
Currently, the JWTs are strewn everywhere, wherever it is relevant. This is kind of going against the modular and obvious domain structure we are using. So, all the different kinds of tokens, like claims tokens or identity tokens should all be present in a unified domain. In this case, all the payloads and validation methods can sit inside a directory in the tokens domain.
This will let both PKE and PKCLI to use a unified interface for issuing and validating the token, removing a potential friction point and better organising the code.
Additional context
- Reference
src/claims/payloadsfor a gold standard on achieving this
Tasks
- Move logic for creating and validating a token to
src/tokens/payloadsor a similar directory - Reference
src/claims/payloadsfor a gold standard
Activity
linear commentedon Jul 9, 2025
ENG-642
CMCDragonkai commentedon Jul 9, 2025
How did JWTs get spread everywhere?
aryanjassal commentedon Jul 9, 2025
This was mostly prompted by a chat Brian and I had regarding centralising the signed auth token being used by the
polykey auth logincommand into a module which can assert, parse, and maybe issue the token. This will make it easy for the logic to be imported in other applications, say PKE, instead of each application needing to roll out their own versions of parsing and validation.Once we were thinking about this issue, we realised that there is another session token used by Polykey, so we can consolidate the parsing and validation all under an organised path, like
src/tokens/payloads. This is what this issue is addressing.tegefaulkes commentedon Jul 9, 2025
It's just consolidating. Before adding the token used to authenticate into PKE we only had the session token for the CLI sessions which had it's logic in the sessions domain and didn't define the token structure well. We're just tiding things up here.