Phoenix.Token max_age vs Guardian JWT for expiring, least-privilege credentials

Credential Expiry and Scoping

A design requirement for a Phoenix API involves issuing credentials that adhere to least-privilege principles (e.g., separating api:read and api:write scopes) and expire automatically to limit the window of exposure.

Two documented paths exist. Phoenix.Token allows signing a payload and verifying it with a :max_age option, providing native expiry without external dependencies. Alternatively, Guardian provides JWTs with standard exp claims and custom scope support, offering interoperability with third-party services at the cost of an additional library.

The Revocation Trade-off

A critical uncertainty remains regarding token revocation. Stateless Phoenix.Token and Guardian JWTs cannot be invalidated before their expiration date. While Guardian.DB enables server-side tracking for immediate revocation of compromised credentials, it introduces a database lookup for every authenticated request.

Assuming recent versions of Phoenix and Guardian, the decision rests on whether the performance cost of stateful tracking outweighs the security risk of a stateless revocation gap.

• Is Phoenix.Token with a short, explicit max_age sufficient for least-privilege needs, or does Guardian's JWT structure provide a significant advantage?
• Is the revocation gap of stateless tokens acceptable if lifetimes are kept very short, or is Guardian.DB the necessary choice for high-security environments?