Conversation
Users seeded via initialState can carry user_metadata/app_metadata
(default {}), and rules receive both on the user argument as Auth0 Rules
do, so claims can be derived from metadata. Neither is copied into the
tokens unless a rule adds it as a claim.
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (9)
Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review. 📝 WalkthroughWalkthroughThe Auth0 simulator now stores seeded ChangesAuth0 user metadata
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~12 minutes Change: Feature Sequence Diagram(s)sequenceDiagram
participant OAuthHandler
participant MetadataRule
participant IDToken
OAuthHandler->>MetadataRule: Supply cloned user_metadata and app_metadata on user
MetadataRule->>IDToken: Add selected metadata values as claims
OAuthHandler->>IDToken: Exclude metadata objects from profile claims and merge rule claims
Suggested reviewers: Merge Risk: ⚪ Minimal · up to No demonstrated issue blocks merging this metadata change after normal checks. Security Architecture ReviewSecurity architecture risk: 🔵 Low · up to Metadata becomes available to configured rules, but is not placed in tokens by default. The reviewed flow keeps rule mutations separate from stored users, and no new metadata-update endpoint is shown. No PR-introduced security concern was established; broader security coverage remains unconfirmed. Retained concerns Security review detailsSecurity Blast Radius
Trust Boundaries and Controls
Resilience and Maintainability Implications
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
commit: |
Package Changes Through 879b0f4There are 1 changes which include @simulacrum/auth0-simulator with minor Planned Package VersionsThe following package releases are the planned based on the context of changes in this pull request.
Add another change file through the GitHub UI by following this link. Read about change files or the docs at github.com/jbolda/covector |
2 participants
Motivation
In Auth0, users have
user_metadataandapp_metadata, and rules often use them to add custom claims (for example, putting an organisation id fromapp_metadatainto the access token).The simulator's users only have
id,name,email,passwordandpicture. Metadata has nowhere to go, so a rule that readsuser.app_metadatagetsundefined. To test those rules today, you have to pass the values in some other way, such as an environment variable read inside the rule.Approach
user_metadataandapp_metadata, which default to{}. You can set them ininitialStatelike any other user field.userargument, as in Auth0.Tests cover seeding the fields, their defaults, reading them from a rule, and keeping them out of the tokens. The README has a short example.
Alternate Designs
The simplest option was to add metadata to the user data that already gets spread into the ID token. I didn't do that because the whole metadata object would then appear in every ID token, which real Auth0 doesn't do.
Possible Drawbacks or Risks
Nothing changes for existing users: both fields default to
{}, and tokens look the same unless a rule uses the new fields.TODOs and Open Questions
PATCH /api/v2/users/:idand others) on top of this, so a metadata update can reach the next login.Summary by CodeRabbit
user_metadataandapp_metadata, which are available to rules through the user object.