Come può un utente finale verificare l'autenticità del modulo di accesso di un provider di autenticazione di terze parti

how can end-users verify the authenticity of the login forms that collect their credentials?

I protocolli di autenticazione di terze parti sul web di solito si affidano a reindirizzare al provider di autenticazione piuttosto che consentire ai siti (potenzialmente non attendibili) di incorporare i loro controlli di autenticazione.

Quando un utente viene reindirizzato a un dominio di proprietà del provider di autenticazione, può verificare l'autenticità del provider controllando gli indicatori di sicurezza del browser (l'URL completo, l'icona di blocco SSL verde, ecc.) prima di immettere le credenziali. Solitamente, vengono anche informati sull'ambito dei dati condivisi e sulle autorizzazioni concesse all'applicazione.

Ad esempio, se si sta effettuando l'autenticazione con Google, si prevede di essere reindirizzati a una schermata di consenso come questa:

(Image Source)

What's to stop a malicious website from displaying a fraudulent Google or Facebook login form, for the purpose of harvesting user credentials?

Se ti viene richiesto di inserire le tue credenziali incorporate su un sito non affidabile o all'interno di un'applicazione non affidabile, non disponi di mezzi affidabili per verificare che il tuo contributo sia sicuro (a meno che tu non sia disposto a ispezionare attentamente la fonte dell'app, che non è realistico per l'utente medio).

RFC 6749 (Il framework di autorizzazione di OAuth 2.0) commenta il problema dell'autenticazione incorporata in alcuni punti. Riguarda in particolare le applicazioni native, ma illustra il problema generale con l'incorporamento:

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
      execute).

(Proprietario risorse = l'utente)

E dalla sezione sulle considerazioni sulla sicurezza:

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
   authorization server.

(Enfasi mie)

Il commento di Arminius risponde alla tua domanda per tutte le implementazioni effettive di questo.

Tuttavia, il modulo incorporato nella pagina padre poteva aprire gli strumenti di sviluppo e controllare il dominio da cui era stato caricato l'iframe. Puoi anche inserire credenziali false e guardare per vedere dove è stata inviata la richiesta.

Tutte le versioni recenti dei principali browser desktop (Chrome, Firefox, cioè Opera, Edge, ecc.) dispongono dei set di strumenti necessari per eseguire entrambi i precedenti.