Description of the limitation and why it is relevant to address
As a developer integrating with the VIKTOR platform, I am currently facing challenges in accessing the platform’s API due to the lack of support for obtaining a bearer token via Single Sign-On (SSO) or alternative authentication methods. This limitation hinders the seamless integration of VIKTOR’s comprehensive tools, as outlined in your documentation (Introduction | VIKTOR Documentation), into our development workflow.
Addressing this limitation is crucial as it would significantly enhance the developer experience by facilitating easier access to the API, thereby unlocking the full potential of VIKTOR’s offerings. This improvement would not only benefit developers by streamlining their workflows but also add value to the end-users by enabling the creation of more robust and integrated solutions on the VIKTOR platform.
Submitter proposed design (optional)
(I heard this is already considered) Implementing a dual authentication mechanism that supports both SSO and traditional username/password login. This approach would provide flexibility in how developers can authenticate and obtain a bearer token, catering to a wider range of use cases and integration scenarios.
Introducing a feature to dynamically generate bearer tokens through a dedicated API endpoint or within the VIKTOR platform’s user interface. This solution would allow developers to programmatically obtain tokens as needed, enhancing automation and efficiency in their development processes.
Current workarounds
Currently, the only workaround involves using developer tools to inspect web requests and manually extract the bearer token. However, this method is not only cumbersome but also unreliable due to the short lifespan of the tokens obtained in this manner. Implementing a more streamlined and official method for token generation would greatly improve usability.
Hi @kassi, thanks for this elaborate feature request. We are currently looking into this feature. Would you be willing to have a little call on this to properly understand your usecase?
Hi @matthijs, yes of course. I would be more than happy to have a little call on this. I’ll send you a message with my email and availabilities. Thanks
For others checking this out, @kassi and I have talked about 2 potential usecases, that can probably be solved without using the external API (and thus already possible in an SSO environment). Sharing here to make sure others can also learn from this:
a parametrization update necessitates a mapping/migration of params for all existing entities.
You can do this in the app with a SetParamsButton to do it for a single entity (good for first check). You do need to save afterwards
You can do this in the app using the api_v1 module if you directly want to change it for all entities.
Generate an overview report of all entities in an app for users to see/download
This can be done in the app itself using the api_v1 module
The important difference between the above usecases and needing tokens is that for the above usecases you can stay within the workspace itself. Using the api_v1 module you have access to all the data in the workspace, without the need of extra authentication (it uses the permissions of the users triggering the job). More info about this is in the docs
There is another usecase that does not currently have a workaround for SSO and could be solved with API tokens:
creating a dashboard for analysis of most used input sets.
This can be solved by creating a separate app + workspace. In this workspace you don’t automatically have access to the other workspace, so using the external API would be an option for this (although we are also thinking about fixing this in a more elegant way)