Session revocation explained: Protect your users, systems, and AI agents

Modern applications are expected to deliver seamless authentication experiences. Users can log in across devices, stay signed in for weeks, and enjoy instant access to their accounts. But with that convenience comes a hidden risk: old or compromised sessions that remain valid long after they should have expired.

That’s where session revocation comes in. It’s the mechanism that lets you invalidate existing sessions, instantly and securely, across all devices. Whether you’re handling a “Sign out everywhere” feature or mitigating a security incident, session revocation gives you control and your users peace of mind.

What is session revocation?

A session represents a user’s authenticated state; it’s what allows requests to your API to prove “this user is logged in.” Sessions often live in cookies, access tokens, or server-side stores. By default, they expire after a set duration or a period of inactivity.

Session revocation means cutting that session short. Instead of waiting for it to expire naturally, your backend proactively marks it as invalid. Any subsequent request using that session token fails authentication, forcing the user to log in again.

In other words, it’s the difference between saying “this session will die in 12 hours” and “this session dies now.”

Why session revocation matters

Most apps handle sign-out locally, clearing a cookie or deleting a token on one device.

But what about all the other sessions a user might have open? Without centralized session management, those stay active indefinitely.

Here are a few common scenarios where session revocation isn’t just nice to have, it’s essential.

1. Lost or stolen device

If a user loses their phone or laptop, the sessions on that device remain active. Without revocation, whoever finds the device can continue to use it as if they were logged in.

2. Password reset or credential breach

When a user resets their password (especially after a security incident) it’s critical to revoke all existing sessions immediately. Otherwise, an attacker with a valid token could remain authenticated even after the credentials change.

3. Employee offboarding and role changes

In enterprise environments, user access must be tightly controlled. When someone leaves a company or changes roles, you should be able to revoke all active sessions to prevent lingering access to sensitive data.

4. “Sign Out Everywhere”: A small feature with big impact

Users have come to expect the ability to review their active sessions and log out of them remotely. Think: Netflix’s “sign out of all devices” feature. This builds trust and transparency, and it’s easy to offer with the right infrastructure.

If your app supports multiple devices, users expect to see where they’re signed in and to be able to log out remotely. It’s a feature most people take for granted, until they need it.

If you’ve ever logged into Netflix on a hotel or Airbnb TV while traveling, you’ve probably had that “oh no” moment days later, realizing you never logged out. Netflix’s Sign Out of All Devices button is a quiet lifesaver: one click, and all those sessions vanish instantly.

That same capability, the ability to revoke sessions across environments, is what modern users expect from any app that takes security and privacy seriously.

5. Risk-based session management

If your security system detects suspicious activity (for example, a login from an unfamiliar location) you can immediately revoke all or selected sessions as a protective measure.

Why your app needs session revocation

Beyond security hygiene, session revocation unlocks a set of capabilities that make your app more professional and enterprise ready:

• Security: Prevent unauthorized access from stale or compromised sessions.
• Compliance: Many enterprise customers require centralized session control and auditability.
• User experience: Give users confidence that their accounts are protected and manageable.
• Operational control: Support complex workflows like forced logout, device-specific sign-out, and admin-driven revocation.

In short: without session revocation, your app is leaving the door open, sometimes literally.

Beyond users: Session revocation for AI agents

Session revocation isn’t just for human users anymore. As more apps integrate AI agents that act on behalf of users (booking meetings, fetching data, or generating content) those agents need their own authenticated sessions.

If a user disables the agent, changes permissions, or disconnects an integration, your system must be able to revoke that agent’s session instantly.

This ensures that the agent can’t continue performing actions or accessing resources beyond what the user intends.

With WorkOS, these sessions are managed just like human ones, meaning you can revoke an AI agent’s session, audit its access, and maintain full visibility into authentication events.

How WorkOS makes session revocation simple

Building session revocation from scratch is tricky. You have to track all sessions per user, check validity on every request, synchronize between devices, and handle edge cases gracefully.

WorkOS handles all of that for you.

WorkOS Sessions API

With the WorkOS Sessions API, you can easily:

