How to handle silent-login in ZITADEL?

This post is more than a year old. The contents and recommendations in this blog could be outdated.

Silent-login and silent-refresh require the use of iFrames, which has to be allowed by ZITADEL. This brings some disadvantages in terms of security. You should be aware of the drawbacks and benefits, that is why we provide you with the basis for decision-making here.

Where are iFrames needed?

There are a few use cases where an iFrame is reasonable and needed, e.g silent-login or silent-refresh.

Silent-login and Silent-refresh

Silent-login and -refresh assumes that the user is already logged in and the existing session can be reused. The existing OpenID session should be reused for a new authentication request without the user noticing anything. This requires the prompt= none in the authentication request. To find out more about the possibilities of the request you can use the OIDC Authentication Request Playground. Silent-login is a general use case, regardless of the app type, whereas silent-refresh is mostly used in SPAs. The authentication request is usually triggered in an iFrame that the user won’t see.

How does ZITADEL handle it?

To maximise the security during login and in the ZITADEL Console UI, ZITADEL follows security best practices by setting a Content-Security-Policy (CSP) and X-Frame-Options:

Content-Security-Policy: frame-ancestors 'none'
X-Frame-Options: deny

These settings block the use of serving it in an iframe to prevent clickjacking attacks.

CSP

Content Security Policy (CSP) is a security standard that helps detect and mitigate certain types of attacks, including cross-site scripting (XSS), clickjacking and data injection attacks.

The policy is a string that contains the guidelines that describe your content security policy. The string can include a series of policy directives, each of which describes a certain resource type or area.

Relevant Examples:

Content-Security-Policy: default-src 'self'

All content should come from the site’s own origin (including subdomains).

Content-Security-Policy: default-src 'self' acme.com *.acme.com

Content from a trusted domain and its subdomains is allowed.

Content-Security-Policy: frame-ancestors ‘none’

“Frame ancestors” defines if it is allowed to embed the page. With none it is not allowed to embed the page.

Content-Security-Policy: frame-ancestors 'self' https://www.acme.com;

“Frame ancestors” defines if it is allowed to embed the page. The own site is allowed as well as https://www.acme.com

X-Frame-Options

The X-Frame-Options can be used to define if a browser is allowed to render a page in a <frame>, <iframe>, <embed> or <object>.

X-Frame-Options: DENY: It is not allowed to display the page in any frame SAMEORIGIN: It is allowed if all ancestor frames are the same origin as the page itself.

Enable iFrame use for your ZITADEL instance

The iFrame option is always enabled on your whole ZITADEL instance. Follow the steps below to apply the option: Navigate to the instance settings in your ZITADEL Console Click on the Security Policy tab Enable the “Allow iFrame” and add the host(s) from which you load the iframe from

This will change the CSP of ZITADEL to the following:

Content-Security-Policy: frame-ancestors https://custom-domain.com

and remove the X-Frame-Options header.

Liked it? Share it!