Add command line tool to generate JWT for use by bots

[stefandesu]

Edit: Creating a command line tool to generate JWTs should be enough for now.

Previous title:

Idea: Add support for multiple authentication schemes at the same time

If we have bots creating annotations to mark certain mappings, we possibly need other ways to authenticate besides JWT/login-server. Ideally, that bot just uses a persistent token to authenticate. I was also thinking that we could possibly allow users to create/remove their own auth tokens for applications like that, although that's something we probably won't need for a while.

Internally, jskos-server could keep a table mapping auth tokens to user objects.

[nichtich]

I don't fully see the need for many multiple authentication schemes but auth tokens make sense for the bot account. But we don't need a users to create auth tokens, in lack of a use case. These tokens can be managed via command line as well. The bot is running locally on the same machine as jskos-server anyway.

[stefandesu]

Okay, my suggestion: Add a command line script to create a valid JWT that can be used for authentication. That way, we don't need to change anything in the code because JWTs are already fully supported.

If we need more than that, we can add it later.

[nichtich]

This could support a command line client to access JSKOS API with commands such as

jskos-api voc                                           # list all vocabularies
jskos-api data uri=http://dewey.info/class/612.112/e23/ # get item
jskos-api add $ITEM                                     # entity type guessed from `type` 
jskos-api edit $ITEM                                    # entity URI in `uri`
jskos-api delete $ITEM
...

The API endpoint and JWT token are read from a config file ./jskos-api.json:

{
  "api": "http://bartoc.org/api/",
  "token": "...."
}

[nichtich]

Current workaround requires command line import on the server:

1. export items
2. modify items
3. import items (if something has been modified)

A bot is a just a script that does this on a regular schedule. The current workflow may be not optimal because step 1&2 and step 3 are executed on different machines (local vs server).