Wildcard permissions in JWTs: when to use them, when to refactor

Wildcards (*:*, admin:*) feel efficient and become security smells. Here's how to evaluate them and the patterns that replace them.

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

Most common wildcard: *:* (all resources, all actions)
Resource wildcard: billing:*
Action wildcard: *:read (rare, less risky)
Better alternative: Named role + explicit permission set

Wildcard permissions (`*:*`, `admin:*`, `billing:*`) are the most common multi-tenant JWT smell in production. They start innocent — "the founder needs to do everything, just give them `*:*`" — and accumulate. Five years later, fifty employees hold `*:*` across thirty tenants. Here's how to evaluate them and what to replace them with.

Why wildcards accumulate

Granting a wildcard is a one-line change. Auditing every user with a wildcard requires knowing who has them, why, and whether they still need them. The asymmetry — easy to grant, hard to audit — is what produces the accumulation.

The pattern that prevents this is to grant roles, not raw permissions. Roles (`owner`, `admin`, `billing-only`, `read-only`) are a finite set. Auditing "who has the owner role" is straightforward; auditing "who has any of these eight wildcard variations" is not.

Frequently asked questions

Are all wildcards bad?expand_more

Not all — but they should be deliberate. `*:read` (read everything) is much less risky than `*:*` (do everything). The danger is *write* wildcards held by humans whose role no longer requires them. Audit wildcards quarterly; flag any holder whose responsibilities have changed.

How do I refactor a wildcard?expand_more

Find every place the codebase checks for the wildcard. Define a named role (e.g. `role: "owner"`) that matches the intent. Replace `permissions.includes("*:*")` checks with `role === "owner"` checks. Migrate users one by one. The role makes intent explicit; the permission check becomes self-documenting.

Should the analyzer flag every wildcard?expand_more

Yes — for review, not as automatic remediation. The analyzer flags wildcards as a Warning finding with the explicit guidance to audit. Most flagged wildcards will be intentional; some will be the legacy you've been meaning to clean up.

Resource:action strings, OAuth scopes, bitmasks — which permission encoding to use in a multi-tenant JWT, and the trade-offs of each.

tenant_id vs sub: where to put tenant context in a JWT

Why conflating tenant identity with user identity in the sub claim is a multi-tenant anti-pattern, and the conventions that work instead.