如果提供商和RP在同一个域上，那么在iframe中加载OpenID提供商是个坏主意吗？

Question

这里有很多问题，有人想要在iframe中加载OpenID提供商的登录页面，而不是重定向并让提供商控制整个外观＆amp;感觉登录页面。出于非常可靠的安全原因（主要是反网络钓鱼），这是一个很大的禁忌，禁止，大多数OpenID提供商都拒绝在iframe中加载。

我遇到过在单个组织的网站和应用程序中使用OpenID的情况。 OpenID提供商具有RP的白名单，并且仅响应这些RP。期望基于哪个RP将用户发送给它来在提供者处广泛地定制登录页面。 （如果有强烈的安全论据反对这样做，我也想了解它们。）

建议的解决方案是简单地允许RP在iframe中显示登录页面，这样他们就可以在他们想要的登录框周围放置任何设计。在这种情况下，只有“用户名”“密码”字段和“登录”“忘记密码”“注册新帐户”按钮将在提供商处托管，页面的其余部分将在RP处，并且仍然具有RP的地址标题栏。不是最佳，是的，但是论证是“它是一个不同的子域，但是相同的二级域，所以它仍然可以。”

我不明白这是怎么回事 - 对不同的应用程序使用非常不同的登录页面仍然会让用户更容易受到网络钓鱼和其他攻击。我在这个结论中不正确吗？关于此问题的每一个问题似乎都是关于使用外部或公共提供者，而我遇到的反驳是这些问题不适用于仅限于同一域名的网站的私人提供商。

Answer 1

即使您担任自己的提供者角色，在iframe中使用OpenID的一般担忧确实有一定的效力。如果您的任何组件容易受到脚本注入攻击，那么他们可能会损害您的用户凭据，因为您可以从父窗口访问iframe数据。

重定向的正常建议（可选地在pop-up中）将限制此风险，因为攻击者现在需要注入OpenID登录页面，在此页面中您可能没有脚本注入漏洞。

Answer 2

两年后我不认为这当前被认为是一个坏主意，特别是因为有一个OpenId Connect规范（目前在草案21），详细说明了iframe应该用于的过程使RP能够与iframe中的OP通信。

http://openid.net/specs/openid-connect-session-1_0.html

我不知道在批准之前需要多长时间，但它确实表明这是一种在RP中管理会话的有效方法。