Sessions

See who is signed in to your organization right now and force them out when needed.

The Active Sessions page lives at /admin/sessions and requires the canRevokeSessions permission.

What the page shows

The page groups active sessions by user — one row per person, not one row per device. Each row shows that user's most recent session, with a small indicator when they're signed in on more than one device. Columns:

• User — display name and email. Your own row is tagged with a "You" pill. When the user has more than one active session, a +N indicator sits next to their name; hover it to see every device in a small popover. The Device cell also shows a +N more hint.
• Device — parsed from the User-Agent header, formatted like Chrome on Mac or Safari on iOS. Unknown device if the session predates User-Agent capture.
• Location — geo-IP resolved location, e.g. San Francisco, California, United States. Falls back to the raw IP, then Unknown, for private IPs or when the lookup has not completed yet.
• Last seen — Active now (green) for any session whose last activity is within the last 45 seconds; otherwise a relative timestamp. The server throttles the activity touch to roughly once every 20 seconds, so 45 seconds catches actively-clicking users without false positives for idle ones.

A toolbar at the top has a search box (filters by name, email, or location as you type) and a sort control (most recent, oldest, most sessions, or name A–Z / Z–A). A counter shows the total session and user counts.

Note

A user counts as Active now if any of their sessions has been touched in the last 45 seconds. Freshness uses the most recent of the session's page-load activity and its chat/agent activity, so a session that's mid-conversation but hasn't reloaded the page still reads as active.

Session details

Open the row's ⋯ menu and choose View details to open a per-user modal listing every active session for that person. Each session shows:

• Device and location
• Active now or a relative "last seen" label
• Created and Expires timestamps
• The full User-Agent string
• A per-session Sign out button

The per-session Sign out button revokes just that one token — so you can kick a single suspicious device without logging the user out everywhere. It flows through POST /api/admin/sessions/by-token/revoke, which first verifies the session belongs to a user in your organization (defense against IDOR via guessed tokens).

Signing a user out

The ⋯ menu's second item is the destructive sign-out. Its label and behavior depend on the row:

• Another user with one session — reads Sign out. Signs them out on that device.
• Another user with multiple sessions — reads Sign out all N sessions. Logs them out on every device at once.
• Your own row — reads Sign me out everywhere. Strata signs you out on every device and redirects to /.

This menu action revokes all of the target user's tokens in one shot, via POST /api/admin/sessions/:userId/revoke. The server enforces an IDOR guard: an admin in one organization cannot revoke a user in another by guessing their user ID. Self-sign-out is allowed since the caller is the target.

To revoke a single device instead of all of them, use the per-session Sign out button inside View details (above).

Every revoke is audited as session.revoked — with { byToken: true } for a single-token revoke, or { count: N } for an all-devices revoke.

Revoking every session for one user

The per-user bulk path is also available from the user-manage modal, not just the Sessions page. To force a single user out across all their devices from there:

1. Open /admin/users.
2. Click Manage on the user's row.
3. In the Profile & Access tab, click Force sign out (all devices).

This wipes every session token tied to that user and audits it as session.revoked with { count: N }.

Revoking every session in the organization

For a suspected breach, use the org-wide nuke. There is intentionally no button on the Sessions page UI — use the API or have an operator run it:

POST /api/admin/org/revoke-all-sessions
{ "reason": "Suspected credential leak — June 24" }

Requires canRevokeSessions. You will be signed out too; re-authenticate the same way every other member does. The audit entry is org.sessions_revoked_all with the count and reason. The reason is optional — manual is recorded when omitted.

How quickly does a revoke take effect

Strata caches sessions in memory for fast validation and also persists them in the platform database. Both layers are consulted on every request:

• Memory: cleared on the next request from the affected user.
• Database: marked revoked immediately.

There is no observable "lag" — once a request comes in after the revoke, the session is rejected.

What can go wrong

See Users for the per-user Force sign out (all devices) button, and Audit log for the trail of revoke actions.

Related

• Users
• Roles and permissions
• Audit log