SqlOS 7.2.0: Sessions and stored credentials stop when they should

7.2.0 closes the gaps where a copied secret-less refresh, a leftover operator cookie, a signed-out SSO portal cookie, or a deactivated user's calendar token kept working after the session that issued it was supposed to be over.

Confidential clients authenticate on every refresh

POST /sqlos/auth/token with grant_type=refresh_token is the refresh flow for every client. A confidential client must present its registered method there: client_secret_basic or client_secret_post. A missing, wrong, expired, revoked, or wrong-client secret returns invalid_client and does not rotate the token, open the grace-window cache, or revoke the legitimate successor.

The JSON route POST /sqlos/auth/token/refresh and in-process RefreshAsync stay available for public clients (token_endpoint_auth_method=none). They have no credential channel, so a confidential client's refresh token is rejected before rotation. Host code that refreshed a confidential client through those paths must move to the token endpoint with client authentication.

Public-client refresh, rotation, and the grace window are unchanged.

See Refresh and logout, Clients, and the token request.

Operator and portal cookies stop outliving the action that should end them

Three cookie lifetimes now match the control that revokes them:

• Dashboard password rotation. In password mode, the operator session cookie is bound to Dashboard.Password. Rotating that password and reloading the host invalidates every previously issued operator cookie. Cookies issued after the rotation work until SessionLifetime. Development-only mode and authorization-callback mode are unchanged. There is no separate "sign out all operators" switch; rotation is the incident-response step.
• SSO portal sign-out. Signing out revokes that exact server-side portal session, records sso.portal.session.closed, and only then clears the continuation cookie. A copied cookie cannot read or change setup state after that commit. Another portal session for the same organization stays active until its own sign-out.
• Same-site CSRF on cookie mutations. Dashboard, FGA, and SSO-portal mutations that present their session cookie require X-SqlOS-Request: 1 and an Origin or Referer that matches the public origin, the issuer origin, or the request host after trusted forwarded headers. The hosted dashboard and setup portal send the header. Bearer and callback administration that does not send those cookies is unchanged. A same-site sibling origin is rejected before the mutation or its success audit is committed.

See Production readiness, Dashboard, Customer-managed SSO, and Configuration.

Calendar credentials follow offboarding

Deactivating a user or organization already revoked sessions, refresh tokens, and issuer sessions. Stored Google and Microsoft calendar refresh tokens did not. 7.2.0 revokes those connections in the same lifecycle:

• Organization deactivation clears every organization-owned connection in the same transaction as its sessions.
• User deactivation, including a SCIM deprovision that removes the last active membership, revokes that user's connections. A row flipped inactive directly in the database is caught the next time anything touches the connection.
• Refresh, sync, and event push re-check the owner before using credentials. A racing write cannot put fresh provider tokens back onto a revoked connection.
• Reactivation does not restore credentials. The person reconnects explicitly.

Sign-out, password reset, and leaving one organization still revoke sessions only. Calendar connections stay until the owner is actually offboarded.

See Calendar integration, Organizations, and Sessions and tokens.

Upgrade notes

dotnet add package SqlOS --version 7.2.0
npm install @sqlos/headless@7.2.0              # if you render your own login UI

If a server-side host refreshes a confidential client with RefreshAsync or POST /sqlos/auth/token/refresh, switch that call to POST /sqlos/auth/token and authenticate with the client's registered secret method. Public clients do not need a code change.

Cookie-authenticated scripts against the dashboard or SSO portal need X-SqlOS-Request: 1 and a matching Origin or Referer. The hosted UI already sends both.

After this upgrade, rotating Dashboard.Password signs every existing operator out. Plan that rotation as a session revocation, not only a secret change. Deactivating a user or organization also disconnects their calendar connections; reconnect after reactivation.