WorkOS JWT Debugger

Decode WorkOS AuthKit session tokens with organization context, roles, and permissions.

shield

Private: Decoding, analysis, signature verification, and token generation all run in your browser. Nothing is sent to any server, except a JWKS URL you explicitly enter and click Verify on.

At a glance

Active org claim
org_id
Role claim
role
Permissions claim
permissions (string array)
Session id claim
sid
SSO connection claim
connection_id (when SSO is used)
Default algorithm
RS256

WorkOS AuthKit issues B2B-shaped session tokens: every authenticated session belongs to an organization, with a role and a permissions array scoped to that org. This debugger surfaces those claims separately from generic JWT fields, decodes the standard registered claims, and warns on patterns that bite multi-tenant apps in production.

WorkOS AuthKit JWT structure

A WorkOS session JWT contains the active `org_id`, the `role` (a free-form string defined in the WorkOS dashboard), the `permissions` array (the role's flattened scopes), and a `sid` (session id). The standard registered claims — `iss`, `sub`, `aud`, `exp`, `iat`, `jti` — are all populated.

For SSO-originated sessions, you'll also see `connection_id` (the SAML/OIDC connection) and sometimes `directory_id` (the SCIM directory). These are diagnostic — useful for confirming a session came from the expected identity provider when debugging access issues.

B2B patterns this tool checks

Wildcard permissions: WorkOS lets you define wildcard permissions on roles. They're convenient but accumulate risk over time. The analyzer flags wildcards in `permissions` so you can audit whether they're still justified.

Long token lifetime: B2B access tokens typically have short lifetimes (10–60 minutes) backed by refresh tokens. If the gap between `iat` and `exp` exceeds 24 hours, the analyzer warns — that's a long window for a stolen token to be useful.

Missing aud: WorkOS sets `aud` by default but custom JWT templates may not. If `aud` is absent, downstream APIs can't reject tokens issued for a different consumer — the analyzer notes that as a warning.

Frequently asked questions

Does a WorkOS token include all organization memberships?expand_more
No — only the active organization. The session JWT has a single `org_id`, `role`, and `permissions` set, scoped to whichever org the user authenticated into. To list all memberships, call the WorkOS API server-side (`organizationMemberships.list`).
How does WorkOS handle role-based permissions?expand_more
When you define roles and assign permissions in the WorkOS dashboard, the user's scoped permissions for the active org are flattened into the `permissions` claim as a string array. This array is the canonical permission set for the request — server-side authorization checks should reference it directly.
What does `connection_id` mean in a WorkOS JWT?expand_more
`connection_id` is the WorkOS identifier for the SSO connection (SAML, OIDC, etc.) the user authenticated through. Its presence indicates the session originated from SSO rather than a password login. `directory_id` similarly tags the SCIM directory the user came from, when applicable.
Can WorkOS issue JWTs for multiple orgs at once?expand_more
Not in a single session token — WorkOS's model is one active org per session. If a user belongs to multiple orgs, they pick one during login (or AuthKit picks the most recent). To switch orgs, the user signs out of the current session and signs into a different one.

Related guides

Related Tools