Web API: default authentication for programmatic requests

[01es]

Description

TG has a consistent and well proven authorisation subsystem, which in based on a uniform model of the RETSful Objects. This authorisation subsystem worked well for both Web UI and Web API. However, there is no default authentication model for Web API requests, making the TG-based application engineers responsible for provide one at the application level.

Article Best practices for REST API security: Authentication and authorization provides a very reasonable overview of the current approaches.

In TG-based applications, If a user making a requests, can be identified as an authentic user, the authorisation subsystem takes care of the rest. For programmatic Web API requests, the approach with using API keys for authenticating users, seems to be the most suitable, especially taking into account that the autorisation subsystem is already in place (e.g., there would be no clear benefit of using JWT tokens).

• [ ] Users, who have the right privileges, should be able to generate an API key for themselves. This means that if there is a separate user, created specifically for making Web API requests, someone would need to login into a TG-based app (and therefore authenticate with the configured method) and generate an API key.
• [ ] API keys should be stored in a hashed form. Because of this, users should store their just generated API key securely before saving it in the system after the generation – non-hashed key values are required to be provided with each request for authentication (see below).
• [ ] There should be at most 1 active key per user. This means, that generating a new API key would always invalidate an existing key.
• [ ] It should be possible to remove an API key.
• [ ] It would be beneficial to keep a history of all hashed API keys.
• [ ] User companion should be enhanced with method Optional<User> findUserByApiKey(final String user, final String nonHashedApiKey). The returned user should be suitable for IUserProvider. This method should hash the key before matching a corresponding active user.
• [ ] Web API requests should bare an API key as HTTP request header API-KEY in their non-hashed form, combined with a username as username:non-hashed-API-key.

Expected outcome

Easy to use and secure functionality to generating API keys, associated with individual users.