Cannot Access app_metadata From Rule

[john-craft]

I am trying to add information from app_metadata to a user’s profile after login using a rule. However, app_metadata doesn’t appear to be available from within the rule. Is it possible I am not sending along enough information using the “Try This Rule” button?

The code for the rule is below.

function (user, context, callback) {
  const namespace = 'https://somedomain.com/';
  context.idToken[namespace + 'app_metadata'] = user.app_metadata || "nothing";
  callback(null, user, context);
}

The context information from the “Try This Rule” modal is below. It’s all the default text except I updated clientId to the appropriate value and I added app_metadata to the profile (I read somewhere to do that).

{
  "clientID":            "12345",
  "clientName":          "MyWebApp",
  "connection":          "MyDbConn",
  "connectionStrategy":  "auth0",
  "protocol":            "oidc-basic-profile",
  "request": {
    "query":             { "scope": "openid profile app_metadata" }
 },
  "samlConfiguration":   {},
  "stats":               { "loginsCount": 5 },
  "accessToken":         {},
  "idToken":             {}
}

When I execute the rule, the portion of the token that I expect to contain app_metadata is blank because user.app_metadata is empty even though the user I am testing with contains app_metadata values.

"idToken": {
    "https://somedomain.com/app_metadata": "nothing"
  }

I didn’t modify clientName, connection, connectionStrategy, etc., within the context and maybe that is causing the problem or is it something else?

[bruno.krebs]

Hi, @john-craft. Thanks for reaching out.

Instead of testing your rule through the “Test Rule” button, you can head to the “Database Connections” and use a more realistic scenario (if you don’t use a custom database connection, you can head to the “Social Connections” page and do the same).

After choosing the connection you want to use, click on the try button, and log in with a real user (the one you updated with app_metadata rules. If you don’t get the metadata as a custom claim, let me know and we will investigate more.

By the way, I just copied the rule you mentioned on the original question, added to a new rule in my Auth0 tenant, and hit the try button, and everything worked as expected.

You can see the result on the image above. There, you will see the custom claim with a “beach tennis” value. I added this value to my user (bruno@spam4.me) as an app_metadata.

[john-craft]

Thanks, @bruno.krebs. I tried the social connection as you suggested and the rule worked; i.e., the custom app_metadata was returned.

I would still like to know they the “Try” button does not work for me when I use it. Is the context information important when I click “Try?” If so, maybe that is why it works for you and not me?

[john-craft]

One more question, @bruno.krebs: I am having the same problem as in this post where app_metadata is not available in idTokenPayload. However, I am namespacing the custom property added with my rule (see below). How can I get at the custom properties?

[bruno.krebs]

Regarding the “Try” button on rules, are you passing all the information you want to the “User” object that the dialog shows? Changing any of its properties to reflect an existing user won’t make the the rule pre-fetch the other properties from any existing user. That is, the rule will get what the modal is showing and nothing else.

I will check the idTokenPayload thing and come back to you soon.

[bruno.krebs]

Regarding the namespacing problem, this is what our docs says:

Any non-Auth0 HTTP or HTTPS URL can be used as a namespace identifier, and any number of namespaces can be used. The namespace URL does not have to point to an actual resource, it’s only used as an identifier and will not be called by Auth0.

That is, you will have to:

1. Fix the namespace so it is a valid URL (replace colons with dots).
2. Use your own domain or anything else (that is, remove auth0.com from the namespace).

I hope that helps.

[john-craft]

That worked. Thanks, @bruno.krebs.

First off, I didn’t even realize there were colons instead of dots. That should have been the first thing to catch. The strange thing is that I had dots in the rule, so Auth0 must have been switching the dots to colons. Either way, changing the domain to a non-Auth0 domain solved the problem.

[bruno.krebs]

Well, I’m glad you fixed the problem. Let us know if you need further assistance.