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
Case 2, GUI provided by the Client
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?
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.