ContextGitter delegates primary authentication to external OAuth2 providers such as GitHub and GitLab, then maintains its own session via internal cookies. The documented 'Connect' workflow lets one Gitter account link multiple identity providers, and access control is based on channel visibility (public vs. private) rather than granular per-message roles.The constraintFor a team running private Gitter rooms, I need a least-privilege posture: when a member leaves or a token is compromised, access should end promptly. The uncertainty is that Gitter's internal session cookie appears to remain valid even after the OAuth token is revoked at the provider, until some re-authentication trigger fires. That creates a gap between 'revoked at GitHub' and 'actually locked out of Gitter'.The trade-offOption A: rely on provider-side revocation (removing Gitter from GitHub's Authorized OAuth Apps) and accept whatever session persistence Gitter applies. Option B: treat Gitter's own session as authoritative and manage offboarding through room membership changes instead, accepting that the OAuth layer is not a reliable kill switch.QuestionsWhich documented mechanism actually terminates an active Gitter session fastest: provider token revocation or removing the user from private rooms?What event forces Gitter to re-check the external provider token, and is that interval configurable or documented?Does the multi-provider Connect workflow change revocation behavior if only one linked identity is revoked?

Direct AnswerRemoving a user from a private Gitter room is the only immediate, administrator-controlled way to cut off their access to that room. Revoking the OAuth grant at GitHub or GitLab prevents future logins but does not invalidate the user's existing Gitter session cookie, which typically remains valid for ~30 days.Why Provider Revocation Is Not a Kill SwitchGitter's architecture treats the external OAuth flow as a one-time identity proof. After successful authentication with GitHub or GitLab, Gitter issues its own session cookie. That cookie is self-contained: Gitter does not periodically re-validate the upstream access token, and no documented setting or API forces such a re-check. The session persists until the cookie expires, the user logs out manually, or the browser clears cookies.What Actually WorksRemove the user from each private room. This takes effect immediately for messages, presence, and history in those rooms. The user retains a valid Gitter session and can still access public rooms and any other private rooms where they remain a member.Revoke the OAuth grant at the provider (GitHub: Settings → Applications → Authorized OAuth Apps → Revoke; GitLab: User Settings → Applications → Revoke). This blocks new logins via that provider but leaves the current session intact.If the user linked multiple providers via Gitter's Connect workflow, revoking only one provider's token blocks login through that provider alone. The Gitter session and any other linked providers remain functional.No Forced Re-authentication Mechanism ExistsGitter's API does not expose a "revoke all sessions" or "force re-authentication" endpoint for room owners or admins. Session termination is exclusively user-initiated (logout) or time-based (cookie expiry). There is no configurable re-check interval.Recommended Offboarding ChecklistRemove the member from every private room they should lose access to.Revoke the OAuth grant at each linked provider to prevent future logins.Ask the departing member to log out of Gitter (or wait for cookie expiry).Verification GapGitter's public documentation does not explicitly describe session persistence after provider revocation. The behavior above is inferred from OAuth2 architecture and community observation. If you need absolute certainty for compliance purposes, run a controlled test: create a test account, join a private room, revoke the OAuth grant at the provider, and observe whether the session remains active in the browser.

Gitter OAuth Revocation vs Room Membership for Offboarding

1 answer

Tasadduq BurneyownerOwner · Founder

32275 reputation · 30 Mar 2025, 18:36 UTC

Permalink

Direct Answer

Removing a user from a private Gitter room is the only immediate, administrator-controlled way to cut off their access to that room. Revoking the OAuth grant at GitHub or GitLab prevents future logins but does not invalidate the user's existing Gitter session cookie, which typically remains valid for ~30 days.

Why Provider Revocation Is Not a Kill Switch

Gitter's architecture treats the external OAuth flow as a one-time identity proof. After successful authentication with GitHub or GitLab, Gitter issues its own session cookie. That cookie is self-contained: Gitter does not periodically re-validate the upstream access token, and no documented setting or API forces such a re-check. The session persists until the cookie expires, the user logs out manually, or the browser clears cookies.

What Actually Works

Remove the user from each private room. This takes effect immediately for messages, presence, and history in those rooms. The user retains a valid Gitter session and can still access public rooms and any other private rooms where they remain a member.
Revoke the OAuth grant at the provider (GitHub: Settings → Applications → Authorized OAuth Apps → Revoke; GitLab: User Settings → Applications → Revoke). This blocks new logins via that provider but leaves the current session intact.
If the user linked multiple providers via Gitter's Connect workflow, revoking only one provider's token blocks login through that provider alone. The Gitter session and any other linked providers remain functional.

No Forced Re-authentication Mechanism Exists

Gitter's API does not expose a "revoke all sessions" or "force re-authentication" endpoint for room owners or admins. Session termination is exclusively user-initiated (logout) or time-based (cookie expiry). There is no configurable re-check interval.

Recommended Offboarding Checklist

Remove the member from every private room they should lose access to.
Revoke the OAuth grant at each linked provider to prevent future logins.
Ask the departing member to log out of Gitter (or wait for cookie expiry).

Verification Gap

Gitter's public documentation does not explicitly describe session persistence after provider revocation. The behavior above is inferred from OAuth2 architecture and community observation. If you need absolute certainty for compliance purposes, run a controlled test: create a test account, join a private room, revoke the OAuth grant at the provider, and observe whether the session remains active in the browser.

Your perspective belongs here.

Join the conversation

Gitter OAuth sessions: revoke at the provider or force re-authentication in Gitter

Context

The constraint

The trade-off

Questions