security(membership): withdrawing access in one organization revokes the person's sessions in every organization

[alex-dembele]

Problem

When an administrator of organization A deactivates or revokes a membership, membership.Service.SetStatus (backend/internal/application/membership/members.go, the s.revoker.RevokeAllUserTokens(ctx, m.UserID) call) destroys every refresh-token lineage of that person, including their sessions in organization B.

The person can still sign in to B (#807 made sure of that), so this is not a lockout. But an action in A signs the person out of B, and that effect crosses the tenant boundary. Refresh tokens carry tenant_id (refresh_tokens.tenant_id), so the revocation could be limited to A's lineages.

Acceptance criteria

1. Withdrawing a membership in A revokes only the refresh tokens whose tenant_id is A.
2. A test with one person holding live sessions in A and B: after A withdraws access, the A refresh fails and the B refresh succeeds.
3. Paths that must still revoke everything (password change, account-level security events) keep doing so, and a test covers one of them.

Definition of Done

Criterion 2's test output is pasted on this issue.

Touches session revocation, so per CLAUDE.md it needs a tech-lead review of the approach before implementation.

Found while working #807.

[alex-dembele]

backend — 2026-09-29

Done — PR #846, branch security/831-scope-membership-revocation. New RevokeUserTokensInTenant in internal/auth/token.go. The SessionRevoker port in internal/application/membership/service.go takes the tenant, and SetStatus/ChangeRole in members.go revoke only in the organization that acted. Password change and reset are untouched. Test: internal/handler/membership_session_scope_test.go.
Verified — go test ./internal/handler/ -run TestMembershipSessions_ -v: deactivation, revocation and role change in A → A refresh refused, B refresh OK. An account-level revocation still ends both. With the old revocation (by user_id only), the test fails. Wider suite (handler, auth, application, middleware, cmd) all ok.
Criteria — 1 ✅ · 2 ✅ · 3 ✅
Next — Owner review and merge of #846. That review serves as the tech-lead review the issue asked for; the approach is a scoping fix, not a redesign.
Blocked on — nothing