We have a web-site, where each user has to log-in to access a private area. Inside the private area, there are some information about the user, a profile, including some sensitive information (home address, bank details, etc.)
Naturally, we follow best practices here (strong hashing, SSL with the correct algorithms, check for weak passwords, etc...).
We also offer an API base on OAuth for third parties. In this way the user knows what a registered application can access, the application does not have to store the user credentials, we can limit what the application gets... all the usual benefits. For example, the API can read the profile info, but the sensitive information is blanked out or omitted.
The problem is: we have a third party application that decided that using the API was no good; instead, it asks the credentials, store them (in plaintext...), and then authenticates using a POST. And reads user info doing screen-scraping. It actually then uses only the "public" information, but it could access also those sensitive information we would like not to disclose.
I am not particularly worried that the app will leak the user information (I think they did this way because they are sloppy/lazy, not malicious), but still this is less then desirable behavior. And it made me wonder: is there a way to handle this situation at the root?
EDIT: to be clear: I am not talking about solutions for "preventing" screen-scraping. We already have mitigations to make it hard (and others to make it even harder down the line) that will make this particular app desist. I am talking about the login process: what can you do to be sure the username and password came from your own form? One of the "selling-point" of OAuth is that you give your credentials to someone (google, twitter) you trust; indeed, you are redirected to a form on the "trusted" domain. Besides looking at the url, the provenience of the credentials is enforced somehow? If so, how?