Repository navigation
Session overwriting #131
Description
When the same user with an active session signs in again, a new session id is created.
There needs to be some investigation here around the implications and relevant bits of code. Clients from the first sign-in don't get the backchannel logout, although they are still signed in and the OP should track them. See https://openid.net/specs/openid-connect-backchannel-1_0.html#Tracking
With server side sessions, the refresh tokens are also lost.
Metadata
Metadata
Assignees
Labels
Type
Fields
Priority
High
Effort
None yet
Activity
oleks9o6 commentedon Oct 27, 2026
In case it helps the investigation: we've worked around this on our side by doing what Duende does.
When
CreateSessionIdAsyncgets properties without a session id, and there is a current session for the same subject, keep the current session id and copy the current client list into the new properties. A different subject, or no current session, gets a new session id. A session id the caller set explicitly is left as it is.What that gives:
RenewAsyncsees the same sid and subject, so the revocation from feat: revoke grants on session overwrite #105 doesn't fire for the same user. It still fires when a different user signs in over the session, which is the Bug: session in store could be overwritten with new sessionId and subjectId without cleanup on previous session state occurring, leaving dangling grants #99 case.We did it as a subclass of
DefaultUserSessionoverridingCreateSessionIdAsync. The cases we test: same subject keeps the sid and the client list; different subject gets a new sid and an empty list; an explicitly set sid is honored; no current session gets a new sid; and end to end, the first client's refresh token survives the second sign-in and the logout reaches both clients.The
same-user-new-sessionscenario in the repro repo I shared shows the current behavior, with and without server-side sessions.Happy to help with tests or a review if useful.