Skip to content

feat(authProviders): add SESSION_COOKIE_DOMAIN for cross-subdomain OIDC#10929

Open
MichaelUray wants to merge 2 commits into
hcengineering:developfrom
MichaelUray:feat/auth-session-cookie-domain
Open

feat(authProviders): add SESSION_COOKIE_DOMAIN for cross-subdomain OIDC#10929
MichaelUray wants to merge 2 commits into
hcengineering:developfrom
MichaelUray:feat/auth-session-cookie-domain

Conversation

@MichaelUray

Copy link
Copy Markdown

Summary

koa-session defaults the cookie domain to the request host. For OIDC flows that start on one subdomain (e.g. dev.example.com) and receive the callback on a different subdomain (e.g. app.example.com, the host registered with the IdP) the Passport authentication-request state is lost — the session cookie set on dev is not sent to app, so the callback handler errors out with did not find expected authorization request details in session.

This PR adds an opt-in SESSION_COOKIE_DOMAIN environment variable. When set, the value is forwarded to koa-session so the cookie scope is widened to the configured parent domain (e.g. .example.com), allowing both subdomains to share the OIDC state cookie.

Default behavior unchanged

If SESSION_COOKIE_DOMAIN is unset or empty, the cookie configuration is identical to today — koa-session defaults apply, the cookie remains scoped to the request host. Single-host deployments require no action.

Security considerations (please review)

Widening cookie scope to a parent domain shares the cookie with every host under that parent. Operators must only enable this when all hosts under the configured domain are under the same trust boundary (operated by the same team, with the same security posture, same authentication realm).

Concrete guidance to add to the deployment doc:

  • OK: SESSION_COOKIE_DOMAIN=.internal.example.com when only the operator's own services live under .internal.example.com.
  • NOT OK: SESSION_COOKIE_DOMAIN=.example.com if third parties or customer-controlled subdomains exist under .example.com — they could read or set the session cookie.

The cookie continues to be marked HttpOnly and Secure (where the original config has them); this change only affects Domain attribute scope.

Behavioural matrix

SESSION_COOKIE_DOMAIN Cookie scope Use case
(unset / empty) request host (today's default) single-host deployment
.example.com all hosts under .example.com split-subdomain OIDC under same trust boundary

Verification

  • Unset / empty SESSION_COOKIE_DOMAIN preserves today's host-scoped cookie behaviour.
  • With SESSION_COOKIE_DOMAIN=.example.com, the OIDC session cookie is emitted with Domain=.example.com.
  • Whitespace-only values are trimmed to empty (treated as unset).

DCO

Signed-off-by Michael Uray. maintainer_can_modify=true.

…n OIDC

koa-session defaults the cookie domain to the request host. OIDC flows
that start on one subdomain (dev.example.com) and get the callback
on another (app.example.com, the host registered with the IdP) lose
the Passport state — the cookie set on dev isn't sent to app, so the
callback handler errors with 'did not find expected authorization
request details in session'.

SESSION_COOKIE_DOMAIN=.example.com scopes the cookie to the parent
domain so both subdomains share it. Empty / unset preserves the prior
behaviour for setups that only use a single host.

Signed-off-by: Michael Uray <michaeluray@users.noreply.github.com>
@huly-github-staging

Copy link
Copy Markdown

Connected to Huly®: UBERF-16532

…n-cookie-domain

Signed-off-by: Michael Uray <michaeluray@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant