Revoke access

To stop one app or AI agent from acting for a user, revoke it on the user's Connected apps tab. To cut a user off from everything, use Sign out everywhere. To let users revoke apps and end sessions themselves, inside your product, use the User API.

Revoking ends a grant: the refresh token and every access token issued from the same sign-in. The app can't refresh from that moment. Whether the access token it already holds stops working at once depends on how your server checks tokens.

Revoke one app

Open the user in Users, then the Connected apps tab. It lists every app that can still act for the user, with its resource server, scopes and when it last got a token. Revoke revokes the app's refresh and access tokens for that user and deletes the remembered consent, so the user has to approve the app again to keep using it.

Servers that introspect refuse the app on its next call. Servers that check tokens locally accept the access token it holds until it expires; the confirmation dialog says when.

Revoking an app doesn't end the user's browser sessions. If they are still signed in, reconnecting skips the sign-in and goes straight to consent.

The MCP server has the same list and revoke as the list_connected_apps and revoke_connected_app tools.

Let users do it themselves

Your product can show users their own connected apps and browser sessions, and let them revoke an app or sign out of a browser, with the User API. Your app calls it with the user's own access token:

• GET /me/v1/connected-apps and DELETE /me/v1/connected-apps/{id} list the user's connected apps and revoke one, as Revoke on the Connected apps tab does.
• GET /me/v1/sessions and DELETE /me/v1/sessions/{id} list the user's browser sessions and end one, as the Sessions tab does.

Ending a session doesn't revoke an app, and revoking an app doesn't end a session. There is no self-service Sign out everywhere; your app can end each session and revoke each app.

Sign out everywhere

For a lost laptop or a compromised account, Sign out everywhere on the user's Overview tab ends every browser session of the user and revokes every connected app. Tick Also suspend this user to stop them from signing in again.

The same action is available as:

• POST /api/v1/users/{id}/sign-out-everywhere in the Application API, with the users:write scope and an optional {"suspend": true} body
• the sign_out_user_everywhere tool in the MCP server

Revoking a single session on the Sessions tab signs the user out of that browser only; their connected apps keep their access.

Suspend or deactivate a user

Setting a user's status to suspended or inactive signs them out everywhere, from any surface: the dashboard, the Application API, the MCP server and SCIM deprovisioning. Their apps can no longer refresh, and introspection answers active: false for their tokens.

Setting the status back to active restores nothing. The user signs in again, and approves each app again.

Check tokens locally or with Authalla

Access tokens are signed JWTs, so a server can check them in two ways:

Introspect when a revoke has to stop an agent now, as for an MCP server whose tools act for the user. Check locally when a few minutes of delay is acceptable and you want no call per request. With local checks, a shorter access token lifetime shortens the delay, down to 60 seconds, at the cost of more refreshes (Tenants → (select tenant) → General → Token lifetimes).

Whichever you choose, check aud and scope: introspection's active: true says only that the token is live, not that it was issued for your server.

• To check locally, follow the JWT validation guidelines.
• To introspect, see Token introspection for the request, and Check each call with Authalla for an MCP server that does it.

Let an app end its own grant

An app can revoke its own tokens at /oauth2/revoke (RFC 7009), for example when the user signs out of your app. Revoking either the refresh token or an access token ends the whole grant; the remembered consent stays. See Token revocation for the request.

Don't rely on AI agents doing this. The MCP authorization specification doesn't ask clients to revoke their tokens, so disconnecting an agent on the agent's side may leave its grant alive. Revoke it from Connected apps instead.

What the activity log records

Each of these appears in the user's activity and on the tenant dashboard:

• Token revoked: an app revoked a grant at /oauth2/revoke
• Signed out everywhere: an admin or an API call signed the user out everywhere, with whether they were also suspended. Changing a user's status doesn't add this entry
• Connected app revoked: the user revoked an app through the User API, with the app they did it from
• Session ended: the user ended one of their browser sessions through the User API, with the app they did it from
• Refresh blocked: an app tried to refresh a token for a user who isn't active