WPGraphQL JWT Authentication issues JSON Web Tokens to clients that authenticate against the WPGraphQL endpoint. The plugin stores a per-user secret and a revocation flag in wp_usermeta under keys like graphql_jwt_auth_secret and graphql_jwt_auth_secret_revoked, and any refresh-token state and last-login timestamps go through the same user meta layer. The default WordPress users screen has no idea any of this exists, which makes auditing JWT users awkward on busy headless sites.

SleekView reads wp_users together with the JWT-related wp_usermeta keys, so every user becomes a row with their graphql_jwt_auth_secret_revoked state, last-login timestamp, role, and registration date as proper columns. Filter on revoked users, by role, or by last-login age. Sort by recent activity. Inline edit the revocation flag, or rotate the user secret through the plugin's own functions when triaging compromised accounts.

Writes route through WordPress core (update_user_meta) and through WPGraphQL JWT's own helpers where appropriate, so any plugin or hook that listens for revocation or refresh events fires normally. Saved views per role give engineering and support each their own slice of the user table, with the columns and filters that match an incident response or onboarding workflow.

WPGraphQL JWT Authentication is the default way to authenticate clients against a headless WordPress site, and it's quietly load-bearing for serious decoupled stacks. The plugin does the right thing on the auth side: per-user secrets, a revocation flag, and refresh-token support. What it doesn't do, and isn't really expected to do, is give administrators a clean view of who's using JWT, who's idle, and who's been revoked.

The default WordPress users screen has no concept of any of it. Teams end up writing WP-CLI scripts or one-off SQL whenever a token misbehaves. SleekView turns that audit job into a normal admin table.

Revocation flags, last-login timestamps, refresh state, and role are real columns. Bulk operations route through update_user_meta so hooks fire normally. Engineering and support each get a saved view tuned to their workflow, and the admin finally treats JWT users as the first-class objects they already are in the database.