Auth0 Multi-Tenant JWT Debugger

Decode Auth0 access and ID tokens with Organizations, namespaced custom claims, and RBAC permissions.

Last updated: May 2026

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.

Paste your JWT

At a glance

Active org claim: org_id
Org name claim: org_name
RBAC permissions claim: permissions
Custom claim namespace: https://yourapp.com/...
Authorized party claim: azp
Default algorithm: RS256

Auth0 multi-tenant tokens differ from a generic JWT in three important ways: organizations live in `org_id` / `org_name`, custom claims must be namespaced URIs (e.g. `https://yourapp.com/roles`), and RBAC permissions appear in the top-level `permissions` array. This debugger lays them out separately so you can see at a glance whether the token has the org context and permissions you expect.

Auth0 namespaced custom claim convention

Auth0 enforces a strict rule on access tokens: any custom claim must be a URI under a namespace you control. Trying to add `roles` directly does nothing — it's silently dropped. Instead use `https://yourapp.com/roles` (or any URL you own).

This is enforced in Auth0 Actions/Rules. The recommended pattern is to define a single namespace constant (`const NAMESPACE = "https://yourapp.com/"`) and prefix all custom claims with it. The debugger's Custom claims panel shows the full namespaced key, so you can verify the namespace is consistent.

Organizations + RBAC together

When a user authenticates into an organization with RBAC enabled, the access token carries both `org_id` and `permissions`. The permissions are scoped to that organization's membership — so the same user authenticating into a different org may have a different `permissions` array.

This is a place where authorization bugs hide. Make sure your server-side check is "user has permission X *in this org*" not just "user has permission X". Validate `org_id` matches the resource being accessed before consuming `permissions`.

Frequently asked questions

Why are my Auth0 custom claims missing from the JWT?expand_more

Auth0 strips non-namespaced custom claims from access tokens. Custom claims must be URIs you control (e.g., `https://myapp.com/roles`). Add them via an Action or Rule in the Auth0 dashboard, and use the namespaced key both when setting and when reading.

How do Auth0 Organizations work in a JWT?expand_more

Organizations is an Auth0 feature where users can belong to one or more orgs and authenticate into a specific one. The active org appears in the token as `org_id` (and `org_name`). To see all of a user's memberships, call the Auth0 Management API server-side.

Where do RBAC permissions appear?expand_more

When RBAC is enabled on your API and "Add Permissions in the Access Token" is on, Auth0 puts the user's allowed permissions in the top-level `permissions` array. This is the canonical claim — your API's authorization middleware should check it directly.

Can I use this for Auth0 ID tokens too?expand_more

Yes. ID tokens use the same JWT structure; they just don't carry an `aud` matching your API. The analyzer doesn't distinguish between access and ID tokens — paste either and the structural breakdown is the same.