Does Silent Renewal Using iFrames Work with Modern Browsers?

[DBCoderAtLarge]

I recently discovered that the silent renewal does not work in the application that I am maintaining in my new job. I had previously got this working in another application and discovered that it does not work in that one anymore either, where it used to.

There's seems to be something about modern browsers which find iFrames problematic, because the error in the console is always about some iFrame error.

All you have to do is reduce the access_token lifetime to a really small number (e.g. 1.5 minutes) and you'll see a full page reload because the iFrame failed to do the renewal in an non-invasive manner.

I just wanted to know if others had noticed this.

[theadell]

I'm not an expert, but I can try to explain based on my understanding.

The problem isn't the Iframe but rather the third-party cookies.

When you log in to an authorization server, it sends a session ID to your browser in the form of a cookie. The browser sends this cookie with subsequent requests, so you don't have to re-enter your credentials each time you interact with the server.

Similarly, OpenID Connect's silent renewal uses a hidden iframe, creating a new browsing context within your application. It attempts to mimic the same process of sending the session cookie, this time within an iframe, to renew the session without the user noticing.

However, modern browsers view the cookie within an iframe as a third-party cookie since it is in the context of your application rather than a direct interaction with the authorization server. As browsers are increasing restrictions on third-party cookies, this could disrupt the silent renewal process. For instance, Google Chrome's support of third-party cookies will stop by the end of 2024

When third-party cookies are blocked, the silent renewal request to the AS doesn't include the session cookie. This means the AS can't identify the user, leading to the display of a login form. This need for manual re-authentication goes against the seamless experience intended by silent renewal.

There are other reasons as to why silent renewal might not work even if third-party cookies are enabled. Such as content security policies and Iframe sandboxing not being configured correctly.

The OAuth working group suggests using an architecture such as BFF to handle the token storage and renewal on the server side, which is much safer and more straightforward as you can use refresh tokens.

[pamapa]

However, modern browsers view the cookie within an iframe as a third-party cookie since it is in the context of your application rather than a direct interaction with the authorization server. As browsers are increasing restrictions on third-party cookies, this could disrupt the silent renewal process. For instance, Google Chrome's support of third-party cookies will stop by the end of 2024

There is still the chance that the iframe renewable process works: Within the hidden iframe the authz website is loaded. The URL of that window matches the authz URL. The session cookie, which the authz server set can use SameSite=strict. That session cookie is then passed along to the authz.

[Badisi]

Depending on the web browser you can also potentially find an option to enable third party cookies as before (their policies now being to turn if off by default). But every user would have to do it manually on their own, so depending on your use case this might not be the best UX solution..