How is Oauth2 protecting the resource owner?

Question

I've spent the last few hours reading about the Oauth2 protocol. From my understanding, the main motivation for this protocol is that the resource owner does not have to share their credentials with 3rd party (client) applications, only the resource server.

In this post, I have used the roles as defined in the Oauth2 RFC. However, I have not distinguished between the resource server and authorization server. I assume for the simplicity that they are the same and refer to them as "resource server".

I can see two different chain of events. Assume that both scenarios start with a resource owner with the intent to let a client access a protected resource.

Case 1, GUI provided by the resource server

1. Client forwards resource owner to the resource server's login page.
2. Resource owner provides his/her credentials at the resource server's GUI.
3. On success, the resource server forwards the resource owner to the Client and provides the user client with a token.

Case 2, GUI provided by the Client

1. The client asks the resource owner to provide his/her credentials to its own GUI.
2. The client sends the provided credentials to the resource server.
3. On success, the client obtains a token and access to the resource server.

My concern is case 2. How hard would it be for the client to obtain full privileges on the resource server if it, instead of authenticating as a client, authenticates as the resource owner? The RFC states the following as a reason to use OAuth2 instead of letting the client handle the resource owners credentials:

"Third-party applications gain overly broad access to the resource owner's protected resources, leaving resource owners without any ability to restrict duration or access to a limited subset of resources."

The RFC further states:

"Third-party applications are required to store the resource owner's credentials for future use, typically a password in clear-text."

This could very well be saved by the client in case 2.

So... Can you assume that a client that implements Oauth2 (In case 2) is more secure than one that does not? Is it possible for a resource server to implement mechanisms to prevent such things as these?

Answer 1

You can assume that using a proper OAuth2 implementation your system is more secure than a conventional user/pass based system.

Case 1 is clearly superior since no user credentials are exposed to the client.

Case 2 is only a possibility, many OAuth2 providers don't support it at all. Even the standard discourages using it, it seems to be there only as a fallback when the plain old user/pass based logic still must be used for some strange reason. This case is still slightly better as the client application has the possibility not to store your credentials at all. The specified credentials can be dropped right after creating the OAuth request and only the granted tokens should be stored. Gaining a refresh token, there is no need to ask for your user/pass again.

Note that stealing the tokens from the application is still a security risk, but the thief won't have full privilege with your credentials, will only have the access rights you have granted to the application. Furthermore, access tokens expire and the provider should support revoking refresh tokens.

Answer 2

Consider case2:

Lets say the resource owner has provided his/her credentials to the client and as you stated the client has to store the password somewhere in plain text form.

1) But can we trust the client that it would not access any information without your permission ??
2) what if someone hacks the client database and gain access to all the credentials which may contain sensitive information like netbanking passwords etc..,??

so to prevent these security-issues, the resource owner deals directly with resource server and sets the permissions for the client to access only information which it wants and not a bit more. Then the server issues a token(like a gatepass) to the client and whenever the client needs some information it has to send the token.

so its best not to give the client our credentials for security reasons.