Is it a good praxis to secure an webservice endpoint with a simple token string?

I have a web application where the regular user login is handled via SSO.(This prevents me from creating a service user)

In this application I have some web service endpoints that are not in the scope of any user. They will be triggered by another application and do some stuff.

Is the following the right way to do.

1. A token string is created by hand(because of simplicity)
2. The token string is stored in the environment variables of the system that provides the webservice endpoint as well as in the system that calls those endpoints.
3. On every call a simple equality check is proceeded - if the token is not present, the endpoint returns a 401.

Is my approach to simple?

I have not found much on this topic - my approach comes from the moodle-webservice handling, where you generate a webservice token in moodle and place it aswell in the application that calls the webservice.

For a basic application with no high security requirements, this might be ok.

A few things you could do (all of which will increase complexity and/or cost):

• The service could store a proper password hash (like bcrypt, pbkdf2 or argon2) instead of the actual password. This would help, because if it is compromised, the actual key would not be lost, the attacker could still not easily call the service. (But it's already compromised, and this is not like a user password that would be reused, so it depends your choices and threat model.)
• You could store this secret in a proper vault like AWS Secrets Manager or Hashicorp Vault or similar. This would enable you to control access to the key in one place, and audit key usage (maybe alert on attempts and so on). Access to the vault would still have to be managed, but that's easy via roles on AWS for example, where instances with the right role can access the secret but others cannot.