[Feature Request]: Support JWT Auth Token Revocation

[jcstein]

Implementation ideas

Summary

There is currently no way to invalidate a previously issued JWT auth token for a DA node. Once a token is created via celestia <node_type> auth <permission>, it remains valid indefinitely with no mechanism to revoke it. Node operators should be able to revoke tokens that are no longer needed, potentially compromised, or were issued in error.

Motivation

This came up while onboarding an integration, who had questions about the auth model. The current behavior — where issued JWTs are permanently valid with no revocation path — is a security concern and goes against standard auth best practices. Telling integrators "once you create a JWT it's valid forever, good luck" is not a great story, and it's not something that can be papered over with documentation.

Concrete scenarios where revocation matters:

• Credential rotation: An operator wants to cycle tokens periodically as a security hygiene practice
• Compromised tokens: A token is accidentally leaked (e.g. committed to a repo, shared in logs) and needs to be killed immediately
• Access downgrade: An admin-level token was issued but the consumer should have only had read access — there's no way to pull it back
• Team offboarding: A team member or integration partner no longer needs access to the node's RPC

Current Behavior

1. Operator generates a token: celestia light auth admin --p2p.network <network>
2. Token is signed with the node's key and returned
3. Token is valid forever (or until the signing key itself is changed, which is a nuclear option that invalidates all tokens)

There is no revoke, invalidate, or delete command. There is no token denylist. The only workaround is to regenerate the node's signing key entirely, which breaks all existing tokens — not granular and very disruptive.

Proposed Behavior

Add the ability to revoke individual JWT tokens. Possible approaches (not mutually exclusive):

1. Token denylist/blocklist: Maintain a persistent list of revoked token IDs (jti claims) in the node store. The auth middleware checks incoming tokens against this list before granting access. A new CLI command like celestia <node_type> auth revoke <token_or_jti> would add entries.

2. Token listing + revocation: Add celestia <node_type> auth list to show active/issued tokens (or at least their jti and permission level), and celestia <node_type> auth revoke <jti> to invalidate a specific one.

3. Short-lived tokens + refresh: Issue tokens with shorter expiration windows and provide a refresh mechanism. This limits the blast radius of a leaked token without requiring explicit revocation. (Note: v0.20.4 added nonce and expiration time via fix: jwt token nonce and expiration time #3967, which is a step in this direction. celestia light auth admin --p2p.network mocha --ttl 100s)

4. Signing key rotation per-permission-level: Allow rotating the signing key for a specific permission level (e.g. just admin) without invalidating read/write tokens.

Additional Context

• The v0.20.4 release included a fix for JWT token nonce and expiration time (fix: jwt token nonce and expiration time #3967), which is related but doesn't solve the revocation problem for already-issued long-lived tokens.
• This is a real pain point for integration partners trying to build on Celestia's DA layer. A clear token lifecycle (create → use → revoke) is table stakes for any auth system they'd be evaluating.

Labels

enhancement, auth