There are multiple problems with what you are trying to do...
OAuth2 in the "traditional" way is not meant to be used on anything other than a webbrowser. This means that if you have a desktop application or a mobile application, you should not use "traditional" OAuth2 for authentication. By "traditional", I mean the one where you get redirected to the provider website to enter your username/password then redirected back with a token that will be used by the client and etc.
Now let's start the explanation... OAuth2 documentation can be a bit confusing at first. What they refer to as a client is what we usually refer to as server when we are developing web application. There is 3 part to OAuth2 :
- Service Provider : Google, Facebook, etc.
- Client (webserver, desktop application, mobile application communicating with the service provider)
- User (the application the physical user is using)
The problem with mobile and desktop application is that the client and the user is the same thing AND they reside on the client machine. Ever heard the saying "there is no security client side"? This pretty much apply here.
Problem 1 : The client secret
You are right to not want to put your client secret in the mobile app because your app can be "decompile" and hacker will retrieve your client secret. Once they have it, they can create their own application and impersonate your app.
Problem 2 : Username / Password
Don't use the "traditional" OAuth2 on a mobile/desktop application. The problem here is how you enter the username/password and how you retrieve the token that the service provider give the user after he logs in. Let's look at possible way to get it "working securely"...
Fail attempt 1 : Ask your user to enter username/password directly through your interface.
Reason for being bad : Congratulation, you just stole the facebook login of all your users.
Fail attempt 2 : Open a browser with the provider page.
Reason for being bad : How do you get the token back from the browser now? There is no way to get it (unless you have a malicious application constantly reading what is in the browser of the user)
Fail attempt 3 : Open a fake browser to lure the user to give you it's log in information.
Reason for being bad : Same at attempt #1. Mobile application can go full screen and control everything you see so you cannot trust them. Desktop application can open new window that could mimic your browser, etc.
The hard fact is that there is no way to make "traditional" OAuth2 work without a secure webbrowser that acts as the "user" and an https webserver that acts as the "client".
OAuth2 was never designed to provide authentication but rather just authorization. There is a big distinction between the two. OAuth2 protocol was "hacked" in order to make it able to provide authentication also (check OpenId). The only problem with this "hack" is that it only works in webbrowser like explained previously.
A real solution
If you still want to continue using OAuth2/OpenID for your login and wanna do it in a secure way, it will be a bit different than what you have imagined. Using OAuth2 for login is still a good idea as it saves your users the trouble of remembering yet another username/password.
You will need a server where your client id and secret will be stored. Your mobile app will connect to this server to send the token.
When ask for log in, redirect the user to the service provider webpage in a browser. Alternatively, the user could go directly to your https website to log in which will again redirect them. The service provider webpage is the only place your should enter your log in information.
Create an https webpage where the user will be able to see the token once he logs in using the service provider.
Ask the user to copy this token into your application. Your application then send the token to your server. The server add the client id and client secret and forward it to the service provider.
Your user can now use their "facebook" login to log into your application and there is no way for your application to steal their log in information or for an hacker to steal your client secret.
The case of phishing attacks and OAuth2 when used outside a web browser is an interesting one as well but that would be the subject of another question.