• List all active sessions for a user, complete with user agent, IP address, and last-updated metadata.
• Revoke individual sessions with a single API call.
• Implement “Sign Out Everywhere" across devices:
  
  • List all active sessions for the user.
  • Revoke each session by ID.
  • Clear the local session on the device that initiated the sign-out.
  • Handle invalid sessions gracefully on other devices: when they next make an API request, WorkOS will reject the revoked session, and your app should clear local state and redirect to login. Alternatively, you can use the session.revoked event that WorkOS emits whenever a user session is revoked in order to notify other devices (using the Events API or webhooks).

Here’s what a flow like that looks like in Node.js:

	
import { WorkOS } from '@workos-inc/node';

const workos = new WorkOS('WORKOS_API_KEY');

async function signOutEverywhere(userId, localClearFn) {
  // 1. Get all active sessions for this user
  const sessions = await workos.userManagement.listSessions(userId);

  // 2. Revoke each session by ID
  for (const session of sessions.data) {
    await workos.userManagement.revokeSession({
      sessionId: session.id,
    });
    console.log(`Revoked session ${session.id} (${session.metadata.user_agent}, ${session.metadata.ip_address})`);
  }

  // 3. Clear the local session on the initiating device
  localClearFn();
}
	

With this flow:

1. You fetch all active sessions using listSessions.
2. You iterate over the session IDs and call revokeSession on each one.
3. You clear the local session with localClearFn.

On other devices, when a revoked session tries to call your API, it will fail with an “invalid session” error. At that point, you should:

• Remove any local session tokens or cookies.
• Redirect the user back to your login page.

The result is a true “sign out everywhere” implementation that ensures no device or session remains valid.

This pattern ensures that after a password reset (or when a user clicks “sign out everywhere”), all of their active sessions across devices are terminated.

Self-service session management

WorkOS also provides a pre-built <UserSessions /> widget, which lets users view and manage their active sessions directly in your app. Each session displays key information (device, browser, IP), and users can click “Sign out” to revoke it instantly.

Example:

	
import { UserSessions, WorkOsWidgets } from '@workos-inc/widgets';

/**
 * @param {string} authToken - A widget token that was fetched in your backend. See the
 * "Tokens" section of this guide for details on how to generate the token
 * @param {string} currentSessionId - The ID of the current session
 */
export function SessionsPage({ authToken, currentSessionId }) {
  return (
    <WorkOsWidgets>
      <UserSessions authToken={authToken} currentSessionId={currentSessionId} />
    </WorkOsWidgets>
  );
}
	

This user-facing transparency doesn’t just improve security, it builds trust.

Enterprise-grade controls

WorkOS goes beyond revocation itself. You can configure:

• Session lifetimes and inactivity timeouts
• Revocation triggers on password reset or SSO deactivation
• Audit logs for security and compliance reviews

All without maintaining your own complex session store or revocation lists.

Best practices for session revocation

If you’re implementing or extending session management, here are a few best practices to keep in mind:

1. Always verify session status on each request. Don’t just rely on token expiration, check whether the session has been revoked.
2. Log all revocation events. You’ll need this for compliance audits and security analysis. WorkOS logs (and can emit) a session.revoked event whenever a user session is revoked.
3. Handle revocation gracefully. When a session becomes invalid, redirect users to sign-in with a clear message.
4. Offer user visibility. Let users see all active sessions and sign out of them; it increases both trust and security.
5. Coordinate with password resets and SSO events. Ensure that these flows automatically revoke old sessions.
6. Test with offline devices. Remember that a revoked session only takes effect once the device reconnects.

A security feature your users will actually notice

Session revocation is one of those invisible features that makes an app feel trustworthy. When users can sign out everywhere, revoke suspicious sessions, or trust that old tokens are gone, they feel safe, and that matters.

And when enterprise customers see that your authentication system supports these capabilities out of the box, it becomes a selling point.

With WorkOS, you don’t have to reinvent it. The Sessions API and AuthKit handle the heavy lifting, so you can deliver “Sign Out Everywhere” and enterprise-grade session management in minutes.

Read more

• Sign Out Everywhere with the WorkOS Sessions API
• WorkOS Sessions API: Session Revocation and Sign Out Everywhere
• AuthKit Sessions Documentation
• UserSessions Widget Guide