Managing OAuth Authorized Sessions and User Consent

Helpdocs Admin Updated by Helpdocs Admin

Once consent has been granted and OAuth is in active use, you'll need visibility into what's connected and the ability to step in when access needs to change. This article covers where authorized sessions and consent grants can be viewed and managed, and what actions are available at each level.

Authorized sessions

Master admins get the most powerful view: a tenant-wide list of authorized sessions, with filtering and faceting — by target type (system-wide, agent, contact) or by application. Selecting a filter drills the facets down further — for example, filtering by "agent" then facets the remaining results by individual agent. This makes it much easier to understand usage patterns as more people begin authorizing apps, without having to hunt through data manually.

Sessions can also be reached from a more targeted starting point: navigating to a specific agent or contact record also surfaces their authorized sessions there. This gives an admin or master admin a fast way to check "what does this specific person have connected" without needing to learn the filtering UI at the tenant-wide view — useful when you already know who you're investigating and just need a quick answer.

Revoking a session: If a session has an active refresh token, an admin or master admin can revoke it directly. A user can also revoke their own sessions, from their own Connected Apps page (see Personal Secrets Explained for how to get there).

Note: the tenant-wide filtering/faceting view is only available to master admins. Agent- and contact-level pages, and the consent grant pages below, still support filtering, but not faceted drill-down — the facet view exists because it's the only place aggregating data across the entire tenant.

Consent grants can be viewed and managed from more places than sessions: the client portal settings page, the TECH portal settings page, or an individual account's settings page — as well as at the individual agent or contact level, same as sessions.

Revoking a consent grant removes it entirely. Any agent or contact — as well as an admin or master admin — can revoke their own consent grant (or, for an admin, someone else's) at any time. This has little to no security downside, since it's simply withdrawing access; if the person still needs it, they'd just need to grant consent again.

Reducing a consent grant removes specific scopes from it, rather than the whole grant:

  • Reducing a personal grant affects that individual only. Any session relying on the removed scope will fail the next time it tries to renew or use it.
  • Reducing a root-level grant affects every contact or agent under that root, for any of them whose individual grant didn't already cover the scope independently. If someone's personal grant separately covers a scope that was just removed at the root level, they're unaffected.

Removing a scope is a full removal, not a downgrade. For example, removing account:read_write doesn't fall back to account:read — it's simply gone. If read-only access is still wanted after removing a broader scope, it has to be granted again separately.

Like revoking, reducing a grant can be done by the person themselves, or by an admin/master admin on someone else's grant — both carry little to no security risk, since it only removes access, never adds it.

Ordinary consent — a user approving access for themselves — happens through the standard authorization endpoint, as covered in Code Authorization Flow.

Admins and master admins can also grant consent on someone's behalf, or at the root level (covering all contacts, all agents, or all contacts under a given account). This is done by:

  • Selecting a target — root level, system-wide, or a specific user (if user, selecting exactly who).
  • Selecting the application.
  • Selecting which scopes to grant.
  • Clicking Grant, which leads to an admin-grant confirmation page — functionally similar to the standard authorize page, and backed by the same security mechanism.

Once granted, an audit log entry records who granted it and which scopes were included.

Root-level consent is covered in more detail in Admin Consent at Root Level — in short, it's a way for an admin or master admin to grant consent on behalf of all contacts or agents at once, rather than one at a time. A common case: if an individual's personal consent has been revoked but the organization still wants everyone to be able to use a given tool — for example, an MCP connector used to access an AI model — granting the required scopes at the root level covers everyone at once, instead of asking each person to grant it individually.

What's next

See Admin Consent at Root Level for how root-level grants interact with personal grants in more detail.

How did we do?

Configuring OAuth Settings in Tokity

Granting OAuth Admin Consent at the Root Level

Contact