The syntax needs to be custom.user_field_x, where x is the numeric field ID shown in /admin/config/user-fields/{x}/edit.
That mapping feature is not available in the Auth0 plugin directly.
That said, there are still options to achieve what you’re describing:
- creating a theme component. You can add a small front-end script that automatically syncs a Discourse custom user field with a value already stored in Auth0. For example, when a user logs in and the field is empty, the script can call a secure endpoint (a small cloud function) that fetches the field value from Auth0 and updates the Discourse profile via API.
- using automation tools. You could also use external automation services like Zapier or Make to perform that sync outside of Discourse. The advantage is that you don’t have to write/maintain code but only pay for the third-party service
- custom development. We can extend the Auth0 plugin itself to natively support mapping custom claims into user fields on login, or build a custom plugin that works in pair with the Auth0 plugin.
A clear drawback of the theme component approach is that you’d need to write and maintain custom code yourself, while also being careful from a security standpoint to avoid introducing potential bugs or vulnerabilities. Honestly, it’s not a solution I’d recommend for a production site like yours.
If I were in your position, I’d lean more toward the second option, using third-party tools, or consider submitting a feature request or custom work request (depending on our project managers’ evaluation) to enhance the Auth0 plugin itself.
If you’re interested in exploring the last option, we can continue the discussion privately.