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?

I want to tackle the problem in the most effective way, and I am starting to wonder: is there a way to let the user login ONLY through your page?
To avoid that someone else authenticates using just a POST?
To the best of my knowledge, you can make it difficult to do (using one-time ids in the page/headers, using client-side (Javascript) hashing, etc.) but there is no way to be 100% sure the post comes from "your page". But I am no security expert, so I may be missing something. And in any case, which is the best way to mitigate the problem, making it impractical enough (but with little or no burden upon the user - no captcha - which will not solve the issue, anyway)?