Customer portal embeds our system in an iframe and users are bounced back to the login page after signing in: should we check cookies or the session first?

Bottom line first: When a customer portal embeds our system in an iframe and users are bounced back to the login page after a successful sign-in, it is mostly not an incorrect username or password, nor a sudden loss of the backend session. It is usually that the browser does not send the login cookie in a third-party context. In 2026, default restrictions on third-party cookies in mainstream browsers are still tightening. For embedded delivery, first run a three-part check: whether the request side carries it, whether the response side is rejected, and whether the storage side persists it. Then decide whether to change configuration, change redirects, or switch to tickets. Do not start by changing session duration.

1. What exactly breaks in the iframe login state

To understand this, first clarify who is the first party. The user's address bar stays on the customer portal's domain, and our page runs inside an iframe, so to the browser we are third-party. Whether a cookie can be carried in a third-party context depends on whether the SameSite attribute, Secure flag, and domain and Path matching are all satisfied at the same time. If any one is not satisfied, the browser may not send this cookie, or may not save it at all.

This is also why it often appears at the end of delivery: during local development, pages and APIs share the same domain, so developers do not experience the third-party context; once embedded in the customer portal, the chain changes. Login logic that works normally on the same domain becomes subject to a different set of browser rules inside an iframe, and local behavior cannot be used to infer production behavior.

• Cookie not sent: There is no session cookie in the request header. This is common when SameSite is set to Lax or Strict, the Secure flag is missing, or the browser blocks third-party cookies by default.
• Cookie sent but not recognized: The request header contains the cookie, but the server treats it as invalid. This is often because Domain is set too narrowly to be retrieved, or same-named cookies are duplicated across multiple paths.
• No cookie at all: Set-Cookie is rejected by the browser and a blocked warning appears in developer tools. This is easily misjudged as the backend not returning it.

2. Three-part verification method: request side, response side, storage side

Rather than guess, check in a fixed order. In projects, we usually use the 'three-part verification method': the request side checks whether it is carried, the response side checks whether it is rejected, and the storage side checks whether it is persisted. Do not reverse the order, because the conclusion of the later part can be skewed by a false impression from the earlier part. For example, when the request header has no cookie, it is easy to misjudge it as a lost server-side session, when in fact the browser did not send it at all.

1. Request side: Open developer tools in the iframe context, find the request for the redirect after login, and check whether the Cookie request header exists and whether it contains the session key. Make sure to select the iframe context; if you select the wrong top-level frame, you will see another set of requests.
2. Response side: Check the Set-Cookie returned by the login API, focusing on the four items SameSite, Secure, Domain, and Path, and whether the browser marks it as blocked.
3. Storage side: In the Application panel, confirm whether the cookie is actually written, under which domain, and whether multiple same-named cookies overwrite each other.

After the three checks, you can usually reach a clear conclusion. What should be avoided is changing configuration without checking: changing SameSite directly from Lax to None without also enabling Secure may look fine in an HTTP test environment, but break again in production when HTTP and HTTPS are mixed. This kind of rework is not rare in delivery.

3. Three common changes: costs and suitable cases differ

After confirming that the issue is third-party cookies, there are commonly three paths. Which one to choose depends on whether the customer portal is willing to cooperate and who manages the account system. Below is a comparison based on common experience ranges in 2026 project delivery; the specific schedule still depends on the number of integrated systems and the review process.

• Option A: switch to top-level redirect or new-window login. The change is small, with an experience range of about 1-3 person-days; it is not affected by third-party cookie policies and is relatively stable; the cost is a fragmented experience, as users jump back and forth between the customer portal and our pages, and the customer side often has to repeat a UI review.
• Option B: dedicated subdomain + SameSite=None; Secure. Configuration-level changes take about 1-2 person-days, but require site-wide HTTPS; even when configured, it may still be blocked in browsers that block third-party cookies by default, so regression testing on real endpoints is needed, and conclusions should not be drawn from a single machine.
• Option C: use a one-time ticket inside the iframe to exchange for a session. The customer portal passes a short-lived ticket via postMessage, and we establish a session under our own domain; the change is moderate, with an experience range of about 5-15 person-days, involving signature validation, ticket validity period (typical range 30-120 seconds), and replay protection. Security review must be completed in advance.

