Persistent API keys

[gctucker]

At the moment, a user can login and get a JWT token. These tokens aren't stored in the database and have a baked-in expiry time. They're used for temporary sessions, typically by web browsers. This is fine and we'll definitely need this kind of tokens, but it's not designed to be used for automation tools that use the API continuously such as pipeline services.

In addition to the JWT, we should create another kind of tokens which we might call "API access keys". These would be stored in the database and could be revoked by the user. They may also have an expiry date and scopes to fine-tune the operations that can be performed with them. This is how most web APIs work, with persistent credentials for this kind of use-case. I don't think fastapi-users can support both, but it can support one or the other:

https://fastapi-users.github.io/fastapi-users/10.0/configuration/authentication/

In our particular case, I would like to suggest that we use the persistent API keys as a way to get a temporary JWT token. So a user can interactively login with a username / password interactive form or non-interactively by sending an access token. Then a short-lived JWT token is generated (say, valid for 1h) and when it expires a new one needs to be generated.

[gctucker]

On a side note, JWT have variable length depending on what they contain. They are self-contained, and as such can have some arbitrary data. Some systems such as LAVA can keep tokens for third-party services such as the API in this case, to handle callbacks, but there is a maximum length for storing such tokens. As a result, storing JWT in LAVA databases has proven to be challenging in the past (that's why the early access deployment has a very short user name kci among other things). So having a fixed-sized API access token format for this kind of use-cases will avoid such issues in the future.

[gctucker]

Based on the fastapi-users documentation, it seems the best approach would probably be to have multiple authentication backends available: JWT and "database" for API keys, and maybe cookies for the new web dashboard later on as well.