I have a scenario where there is a standalone web API sitting on a server, and standalone web application sitting on another server.
The web API
The web API (ASP.NET Core WebAPI, but I think it's irrelevant right now) has user authentication implemented via the JWT Bearer token authentication scheme (a scheme provided by Microsoft's ASP.NET Core Identity). Basically a valid username + password grants you an access token and refresh token which are used in subsequent requests to protected endpoints. The web API's primary users are end users which register by themselves.
The web application
For business purposes this web application has to communicate via HTTP with the web API's protected endpoints, but this communication must take place strictly on the back channel without user interaction, which means that authentication of the requests from the web application must also take place without user interaction.
Perceived issue
A the web API's authentication mechanism is already implemented with only end users in mind, there is currently no mechanism to support service-to-service authentication. Is it wrong to automatically create a user account for the web application (and maybe flag it as a service account to skip validation of some of the user attributes)?
P.S The web API and web application do not have a shared user base and business-wise would not ever have one. Also, I am aware of OAuth2 and OpenID frameworks like IdentityServer, which support different flows for authenticating, but currently switching the authentication mechanism is not ideal.