Janus currently expires tokens after 24 hours. This is required because the token, once issued, cannot be invalidated except by a recycling of secrets (that is, the Janus public key) across all Etna applications.
However, in many instances, mostly long-lived jobs that might take several days to execute, the short-lived token is a nuisance. There are several ways to avoid this nuisance, mostly the /refresh_token and /generate endpoints, which either let you keep a current token alive before it expires, or sign for a new token using a registered public key. Both of these methods involve contacting Janus to serially update the token.
In these instances we'd probably prefer a single, long-lived token that works the same as the regular Janus token, but doesn't require constant refreshing. However, as noted above, we want to be able to invalidate the long-lived token somehow.
To implement, we add a /long_token endpoint that allows the issuing of long-lived tokens. This token is modified in a few ways:
- Only one project/role is allowed in its payload.
- It has a
verify: true bit in its payload.
- The expiration is some suitably long period, perhaps 60 days.
The usage is identical; Etna::Auth, in the process of verifying the token (i.e., for each transaction to any Etna app with this token), notes the presence of verify: true and phones Janus at /validate_token, which confirms that the credentials in the token are still valid according to Janus's db. Etna::Auth then rejects or approves on the basis of this received confirmation.
Janus currently expires tokens after 24 hours. This is required because the token, once issued, cannot be invalidated except by a recycling of secrets (that is, the Janus public key) across all Etna applications.
However, in many instances, mostly long-lived jobs that might take several days to execute, the short-lived token is a nuisance. There are several ways to avoid this nuisance, mostly the /refresh_token and /generate endpoints, which either let you keep a current token alive before it expires, or sign for a new token using a registered public key. Both of these methods involve contacting Janus to serially update the token.
In these instances we'd probably prefer a single, long-lived token that works the same as the regular Janus token, but doesn't require constant refreshing. However, as noted above, we want to be able to invalidate the long-lived token somehow.
To implement, we add a /long_token endpoint that allows the issuing of long-lived tokens. This token is modified in a few ways:
verify: truebit in its payload.The usage is identical; Etna::Auth, in the process of verifying the token (i.e., for each transaction to any Etna app with this token), notes the presence of
verify: trueand phones Janus at /validate_token, which confirms that the credentials in the token are still valid according to Janus's db. Etna::Auth then rejects or approves on the basis of this received confirmation.