Gitter OAuth session persistence after upstream credential revocation

Direct answer

No. Revoking Gitter's OAuth authorization at GitHub or GitLab should not be assumed to terminate an active Gitter web session immediately. If Gitter issues its own session token after the OAuth handshake, that session normally remains usable until the Gitter-issued token expires or Gitter explicitly invalidates it. Separately, the scopes granted during the original authorization are fixed for that grant; you cannot reduce them on the existing grant without re-authorizing.

Likely explanation vs. confirmed facts

Likely explanation (OAuth delegation pattern): OAuth revocation is primarily a signal to the identity provider to invalidate the upstream grant or token. Unless the relying party checks token revocation or introspection on every request, or consumes provider notifications, the upstream revocation does not automatically push an invalidation event into the relying party's own session store. Gitter's session is a separate credential with its own lifetime.

Confirmed facts: This answer is based on general OAuth 2.0 behavior and the stated assumption that Gitter issues its own session token after login. It is not a confirmed audit of Gitter's current implementation. Gitter's session lifetime, cookie flags, and any sign-out-everywhere feature may have changed and require verification.

Steps to shorten the session independently

1. Sign out of Gitter in the browser. This should invalidate the Gitter-issued session token and clear the session cookie.
2. If no sign-out control is available or the session persists, clear cookies and site data for the Gitter domain in your browser settings.
3. Check Gitter's account settings for a session-management or sign-out-all control, and use it if present.
4. Verify by opening Gitter in a private/incognito window or a clean browser profile to confirm no logged-in state is restored.

Reducing scopes without re-authorization

Scopes are bound to the original authorization grant. There is no standard OAuth mechanism to narrow scopes on an existing grant. To reduce permissions, revoke Gitter's access at the identity provider and complete a new OAuth authorization with the narrower scope set. Some providers offer a re-consent screen that may allow scope changes without full revocation, but this is provider-specific and not guaranteed.

One diagnostic detail that changes the recommendation

Does Gitter validate the upstream token on every request, or only at login? If Gitter performs per-request validation with revocation checks, upstream revocation could produce faster session termination than the login-only pattern described above. This single detail determines whether the session should end immediately or only after the Gitter token expires.

Practical verification

Because Gitter's current session behavior is not confirmed here, test in a clean browser profile: sign in to Gitter, revoke Gitter's access at GitHub or GitLab, then reload Gitter without clearing cookies. Inspect the Gitter session cookie in developer tools for its expiry timestamp and compare it with the revocation time. Repeat separately for GitHub and GitLab, and record whether Gitter actions fail immediately or only after the Gitter session expires.