Manage and Revoke Sessions with BTST Better Auth UI

An account security page should let a user inspect active sessions and end access from another browser. BTST Better Auth UI includes that interface, but the session store and server authorization determine whether a revoked browser can still read protected data.

This guide targets @btst/better-auth-ui@2.0.0 with Better Auth 1.6.16 and an existing database-backed integration. Stateless deployments have different revocation limits and need a separate design. Start with the auth integration guide if the account routes or provider are not mounted yet.

Use the existing account security page#

With the account plugin enabled and a /p site mount, open /p/account/security. The released security settings view includes a sessions card. You do not need to enable the multi-session plugin just to list a user's browser sessions; multi-session account switching is a separate feature.

The sessions card reads through useListSessions. Its session row distinguishes the current session from other sessions. Revoking another row calls the configured mutator and refetches the list. Acting on the current row navigates through sign-out.

Keep the shared authClient, session-change callback, and authorization adapter connected. A custom hook or mutator replaces part of this behavior, so it must preserve the same user scope, error handling, and refresh behavior. Do not replace a failed request with an optimistic success message.

Choose the operation that matches the label#

For a custom “Sign out other browsers” action, call the existing client and keep failure visible to the caller:

import { authClient } from "@/lib/auth-client";

export async function signOutOtherBrowsers() {
  const { error } = await authClient.revokeOtherSessions();
  if (error) throw new Error(error.message);
}

Call this from an authenticated client-side action. Show pending and error states, and refetch your sessions list after it succeeds. Do not label it “sign out everywhere,” because it intentionally retains the current browser. The Better Auth session API documentation describes these operations.

Session tokens are credentials. The built-in selected-session action passes a token to the auth endpoint; do not put that token into a URL, event property, screenshot, or support log. Device labels and IP addresses are descriptive hints, not reliable proof of a person's identity.

Account for session caches#

If session.cookieCache is enabled, a valid cached session can temporarily outlive deletion of the server-side session. Revocation should therefore be tested against your application's actual cache configuration. Do not promise immediate lockout based only on the row disappearing from the sessions card.

For a sensitive server operation that needs a fresh session-store check, Better Auth supports bypassing the cookie cache:

import { auth } from "@/lib/auth";

export async function currentSessionForSensitiveRequest(request: Request) {
  return auth.api.getSession({
    headers: request.headers,
    query: { disableCookieCache: true },
  });
}

Run this on the server. Reject a missing session before reading or changing protected data, then enforce the operation's resource permissions. This call does not replace authorization, invalidate another browser's cookie by itself, or turn a stateless deployment into a server-backed session store. Keep the app's existing authorization boundary and use a fresh session check within it where the required revocation behavior warrants one.

Keep password change and recovery policies explicit#

The released companion's change-password card passes revokeOtherSessions: true, retaining the current session while ending others. Password recovery uses a different server option: emailAndPassword.revokeSessionsOnPasswordReset. The password-reset guide configures that option explicitly. Do not assume enabling one policy also configures the other.

Verify with two independent browsers#

Sign the same controlled account into two separate browser profiles. Two tabs sharing cookies do not establish two independent sessions. On browser A, verify that the account security page lists both sessions, then revoke browser B.

In browser B, request a protected server resource. Check both the normal request path and the sensitive path that bypasses cookie caching, if your app uses one. Record the expected cache lifetime before deciding whether a delayed rejection is a bug. Browser A should remain signed in after an “other browsers” action.

Finally, sign out A and request protected data again. Confirm that backend responses reject missing sessions even if a client page still displays cached content. Repeat with a separate user to verify that one account cannot manage another's sessions.

Use the BTST account/provider documentation to connect the UI and the route permissions guide for the server-boundary principle. A rendered security page is the starting point; verified denial of the revoked session's protected request is the result to check.