The console keeps a person signed in for days after the sign-in behind it has expired #24

New Issue

2026-09-21T07:18:08Z

cgalo5758 commented

2026-09-21 07:18:08 +00:00

The question

The console's own session lives for seven days. Everything it was built on expires far sooner: the identity token in minutes, and the provider's own session on its idle and maximum limits, which a deployment sets and the test seed does not. Nothing re-checks the console session against the provider after sign-in, so hours later the console still says signed in while the provider no longer agrees, and a link into the account pages lands on a sign-in prompt. How long may a console session outlive the sign-in it came from, and what re-establishes it?

What depends on the answer

Whether the console's session length becomes a function of the provider's, whether the console holds a refresh token, and what a person sees when the two disagree. One symptom of the same gap is already fixed: the stored, long-expired identity token is no longer replayed when signing out, which used to strand the person on the provider's error page.

Options known so far

Set the console session to the provider's maximum session length and accept a re-sign-in at that boundary.
Re-validate silently at intervals with a no-prompt authorization request, treating failure as signed out.
Store the refresh token and end the console session when a refresh fails.

Decided when

The session model states the console session's lifetime, what re-validates it and how often, and what a person sees when the provider has ended the session; the console implements that one answer rather than a guard chosen at a call site.

Migrated from status/issues.md at b7a0e15

## The question The console's own session lives for seven days. Everything it was built on expires far sooner: the identity token in minutes, and the provider's own session on its idle and maximum limits, which a deployment sets and the test seed does not. Nothing re-checks the console session against the provider after sign-in, so hours later the console still says signed in while the provider no longer agrees, and a link into the account pages lands on a sign-in prompt. How long may a console session outlive the sign-in it came from, and what re-establishes it? ## What depends on the answer Whether the console's session length becomes a function of the provider's, whether the console holds a refresh token, and what a person sees when the two disagree. One symptom of the same gap is already fixed: the stored, long-expired identity token is no longer replayed when signing out, which used to strand the person on the provider's error page. ## Options known so far - Set the console session to the provider's maximum session length and accept a re-sign-in at that boundary. - Re-validate silently at intervals with a no-prompt authorization request, treating failure as signed out. - Store the refresh token and end the console session when a refresh fails. ## Decided when The session model states the console session's lifetime, what re-validates it and how often, and what a person sees when the provider has ended the session; the console implements that one answer rather than a guard chosen at a call site. Migrated from status/issues.md at b7a0e15

cgalo5758 added the

kind

design

area/identity security labels 2026-09-21 07:18:08 +00:00

cgalo5758 commented

2026-09-25 06:17:59 +00:00

Fixed by the security remediation in 0b28a9d (change identity-refresh-interval, 2026-09-09). This issue was written before that change and migrated afterwards without being re-checked.

The console no longer trusts a session for its whole lifetime. Every five minutes it presents the session's refresh token to the identity provider. When the provider refuses it, because the provider's own session expired or was ended, or the account was disabled, the console ends the console session on that request. See identityRefreshInterval in internal/auth/auth.go.

A console session can therefore outlive the sign-in behind it by at most five minutes, not days. Closing that remaining window is #7.

One case keeps the old behaviour: a provider that issues no refresh token. Keycloak issues one for the sign-in flow the console uses.

Fixed by the security remediation in 0b28a9d (change `identity-refresh-interval`, 2026-09-09). This issue was written before that change and migrated afterwards without being re-checked. The console no longer trusts a session for its whole lifetime. Every five minutes it presents the session's refresh token to the identity provider. When the provider refuses it, because the provider's own session expired or was ended, or the account was disabled, the console ends the console session on that request. See [`identityRefreshInterval` in `internal/auth/auth.go`](https://git.coopcloud.tech/wiki-cafe/member-console/src/commit/94334c0/internal/auth/auth.go#L1160). A console session can therefore outlive the sign-in behind it by at most five minutes, not days. Closing that remaining window is #7. One case keeps the old behaviour: a provider that issues no refresh token. Keycloak issues one for the sign-in flow the console uses.

cgalo5758 closed this issue

2026-09-25 06:18:03 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wiki-cafe/member-console#24