Currently, we rely on a simple server-side secret to sign JWT tokens. Some tokens are for anti-DOS purposes and do not contain any relevant authorization data, while others serve as access keys linked to a subject identifier associated with a set of capabilities (or allowances).
Improvements
Users can issue access and anti-DOS tokens from the UI and via API. The tokens will support JWT expiration. For access tokens with long expiration periods, a revocation logic may be needed (i.e., server-side state to check if the token is active).
For the anti-DOS tokens, an endpoint protected by the access token will issue them with a short expiration period.
The server could use JWKS to publish public key sets for signing, allowing public verification of the signer and key rotation.
Currently, we rely on a simple server-side secret to sign JWT tokens. Some tokens are for anti-DOS purposes and do not contain any relevant authorization data, while others serve as access keys linked to a subject identifier associated with a set of capabilities (or allowances).
Improvements
Users can issue access and anti-DOS tokens from the UI and via API. The tokens will support JWT expiration. For access tokens with long expiration periods, a revocation logic may be needed (i.e., server-side state to check if the token is active).
For the anti-DOS tokens, an endpoint protected by the access token will issue them with a short expiration period.
The server could use JWKS to publish public key sets for signing, allowing public verification of the signer and key rotation.
Related #71 #103