Amazon Cognito hosted UI impossible to iframe?

Question

I tried, but in headers X-Frame-Options: deny and I do not found any way to configure this inside backend UI.

Answer 1

I'm not sure how much of an "answer" this is, but I don't yet have enough reputation to comment and I think this is relevant. The accepted answer doesn't really address iframes at all.

I can't find it documented anywhere, but my guess is that AWS doesn't allow this due to click-jacking concerns.

The FAQ page for Microsoft's Azure AD B2C (a product similar to Cognito) explains why they don't allow their hosted pages to be embedded in iframes:

No, for security reasons, Azure AD B2C pages cannot be opened within an iFrame. Our service communicates with the browser to prohibit iFrames. The security community in general and the OAUTH2 specification, recommend against using iFrames for identity experiences due to the risk of click-jacking.

Source: https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-faqs

Answer 2

I do not found any way to configure this inside backend UI.

TLDR: Looks like you can't configure it.

How is iframe Embedding Blocked?

How did AWS prevent iframe embedding? As you pointed out:

in headers X-Frame-Options: deny

AWS use the x-frame-options: DENY header on purpose to block iframe embedding and thus defend against ClickJacking, as hypothesised in this answer. Here is a quote from rachitdhall, who at the time of writing is a "Software Development Manager working for Amazon Cognito":

X-Frame Options is used to prevent ClickJacking.

Here is the source of that comment on GitHub.

Indeed, if I log into my AWS account and navigate to my Cognito hosted UI in my web browser, I can still see today x-frame-options: DENY as one of the headers coming in. I won't go into what this does - instead readers should refer to the MDN docs.

The comment appears on this GitHub issue, which is still open at the time of writing, so presumably AWS have not today implemented the feature to allow Cognito users to enable embedding of the hosted UI in their custom pages.

Why Don't AWS Allow their Customer to Configure the Headers?

Again returning to this GitHub comment:

We have heard the request to allow IFRAMES from other customers and will consider it in future updates to the service.

It leaves you wondering, almost 5 years on, why is this not implemented "yet"?

I'll try to speculate, but note that I do not represent AWS and cannot speak on their behalf. All I am doing in the following is pointing out some difficulties that make the implementation of this feature non-trivial; perhaps less trivial than it might seem at first glance.

No CSP Headers

Firstly, I do not see any Content-Security-Policy (CSP) headers coming from AWS yet. From the MDN docs, note that:

The Content-Security-Policy HTTP header has a frame-ancestors directive which obsoletes this header for supporting browsers.

Maybe we will see CSP headers over the next few years. But this may or may not result in a customisable iframe embedding feature for the hosted UI. I'll give some reasons in the following sections.

Limitation

x-frame-options only allows two values: DENY and SAMEORIGIN. Neither would suffice to allow a customer to embed the hosted UI on their custom page, which is presumably a different origin to that of the hosted UI e.g. example.com vs auth.example.com. Note: I believe this is impossible, even using the deprecated approach of setting document.domain as proposed in this answer, because doing so requires the new origin to be:

its current domain or a superdomain of its current domain

This again, according to the MDN docs.

So since AWS manages Cognito, and since AWS are hardly going to allow use of a deprecated feature with security risks, we can assume the document.domain of auth.example.com can't be modified, and on the other hand the domain of example.com can't be modified to auth.example.com vs because that's a subdomain, not self or a superdomain.

Security / Responsibility

Since x-frame-options won't work, presumably the way for AWS to grant their customers this feature would be to allow them to edit the frame-ancestors directive in the CSP header of the hosted UI; this would assume AWS adds a CSP header of course. But then AWS is handing over some more control to its customers and this somewhat blurs who is responsible for the security of the hosted UI. This would probably mean a lot of work for AWS revising their shared responsibility model for the Cognito hosted UI.

Backwards Compatibility

Even if AWS do add the CSP header, and even if they do allow customers to edit it, there is still the issue of backwards-compatibility. AWS will likely be loth to completely discard the x-frame-options header, in case some browsers do not yet process the frame-ancestors CSP directive.

For browsers that do support the frame-ancestors CSP directive, then according to W3 docs:

the frame-ancestors policy SHOULD be enforced and the X-Frame-Options policy SHOULD be ignored.

But what if it isn't ignored? And what about older browsers that don't process the frame-ancestors CSP directive yet? For such browsers, the frame-ancestors CSP directive will be ignored, the x-frame-options denial will kick in, and the functionality won't work. And then AWS will likely get a bunch of complaints from their customers about a feature that's broken.

Answer 3

You can check this post on Github: https://github.com/aws/amazon-cognito-identity-js/issues/508. In ildar-icoosoft's respond, he showed how he managed to put the hosted ui in a pop-up window. Hope this can help

Answer 4

In case someone else is looking for this: it turns out cognito will run in an iframe if you set the iframe's document.domain to amazoncognito.com. Of course, then the underlying resource that you're trying to load must run inside the iframe with that domain. If that underlying resource uses cookies, they won't work if 3rd party cookies are disabled on the user's browser.