Lately the internet has been abuzz about micro-frontends. Micro-frontends are a great pattern for enabling teams to deliver customer facing value q...
For further actions, you may consider blocking this person and/or reporting abuse
nice blog! I wonder how one could manage Auth0 token lifecycle with micro-frontends. I am building a React SPA which has a container that contain other micro-frontends and am considering the PKCE flow. What do you think would be the most effective approach to share the authentication? I think that one approach is to inject the token to micro-frontends by the container (that handles authentication) during initialization and another approach is to share the token via the cookie.
It sounds like you're achieving micro frontends by joining together multiple React components/apps either at runtime or at compile time. In that case you should be able to have your authentication done at a higher level than these app then either inject it as you say, or provide it through a context provider. I would consider abstracting it away entirely and providing your components with an authenticated fetch api where the abstraction handles attaching authentication to requests and handling token lifecycles. That api could then be injected or provided. A caveat on that is that I haven't thought deeply on potential edge cases.
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.this sounds like google OAuth, the idea of redirecting the user out somewhere to be authenticated, but I am actually trying to put this together right now with a react microfrontend not built with CRA and an Express API and I am hitting a wall where the proxy is not working, I get a 404 on that localhost:5000/auth/google proxy. Anything a bit more involved than what you have here on how to resolve that?
Hi Daniel, good pickup. This is based on Open ID Connect (OIDC) which is built on top of the OAuth2 psec.
Sorry I don't think I can help you without seeing the code on this one. Best of luck figuring it out.