Skip to content

Conversation

vladislavbogomolov
Copy link

  • All new/changed/fixed functionality is covered by tests (or N/A)
  • I have added documentation for all new/changed functionality (or N/A)

📋 Changes

This PR makes the list of ID-token claims extensible via an environment variable:

  • Added support for AUTH0_ID_TOKEN_CLAIMS_CUSTOM – a comma-separated list of additional claim names.
  • Updated the default claim array so that custom entries are appended only when the variable is set, trimming whitespace and ignoring empty items.
  • No breaking changes – if the variable is undefined, behaviour is identical to the current release.

Why is this important?

Projects often need extra user metadata (e.g. role, tier, locale) inside the ID token for quick client-side access. Allowing claims to be configured by env keeps the core codebase clean while giving integrators flexibility.

📎 References

  • Fixes – “Allow custom claims in ID token”
  • Auth0 Community topic: “How do I add app-specific claims without forking?”

🎯 Testing

  1. Unit tests cover:

    • Construction of the claim array with, without, and with malformed AUTH0_ID_TOKEN_CLAIMS_CUSTOM.
    • Deduplication / trimming logic.
  2. Manual (optional):

    # without custom claims
    AUTH0_ID_TOKEN_CLAIMS_CUSTOM="" npm test
    # with custom claims
    AUTH0_ID_TOKEN_CLAIMS_CUSTOM="role, tier , locale" npm test

    Confirm that the resulting token payload contains the base claims plus "role", "tier", and "locale".

No other runtime behaviour is affected.

@vladislavbogomolov vladislavbogomolov requested a review from a team as a code owner June 28, 2025 15:03
@tusharpandey13
Copy link
Contributor

Hi @vladislavbogomolov 👋 Thanks for this and apologies for the late response.
While the business need for customizable ID token claims is valid, we are not sure if we can go ahead with the exact implementation as in this PR.

Ideally, we would go for constructor-based configuration in Auth0Client insted of putting these in environment configuration. IMO, environment variables should be for deployment configuration (secrets, domains), not application logic.

The SDK already uses constructor options for config and reading env vars -> Auth0Client constructor options is a trivial task on client side, we are not sure if SDK is the right place to add logic to read this from environement.

That being said, this PR does aim to solve a rather important issue and we have taken note of this and will solve this via CTOR options in a recent upcoming release. While this is planned, we would appreciate code contributions for the same!

Closing this, if any queries, feel free to ping me or create an issue for the same.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants