To my understanding is that the 1px iframe method is the best way to get fresh access, identity and rotating refresh tokens (if required / supported) without having your user see the redirects that are happening as they move between multiple applications that are masquerading as a single user experience.
This method is for micro front ends, where multiple distinct front + back end stacks work as a single seamless experience for a user. For different application architectures I would consider different implementations. For instance I wouldn't use it if I had a single server that multiple front ends communicated with a single back end I would consider HTTPOnly cookies.
Sorry, I was a bit imprecise here. With Safari and ITP, cookies in cross-origin iframes are blocked. Chromium plans to discontinue third-party cookies as well (blog.chromium.org/2020/01/building...)
Thanks for the info. My reading of this is we should be able to continue using iframes for authentication as long as we keep our cookies as first party cookies by having our authentication server on the same domain as the website the user is using.
In the short term the cookies will continue to work even across domains as long as the authentication server is setting a same site lax cookie.
Thanks again for responding with that info.
My understanding is that depends on where the cookie is set, auth.acme.com could set a cookie on auth.acme.com in which case it would not be 1st party on app.acme.com but if it was set set it on the root domain acme.com then it would be accessible on all subdomains of acme.com including app.acme.com.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Very interesting, however is the workaround with the 1px hidden iframe really the best practice?
To my understanding is that the 1px iframe method is the best way to get fresh access, identity and rotating refresh tokens (if required / supported) without having your user see the redirects that are happening as they move between multiple applications that are masquerading as a single user experience.
This method is for micro front ends, where multiple distinct front + back end stacks work as a single seamless experience for a user. For different application architectures I would consider different implementations. For instance I wouldn't use it if I had a single server that multiple front ends communicated with a single back end I would consider HTTPOnly cookies.
As far as I know, hidden iframes don't work in Safari and support in Chrome is also scheduled to be discontinued.
Interesting, thanks for letting me know. Do you have any links so I can read more?
Sorry, I was a bit imprecise here. With Safari and ITP, cookies in cross-origin iframes are blocked. Chromium plans to discontinue third-party cookies as well (blog.chromium.org/2020/01/building...)
Thanks for the info. My reading of this is we should be able to continue using iframes for authentication as long as we keep our cookies as first party cookies by having our authentication server on the same domain as the website the user is using.
In the short term the cookies will continue to work even across domains as long as the authentication server is setting a same site lax cookie.
Thanks again for responding with that info.
And "same domain" means the exact same domain, right?
Auth server on auth.acme.com and application on app.acme.com wouldn't work.
My understanding is that depends on where the cookie is set,
auth.acme.comcould set a cookie onauth.acme.comin which case it would not be 1st party onapp.acme.combut if it was set set it on the root domainacme.comthen it would be accessible on all subdomains ofacme.comincludingapp.acme.com.