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/