I'm developing info.client.com, which needs to be embedded in an iframe on www.client.com. The main site is hosted by a third-party platform, while the embedded site runs on the client's Apache server. Users can authenticate successfully on both sites when visiting them directly, but the embedded iframe needs to recognize the session that is already active on the parent page.
I considered sharing cookies across the subdomains by using a cookie domain such as .client.com. However, the hosted site currently uses a __Host- HttpOnly cookie scoped specifically to www.client.com, so the info.client.com server cannot read or validate it. The alternative is for www.client.com to issue a signed, short-lived JWT containing the necessary identity or session information, pass it to the iframe, and let info.client.com validate it and create its own session.
I have full control over info.client.com, and the hosting provider may be able to make limited changes to www.client.com. What is the usual secure pattern for handling authentication in this setup?
2 Answers
A shared cookie only works if the parent platform actually issues a cookie with Domain=.client.com and the cookie is usable by the embedded application. A __Host- cookie cannot be widened to the parent domain: it must remain host-only, and HttpOnly also prevents client-side scripts from reading it.
Ask the provider for an endpoint or small integration that exchanges the parent session for a short-lived signed assertion. The parent can then deliver that assertion to the iframe with postMessage, and info.client.com can validate it server-side before creating its own cookie.
The token-based approach is generally the best fit here. Have the parent site obtain a short-lived, narrowly scoped token from its authentication system, then send it to the iframe with window.postMessage. The iframe should verify the message origin, send the token to its own backend over HTTPS, validate it there, and establish a local session.
Avoid putting a long-lived credential in the iframe URL. If a URL parameter is unavoidable, use a one-time or very short-lived exchange code rather than a reusable access token. This also avoids depending on cross-subdomain or third-party cookie behavior, which can be blocked or become difficult to reason about.
So simply setting a cookie domain on info.client.com won’t grant access to the parent’s existing host-only cookie. The provider would need to change how the parent session is exposed or provide a token exchange.