Third-party authentication protocols on the web usually rely on redirecting to the authentication provider rather than allowing (potentially untrusted) sites to embed their authentication controls.
When a user is redirected to a domain owned by the authentication provider, they can verify the provider's authenticity by checking the browser's security indicators (the full URL, the green SSL lock icon, etc.) before they enter their credentials. Usually, they are also informed about the scope of the data shared with the appplication.
A consent form looks something like this:
On the other hand, if you are prompted to enter your credentials embedded on an untrusted site or inside an untrusted application, you have no reliable means of verifying that your data is safe (unless you're willing to carefully analyze the app's source).
RFC 6749 (The OAuth 2.0 Authorization Framework) addresses the problem of embedded authentication in a few places. This is about native applications in particular, but it illustrates the problem with embedding:
9. Native Applications
When choosing between an external or embedded user-agent, developers
should consider the following:
o An embedded user-agent poses a security challenge because resource
owners are authenticating in an unidentified window without access
to the visual protections found in most external user-agents. An
embedded user-agent educates end-users to trust unidentified
requests for authentication (making phishing attacks easier to
And from the chapter about security considerations:
10.11. Phishing Attacks
Wide deployment of this and similar protocols may cause end-users to
become inured to the practice of being redirected to websites where
they are asked to enter their passwords. If end-users are not
careful to verify the authenticity of these websites before entering
their credentials, it will be possible for attackers to exploit this
practice to steal resource owners' passwords.
Service providers should attempt to educate end-users about the risks
phishing attacks pose and should provide mechanisms that make it easy
for end-users to confirm the authenticity of their sites. Client
developers should consider the security implications of how they
interact with the user-agent (e.g., external, embedded), and the
ability of the end-user to verify the authenticity of the
(Emphasis my own)