Per-product login sessions: one identity's session cannot serve several products on Thunder

[kanushka]

Problem

The shell's session model is one login per identity, with every product namespace deriving its access from that one session. Measured on ThunderID v1.0.0-beta (see #41), that model does not hold:

• Thunder requires an RFC 8707 resource parameter on the authorization request.
• It accepts only one — "Only a single resource parameter is supported".

So a Thunder login session is pinned to exactly one resource server, and therefore to exactly one product audience, from the moment of authorization.

#41 ships Thunder support for single-product identities and refuses a Thunder identity that declares more than one product, which is a legible limit rather than a confusing runtime refusal. This issue covers lifting it.

Why this is not a surprise

docs/research/product-authentication-compatibility.md §1.5 already records "Per-product session multiplicity — one context needs several concurrent product sessions" as a required cross-cutting gap. #41 is the first hard evidence for it.

What it touches

• The session model: a stored session is keyed by identity today; it would need to be keyed by identity and product.
• The context schema: credentialRef is per identity and would need a per-product form.
• wso2 login: one invocation currently establishes one session; it would need to establish, or lazily establish, one per product.
• The broker: choosing which session answers a given namespace's request.

Backend ask, not filed upstream

Thunder supporting multiple resource parameters at authorization would remove the need for most of this. Owner: thunder-id/thunderid. Not filed there — recorded here so the ask has a home, matching how the compatibility research records backend asks with owners.

Notes

• Asgardeo and Identity Server are unaffected: neither takes an audience at authorization time, so one session serves every product there. This is Thunder-specific and follows from a stricter, arguably better, audience model.
• Related: Decide what the broker claims when a deployment cannot bind a token to one product #37, which asks what the shell should claim when a deployment cannot bind a token to one product. Thunder is the opposite case — it binds tightly and charges for it in session multiplicity.

Follows from #41.

[kanushka]

Correction: this is token multiplicity, not sign-in multiplicity

The issue body says a Thunder login session is pinned to one product. That is right about tokens and needs sharpening about sign-in.

What is forced by Thunder: an access/refresh token pair is bound to exactly one resource server, because resource is required at authorization and only one is accepted. Two products therefore need two authorization exchanges and two stored refresh tokens. That part is unavoidable and is the substance of this issue.

What is not established: whether the user has to authenticate again for each of those exchanges. That depends on whether the deployment carries a single sign-on session between authorization requests, which is a separate question from audience binding.

Measured, 2026-08-06, ThunderID v1.0.0-beta at https://localhost:8490: a second authorization request, in the same browser roughly ten minutes after a completed sign-in, presented the sign-in form again. So no single sign-on was observed on a default deployment.

That verdict is deliberately narrow. It does not distinguish between Thunder carrying no session by default, the default authentication flow always prompting, and a setting that was simply not configured here. It should not be read as "Thunder does not do SSO".

Two earlier flows in the same session appeared to skip sign-in. They did not — both were refused at the authorization endpoint before authentication ran, because resource is validated first. They are not evidence of a session.

Consequence for this issue: even with single sign-on working, the shell would still need one authorization round-trip and one stored refresh token per product. Single sign-on would make the extra round-trips silent, not unnecessary. Whether it does is worth measuring before this issue is designed, because it decides whether per-product sessions cost the user anything visible.

[kanushka]

Triage: the follow-up comment on this issue found that Thunder's single-sign-on behavior needs to be measured before the per-product-session design can be scoped — the comment's own words: "worth measuring before this issue is designed." Labeling needs-triage until that measurement lands and a concrete design can be written.