We've got an app, which should use authentification through 3-rd party OAuth 2.0 server, which acts as an authorization server.
As i understand there are two possibilities.
The "right" one is:
- Mobile app stores client_id
- Mobile app starts with GET /auth to receive authorization_code
- Authorization server returns response with redirect to redirect_uri and attached authorization code. We assume, that redirect_uri is an endpoint on our own server.
- Mobile app follows redirect
- Our server receives request, takes authorization_code from query and exchanges it for access_token using POST /token method and client_secret (stored on server).
- Server responses to mobile app with access_token
- Mobile app takes access_token and uses it in future requests.
The "bad" one is:
- Mobile app stores client_id and client_secret
- Mobile app starts with GET /auth to receive authorization_code
- Authorization server returns response with redirect to redirect_uri and attached authorization code. We assume, that application intercept it and takes authorization_code (we can simply ask to redirect to localhost).
- Mobile app exchanges it for access_token using POST /token method and client_secret.
- Mobile app takes access_token and uses it in all future requests.
So i can't see real difference between this two alternatives. In both cases we end up with access token. In both cases we need real user to enter his login and password in rather secure webview.
Even if some bad guys will distribute fake application... what do prohibit them from using our server's callback to exchange authorisation code for access_token? Our server can't distinguish "bad" and "good" application - it just receives request GET \callback?code=blablabla and replies with access_token.
So why should we keep secret on server? What is the case of fraud with faked applications?