QA (public) » openQA Project (public)

For authentication method, I suggest JWT (https://en.wikipedia.org/wiki/JSON_Web_Token) (https://jwt.io/)
Once you have authenticated you receive a token that will be used in next calls to the API
Is an standard (https://tools.ietf.org/html/rfc7519)
And exist perl libraries
cpanm Crypt::JWT

I'd also like to put the idea of personal access tokens into the room. Similar to how GitHub handles the problem. Those are pre-negotiated keys stored with the user profile that do not expire on their own. They are created and deleted by the users themselves in the ui. And then used like curl -u username:token https://api.github.com/....

For temporary expiring tokens i do like the idea of using JWT (Mojo::JWT is another option there). Perhaps as a starting point we could have a new operators menu entry for access tokens. And on that page only give out one temporary JWT token that expires after 48 hours. But that in the meantime could be used for curl -u username:jwttoken ... access. Every time you refresh the page you would get a new JWT token. If we later decide we want real persistent personal access tokens that could easily be added using the same infrastructure. Workflow for the user would stay pretty much the same.

Btw. One downside of JWT is that they can get a bit long.

curl -u kraih:eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2MTE4NDMzNDcsInVzZXIiOiJrcmFpaCJ9.uKb_e-Fe_fN0COVMcK3zawP00gALO6YeEswCibMree0 /api/...

This one only contains my nick and an expiration time.

What do you see as benefit for temporary expiring tokens? And what is the difference for user access tokens vs. apisecrets? They are also already created by users themselves

kraih wrote:

okurz wrote:

What do you see as benefit for temporary expiring tokens?

The requirements for the user workflow are currently very vague. Temporary expiring tokens give us the most freedom to figure out what exactly users want and modify the system based on feedback. Access control levels could be added/changed without the need for database migrations.

We should not be scared of database migrations. Not that we should necessarily design that we would always need database migrations to introduce more fine grained details for access control levels but to introduce the concept of a more fine grained control in general. Currently I see any access control levels going further than the current "unauthenticated/user/operator/admin" levels out of scope for the work to be planned here.

okurz wrote:

And what is the difference for user access tokens vs. apisecrets? They are also already created by users themselves

Good point. It really depends on what workflow we end up with. Reusing "$user:$key$secret" as access token could be enough if we are sure that level of access control is all we need. And would be the easiest solution for me to implement.

Yes, that is all that we currently need.

Here's a few question that need to be answered first though:

• Should access tokens always have the same level of access as the user that created them? GitHub has fine grained access levels to mitigate security risks (i've attached a screenshot as example).

I can see the screenshot. And I think github is a nice example but I do not see that we need that as openQA is not a "single closed-source service" but a server that we market to be installable by users even for single-person instances as well as have multi-user instances but with the limit of not needing more fine grained access levels. So in short: For now, yes, access tokens should always have the same level of access as the user that created them

• What additional information would we need to keep for API keys? At the very least a comment field to remember what automated service an API key has been created for comes to mind.

yes, an optional comment sounds good.

• How much flexibility do we need for future changes to the personal access token system? Changes to the key+secret system have a risk of interfering with micro service IPC and other existing OpenQA::Client uses. Which are much more important than user automation scripts.

I agree but I am confident that in the case we even would need such change we can get along with a migration and stringent inter-dependency of services key+secret API version.

• How much do we trust our users to not use one pair of key+secret for absolutely everything and ignore security risks completely? Do we care?

I am sure that the majority of users will use one pair for everything and some of them will leak the details in the web :D But we should not care.

• Is there no chance at all we might need a token access level below operator in he future? Perhaps for certain read-only endpoints?

Well, certainly there is a chance but what would that interfer with now? And another point: Right now an authenticated user can actually not do that much so from my experience existing users ask soon to become "operator", meaning that should give us some leeway to give "user" more permissions when we see good, limited new use cases for that.