Auth0 Metadata Explained: user_metadata vs app_metadata

Summary

Auth0’s user_metadata and app_metadata define a security boundary: user_metadata is writable by users through the update:current_user_metadata scope, while app_metadata requires privileged scopes available only to confidential clients via the client credentials grant. Post-login Actions reading authorization data like subscription plans or feature flags from user_metadata allow users to escalate privileges by modifying their own metadata, for example setting plan to enterprise and beta_access to true. Writing to app_metadata demands a server-side M2M application with update:users_app_metadata scope, which no public client or user token can obtain. The correct practice is to store access-control data such as roles, tenant membership, and IP allowlists in app_metadata, and non-sensitive preferences like theme or language in user_metadata. A third field, client_metadata, holds application-level properties readable via event.client.metadata in Actions.

Takeaways

1. 1

   user_metadata can be modified by users via the update:current_user_metadata scope obtained by public clients; app_metadata cannot, as its write scopes (update:users, update:users_app_metadata) require the client credentials grant reserved for confidential clients.

2. 2

   Storing authorization data such as subscription plans, feature flags, or IP allowlists in user_metadata enables privilege escalation because users can update their own metadata without server-side approval.

3. 3

   The correct architecture places access-control data in app_metadata, updated only by server-side M2M applications, and non-sensitive user preferences in user_metadata for user self-service.

FAQ