API keys tied to computational service life cycle

[GitHK]

Is there an existing issue for this?

• I have searched the existing issues

User Story

As an oSparc service developer, I want to run a computational service that can interact with the oSparc API. This requires an API key.

I don't want to manually generate API, since the final users of these services, do not know anything about API keys.

Proposed solutions

The obvious one

Computational services should have the to generate and API keys and make them available for the users.

Cons:

• we can easily generate millions of API keys this way
• work from the computational backend development needs to be redirected in this direction (for now we cannot spare it)
• we might want to limit these to 1 per user

Pro:

• solves the issue for the service owner without additional work

The hacky one

Using osparc vendor and secrets create a shared api key for a service. This will work similar like the licensing works. We have one API key for a service and everybody who uses it has access to it.

Cons:

• one user for the key and all projects generated end up under the same user
• requires more setup
• harder to filter which user created which job. This is currently a no go for the first application of this feature

Pros:

• solves the issue for the service owner without additional work
• we can already support this without extra development

A less obvious one

API server generates temporary API keys. You would use an API key (for example the one that is automatically added to a dynamic service) to create a temporary API (it always has an expires)

One temporary API key can be created an passed to a computational service, before starting it.

Cons:

• service owner decides the duration of the API key based on the expected execution time of the service
• we extend the API server for this purpose. I'm not sure about abuse opportunities here
  Pros:
• half way between the ideal and hacky solution