Something I still don't understand about the OAuth flow is how it's _not_ training users to be more easily phished for actual usernames and passwords. The very first step is "If you are not logged into the third-party, display a login-form from the third-party."
The thing is, you never really know off-hand if you're logged into the third-party (provider) or not without opening a second tab and going directly to the third-party's site, since you're always getting logged out after various timeouts, cookie-clearing, browser-closing, and computer-restarting events.
What prevents an OAuth client application from displaying an OAuth process that shows a fake login form, which looks identical to the provider's login form, to get the user to enter their provider username and password before they realize the URL is off? It seems like it trains users that it's normal for websites to launch a Gmail login form and this is perfectly safe.
> The thing is, you never really know off-hand if you're logged into the third-party (provider) or not without opening a second tab and going directly to the third-party's site
That's exactly right! But with OAuth, when you authenticate, you go directly to the login-form from the third party (assuming here that by third party you mean the party you have an account with)! Ideally, the client (the app you're using) doesn't even know where you (the user, via the user-agent, otherwise known as "browser") went to log in, it only knows the address of the authorization service (which does not need to be the same domain as the actual login server). That's the great thing about OAuth!
But for this to work, authentication must be performed in a reliable browser, hence the importance of the green URL bar in browsers: so you know you really are in the Google login page, not in some phishing website, when you enter your credentials.
This is something that the identity provider struggles with. Supporting additional authentication factors can help, although the newer active phishing attacks are causing issues. Certificates, kerberos and webauthn are inherently phishing resistant which mostly solves the problem if you can rely on or leverage them.
You can also do a form of device enrollment/tracking via a cookie. Since a phisher will not have that cookie, the user authentication experience can switch to be more robust. This also typically triggers a notification to the user that a new device or browser was seen.
You also have threat detection technologies outside of cookies, such as looking at IP address geolocation and doing time of flight analysis.
Thats all stuff the identity provider can do. From a user perspective today - check the address bar, and/or use a password manager.
The thing is, you never really know off-hand if you're logged into the third-party (provider) or not without opening a second tab and going directly to the third-party's site, since you're always getting logged out after various timeouts, cookie-clearing, browser-closing, and computer-restarting events.
What prevents an OAuth client application from displaying an OAuth process that shows a fake login form, which looks identical to the provider's login form, to get the user to enter their provider username and password before they realize the URL is off? It seems like it trains users that it's normal for websites to launch a Gmail login form and this is perfectly safe.