With 2.0 we have minimal suport for json web tokens. They allow login
as a user and a restricted permissions set based on the role embedded
in the JWT.

This ticket can be used as a grab bag of ideas that others may want to
tackle if JWT's are deemed more useful.

JWT can have own rate limit
===========================

Currently rate limiting in the rest interface is done based on the
user/subject. Consider adding a separate rate limit in the body of the
JWT. This restricts the amount of resources usable by the JWT which
may be lower than that allowed for the user. The user's level needs to
be able to support say an AJAX web interface to roundup which may
need many more hits than the JWT token needs to do its work.

More ideas can be added to this ticket and migrated to separate
tickets as they get implemented.

Consider including array of ip's (or cdir network spec) in token.
Token can only be used if sent from an ip in the list.

X-Forwarded-For is available from roundup-server, so it may be
possible to get the real source ip in other deployment modes.

issue2551177 suggests looking at macaroons for some of the JWT use cases
above. E.G. An existing macaroon could be modified by a user to create
a token that restricted a token with read write access to all
issues the user has accessible from anywhere at any time to a token that:

  allowed read only access
  to one issue
  for the next 6 hours
  from a specific subnet or set of addresses

Also consider how we rotate keys.

see: https://itsdangerous.palletsprojects.com/en/2.0.x/concepts/#key-rotation

for key rotation ideas.

May need to have multiple keys live at the same time and  way to add/remove them.

would a jwt make a good base for password less login with a magic link/url?

Consider a jwt with a 2 minute lifetime appended to a url like:

  https://trackerorg/demo?@template=new_session&@action=new_session&session=<jwt>

the jwt has a scope/role of new_session that when browsed to results
in a new session cookies for the user.

Magic link might be better setup using a session token that can be revoked rather than
the time limited jwt but something to consider.

See also: https://fly.io/blog/api-tokens-a-tedious-survey/

and for server to server:

  https://web.archive.org/web/20200507173734/https://latacora.micro.blog/a-childs-garden/

Force long lived JWT access tokens that are not expected to be used
often/quickly to check to revocation like a refresh token.

For example consider a third party time tracking application with a JWT. It hits the
REST/web interface when the user changes tasks. Compare to a WT used by an alternate
front end written in react where all the data (20/30 or more requests/sec) for a
page is obtained via the REST interface.

For the third party infrequent use case, consider adding something to the JWT to trigger
checking to see if the JWT has been revoked.

This does destroy the statelessness of the JWT. However it shouldn't be any worse
than the stateful checks done with a refresh JWT.

A refresh JWT should be identifiable by the payload: either a role: (e.g. jwt:refresh)
or a refresh claim. All Refresh JWT's should be checked for revocation.
Using a claim to identify the refresh token might be better than a role. With the claim,
could the role be used as a template to simplify generation of the new JWT access token?
I.E. The only difference between the access token and the refresh token is the refresh claim.
So minting a new access token is copying the Refresh token, removing the refresh claim
and resetting the iat (issue time/not valid before) and exp (expiration time) claims.

Key rotation as mentioned in msg7415 is implemented by changeset:   7809:be6cb2e0d471

jwt_secret takes multiple comma separated values. First (left most) should be used
to sign. All secrets are used to validate the JWT. If left most is < 32 characters
JWTs are disabled. If any secret except the first is < 32 characters Roundup will
exit to prevent too short/insecure secrets from being used.

There is no way to revoke a JWT. However Roundup raises a LoginError if a JWT with an
invalid role is specified.

Could you define per user roles:

  email_read:user21
  email_read:user22

and change the schema to remove those roles and restart Roundup to invalidate
a JWT? So if user22's JWT using email_read:user22 is exposed, change the role to:
email_read:user22_1 and restart roundup. The old JWT will raise a LoginError.
Now every JWT with that role will be obsolete. But the scope of JWT is limited
to that user's JWT.

This does lead to a proliferation of roles and I am not sure what the implications
of that are.

Should we add an ID to a jwt via its data element or the 'jti' registered claim?

This allows logging/audit of use of the JWT. Logging the ID
when a JWT is used via python logging or in some table in Roundup
should be added as well.

Th native audit logs/journal records the userid. It assumes that the user is
logged in. Do we need some way to audit a change by a user when done by a service
(which is likely to have a JWT for authentication)? So a change done by user X
is logged differently than a change done on behalf of user X by some
program/agent/... with a JWT?

The tx_Source database connection property doesn't include an authentication
method for any mechanism except email (where pgp auth is identified). But
this property might be a good place to store authentication method/agent ID (JWT ID)
for use in logging.