I agree that (some subset of) people will not like that extra authentication screen, because from their perspective it serves no purpose at all.
This is not a third party authentication server, we will be in control of it.
Then there is no point in disguising what is actually a first-party authentication process as a third-party OAuth scheme; all that accomplishes is interposing an unnecessary extra form for the user to click through before completing their login.
There are different types of OAuth workflow; you're trying to use the wrong one for your particular circumstances.
The workflow you're using (the "Authorization Code" grant type) is meant to allow the user to take an existing authentication token from site Foo, and use it on site Bar. The extra "authorization" page serves to prevent phishing attacks by notifying the user that the authorization (though not the password itself) is being shared from Foo to Bar, so they can confirm that Bar is in fact who they wanted it shared with.
In your case, Foo and Bar are the same site. The user wants to log into your site, you're routing them through an OAuth scheme in which their only meaningful option is to confirm that when they typed their login information into your site they intended to actually log into your site. Which is, you know, silly.
For this circumstance what you want is the "Password Credentials" OAuth grant type. In this workflow the extra confirmation step is unnecessary, because there is no third party to share the authorization with. The user interface is familiar: they're on your site, they enter their username and password, they're logged in. The user doesn't need to be aware that the underlying authentication scheme is OAuth-based.
(Anecdotally: a substantial percentage of users still don't quite understand OAuth; in every site I've worked on that uses it, it's been a persistent low-grade source of user confusion. Common, recognizable authentication providers ("Log in using Facebook" or "Log in using Twitter") seem to cause less confusion -- enough users will have encountered that on other sites that they'll understand what it means on yours. Smaller, more obscure providers tend to be much more problematic (expect support tickets along the lines of "Hey, I was trying to log into your site but somehow wound up on something called Cloud Foundry! I think you've been hacked!!")
(The larger providers are also much more convenient in practical terms for the end user: most will have a Facebook or Twitter login token in place and ready to use; that will not be the case for Cloud Foundry.)