Five Reasons Why Your Auth0 Permissions Are Not in your Access Token

Summary

Auth0 access tokens can lack a permissions claim despite apparently configured RBAC, and the post identifies five silent causes. The authorization request may omit the API audience, the API’s “Add Permissions in the Access Token” setting may be disabled, or a permission-bearing role may not be assigned to the user, including at the relevant organization level. Developers may also be decoding an ID token rather than the API access token, whose aud identifies the API. Client Credentials tokens represent applications rather than users and typically carry granted scopes instead of a permissions array. For custom Post-Login claims, the post advises using a namespaced claim rather than colliding with Auth0’s reserved permissions claim.

Takeaways

1. 1

   An authorization request without an audience produces an opaque token; the audience must exactly match the Auth0 API Identifier, including any trailing slash.

2. 2

   Client Credentials tokens represent applications, so M2M authorization uses API-granted scopes and a scope claim rather than user roles and a permissions array.

3. 3

   Permissions added through a Post-Login Action should use an application-specific namespaced claim instead of Auth0’s reserved permissions claim.