On their Getting started guide, 
it answered with:
So then I tried inputting client credentials from RegistredClientRepository entry:
And it worked.
So my question is: what is the purpose of UserDetails and RegistredClient being both available in this case?
And another little bit off-topic question: if I create my own authorization server for client credentials flow between my servers, how does every server know that token belongs to legitimate server and not to some attacker who can just register with needed clientId if there's an opportunity? How can resource server actually verify that token owner is the server it trusts?
CodePudding user response：
Generally in oauth2, a "client" is an application which users might use to interface with some service - for example something like an App people can install on their phones or a web application.
Most oauth2 implementations have "scopes" (basically defined sets of access rights). Clients (client applications) are registered with some metadata (name, author, ...), a set of scopes they might use and some details to improve security - like "where is that application hosted" (in form of "which redirect URIs are valid"), client ID and client secret.
Depending on the oauth2 flow chosen, your App needs to prove being that app by some means - e.g. by having a valid combination of client ID and redirect URI or by doing HTTP basic auth with their client ID as username and client secret as password when exchanging a "code" for a "token".
All this was about clients - now about users: they are what you would expect, the users of a service - like you and me are users on Stackoverflow.com
And another little bit off-topic question: if I create my own authorization server for client credentials flow between my servers, how does every server know that token belongs to legitimate server and not to some attacker who can just register with needed clientId if there's an opportunity? How can resource server actually verify that token owner is the server it trusts?
for this you could either use a form of signed tokens (look at e.g. JWT) or store the currently valid tokens per user in a database reachable by all your servers - both have pro's and con's, tokens in a database are easier to revoke, while signed tokens don't require you to store any state in a database (which can be expensive in big distributed systems)
Update - OP actually wants to do server-to-server authentication, see comments below
Server-to-server authentication can often work very well without any extra authentication server, in cases where your parties a less dynamic - like when you always have "those three servers" and they don't come and go very often.
In such cases, using a simple token is probably better and easier than using an oauth2 stack. Each server could just have a list of randomly generated strings in its config file, let's call this "the set of valid tokens" and also knows which token to send when communicating with a specific other server. When a request comes in, the server checks if the given token is in its set of valid tokens - done.