server-to-server REST API security

Doesn't matter - from browser or not.

Is it neccessary to:

Create some changing key, e.g. md5(timestamp + token) that is formed for the request and validated at the endpoint?

Use oauth (2-legged authorization)?

Use OAuth, it solves both these questions. And OAuth usage is good because:

• You aren't reinventing wheel

• There are already a lot of libraries and approaches depending on technology stack

You can also use JWT token to pass some security context with custom claims from service to service.

Also as reference you can look how different providers solve the problem. For example Azure Active Directory has on behalf flow for this purpose https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-oauth2-on-behalf-of-flow

Use of OAuth2/OpenID Connect is not mandatory between your services, there are other protocols and alternatives and even custom. All depends in which relationships are services and either they both are in full trust environment.

You can use anything you like but main idea not to share sensitive information between services like service account credentials or user credentials.

If REST API security is main requirement - OAuth2/OpenID Connect is maybe the best choice, if you need just secure (in a sense of authentication) calls in full trust environment in a simplest way - Kerberos, if you need encrypted custom tunnel between them for data in transit encryption - other options like VPN. It does not make sense to implement somthing custom because if you have Service A and Service B, and would like to make sure call between them is authenticated, then to avoid coupling and sharing senstive information you will always need some central service C as Identity provider. So if you think from tis pov, OAuth2/OIDC is not overkill