To decide which is more suitable, do not look at whether the technology is new; look at two things: whether the customer allows leaving the iframe, and who issues the login state. The former determines whether Option A is feasible, and the latter determines the boundary of Option C. If the account system is mainly held by the customer, Option C is usually more controllable than Option B; if the other party allows top-level redirects, prioritize Option A, which has smaller changes.

4. At delivery: practices and costs under constraints

A common situation in projects is: the customer portal domain is fixed, new windows are not allowed, accounts are still issued centrally by customer IT, and only two weeks are allowed for the schedule. A relatively stable approach is to first perform packet capture verification on real endpoints, then produce a small compatibility matrix by browser type, and record the three symptoms separately: cannot sign in / bounced back after sign-in / can sign in but drops offline after refresh, rather than logging them as one vague statement: login has a problem. The typical range for the number of endpoint types covered by the compatibility matrix is 2-4, and the typical range for ticket validity is 30-120 seconds; the specifics should still be adjusted according to the customer's network and review requirements.

The costs are real too: in one project, because only SameSite was changed and Secure was not synchronized, the HTTP site passed in the test environment, but the production HTTPS site was blocked due to mixed content; there were two rounds of rework and a delay of three to four days. Later, we made the three-part check a fixed acceptance item in the integration testing checklist, and similar issues could basically be traced to the specific layer on the first day, instead of guessing back and forth between session duration and frontend code.

5. When it fits and when it does not

When it fits: in B2B delivery, the system is embedded in the customer's OA, portal, or workspace, and the customer wants users to go through the whole flow without perceiving a redirect; there are many endpoint and browser types, and a verifiable compatibility behavior matrix is needed. When we do embedded portal integration, we also provide this matrix to customer IT as a delivery attachment, making it easier to check item by item during later integration testing.

The cases that do not need a heavy solution should also be stated clearly: if the other party allows top-level redirects, or the endpoint browser version is locked down and used only on a small number of intranet machines, prioritize the solution with the smallest change; for purely internal systems where pages and APIs share the same domain, third-party context is usually not involved, and an additional ticket mechanism is not needed. Option C is not a universal solution either: a ticket validity period that is too long increases replay risk, while one that is too short may fail to exchange for a session on weak networks, so the experience range should be chosen according to real network conditions. If customer security review requirements are strict, the ticket option should document signature, validity period, and replay protection clearly before scheduling.

Common questions

Local login works, but as soon as we embed in the customer portal it redirects back to the login page. Is this a frontend bug?

Most often it is not a frontend code error, but after the page enters a third-party context, the cookie is blocked by same-site policy or blocking policy. First check whether the request header after login actually contains the session cookie.

If SameSite is changed to None and Secure is added, will the cookie be sent?

Not necessarily. These two items are only necessary conditions; you also need to check whether the browser blocks third-party cookies by default, whether the page is fully HTTPS, whether Domain and Path match, and whether same-named cookies overwrite each other.

Users can sign in successfully inside the iframe, but are logged out after one refresh. Is the session duration set too short?

Do not change session duration first. If the first redirect after login carries the cookie but a refresh does not, a common cause is that the cookie was only written in the redirect response, and the path or domain of the refresh request does not match.

The customer portal will not change, so only our side can change. Roughly how much effort is required?

Based on the experience range, changing to top-level redirect is about 1-3 person-days, and ticket-for-session is about 5-15 person-days; whether a security review is required and whether multi-browser regression is needed will significantly affect the schedule. Do not quote an estimate based only on single-machine verification.

Next-step recommendation: first capture a request on real endpoints using the three-part verification method, distinguish 'not sent,' 'rejected,' and 'sent but not recognized,' then confirm with the customer who owns the login state and whether leaving the embed is allowed, and write the compatibility behavior into the acceptance checklist. If a ticket option is involved, complete the security review before scheduling; if the customer only uses a small number of locked-down endpoints on the intranet, a heavy solution is usually unnecessary.