Allow usage of API-endpoint with API-key

[zcrt]

Is your feature request related to a problem? Please describe. Currently a CRUD-endpoint is available for organisations (and tags). However, to use the endpoint a full KAT account is required. As this endpoint is mostly useful for automated systems that do not need any other rights it would be nice to authenticate using an API-key

Describe the solution you'd like Authentication on the organization-endpoint with a configurable API-key

[underdarknl]

related / duplicate of https://github.com/minvws/nl-kat-coordination/issues/484 We will pick this up in Januari

[dekkers]

Functional Design

• Tokens should be linked to a user account
• It should be possible to have multiple tokens per user
• It should be possible to add an expiration date to a token
• Tokens should be stored hashed in the database

Technical Design

Using an existing library is preferred, because for security sensitive code such as validation of tokens it would be better to use software that also other people use and have looked at.

Django REST Framework has token authentication, but it has some limitations. There can only be a single token for a user account, it stores the tokens without hashing in the database and doesn't support expiration.

https://github.com/jazzband/django-rest-knox provides a better token implementation for Django REST Framework. It seems to be used by a lot of people. The only downside is at the moment is that the author transferred the project to jazzband but did not transfer the PyPI package yet so no new releases can be created. While it would be suboptimal, if necessary we could use git repo instead of the PyPI package to get the fixes and improvements done since the last release.

DRF uses a different authentication system that is not the same as the built-in Django authentication. We can still use it in normal views (such as the report download view) by creating a class or mixin that calls the DRF authentication mechanism or by inheriting from APIView.

I want to look into whether it is easy to inherit from APIView and still render the normal html view. If that's possible I think that might be the better solution, else we should implement calling the authentication mechanism directly. Another option would be to create a proper REST API using DRF for the reports (which would include OpenAPI schema, auto generated documentation, etc.), but that would be more work for which we don't have time currently.