The OAuth 2.0 spec defines several different use cases or workflows targeted to different kinds of applications or authorization scenarios.
One of the authorization workflows, and the one most commonly associated with Oauth, is when a client application requests access to a protected resource but does not obtain the end user's credentials directly - the access request redirects to present the end user with a login screen owned by the authorization system, not owned by the client application. When the user presents credentials and agrees to allow the client app's request for access, then the authorization server returns an authorization code to the client app and the client app can use that code to obtain an access token to access the end user's protected resources.
That's called the authorization code grant, and it's detailed in section 4.1 of the OAuth2 spec.
There is another authorization workflow in which the client app does have possession of user credentials or some other form of shared secret. The client application includes the user credentials or shared secret when requesting an access token. This is called a client credentials grant, and is detailed in section 4.4 of the Oauth2 spec.
The client credentials grant may be closest to your scenario.