title: Is loading an OpenID Provider in an iframe a bad idea if the provider and RP are on the same domain?
body: <p>There are plenty of questions here where someone wants to load an OpenID provider's login page in an iframe rather than redirecting and having the provider control the entire look &amp; feel of the login page. For very solid security reasons (primarily anti-phishing) this is a big no-no, prohibited, and most OpenID providers refuse to load within an iframe.</p>
  
  <p>I have been presented with a situation where OpenID is being used within a single organization's set of web sites and applications. The OpenID provider has a whitelist of RPs and will only respond to those RPs. There is a desire to extensively customize the login page at the provider based on which RP sent the user to it. (If there are strong security arguments against doing this as well, I'd like to know about them as well.)</p>
  
  <p>A proposed solution to this is to simply allow the RPs to present the login page in an iframe, so they can put whatever design around the login box they want. In this scenario only the "Username" "Password" fields and "Login" "Forgot Password" "Register New Account" buttons would be hosted at the Provider, the rest of the page would be at the RP and still have the RP's address in the title bar. Not optimal, yes, but the argument is that "it's a different subdomain, but the same 2nd level domain, so it's still okay."</p>
  
  <p>I don't understand how this could be the case - having very different login pages for different applications still leaves users more vurnerable to phishing and other attacks. Am I incorrect in this conclusion? Every question on SO about this appears to be about using an external or public Provider, and the counterargument I'm encountering is that those concerns don't apply in a private Provider limited to sites on the same domain.</p>