Is it a bad idea to load an OpenID provider into an iframe if the provider and RP are on the same domain?

There are a lot of questions here where someone wants to load an OpenID login page in an iframe rather than a redirect, and the provider controls the entire appearance of the login page. For very solid security reasons (anti-phishing in the first place) this is a big no-no, forbidden, and most OpenID providers refuse to load in an iframe.

I was presented with a situation where OpenID is used within a single set of websites and applications. The OpenID provider has a whitelisted RP and will only respond to these RPs. There is a desire to tweak the provider's login page intensively based on which RP sent the user to it. (If there are serious arguments to defend against this, I would like to know about them as well.)

The suggested solution is to simply let the RPs present the login page in an iframe so they can put any design in the login box they want. In this scenario, the Provider will only host the "Username" "Password" and "Login" "Forgot password" "Register a new account" fields in the Provider, the rest of the page will be in the RP and still have the RP address in the title bar. Not optimal, yes, but the argument is that "this is a different subdomain, but the same 2nd level domain, so it's still okay."

I don't understand how this could be so - very different login pages for different applications still leave users more vurnerable for phishing and other attacks. Am I wrong in this conclusion? Every SO question about this seems to be about using an external or public provider, and the counter-argument I come across is that these issues don't apply to a private provider limited to sites on the same domain.


source to share

2 answers

Common problems with OpenIDs in iframes do have some value, even if you are acting as your own provider. If any of your components are vulnerable to script injection, there is a risk that they could compromise your users' credentials as you can access the iframe data from the parent window.

A normal recommendation to redirect (not necessarily to a popup ) will limit this risk as the attacker now needs to type into an OpenID login where you presumably have no script flaws.



Two more years more and I don't think it is currently considered a bad idea, especially since there is an OpenId Connect specification (currently in draft 21) that details the process by which an iframe should be used to enable RP to communicate with the OP in the iframe.


I don't know how long it will take until this is ratified, but it does show that this is seen as a valid approach for session management in RP.



All Articles