Add custom claim to access token not working

Get Help
8

Thanks for the reply! I still don’t think the documentation is clear on this. I don’t have a problem with the way these restrictions work, I just want the documentation to be clear and accurate.

  • This sentence is introduced by the words “Use the following guidelines:”. I parse this in context as “guidelines to help benefit from our suggestion of using a URI you own in order to avoid collisions”. More to the point, “Guidelines” is not equivalent to “Requirements” so it’s not clear that these “guidelines” must be followed.
  • My interpretation of this guideline as optional is supported by the earlier section which says “you can call your namespace anything you want”. This “anything” quote refers to “your namespace”, not “your XML namespace”, so it’s not even implied that there’s an enforced limitation on the namespace format with how that sentence is worded.
  • In the doc, the term “namespace” is used several times before it is compared to “XML namespaces” (which only happens once). The concept of a namespace can mean many different things outside of XML, including simply nesting all data under a single unique key. Also note that we’re modifying JSON objects, not XML documents, so it’s not obvious or intuitive that XML rules apply unless that’s stated explicitly.
  • There are schemes other than http: and https:, but it seems that no other schemes work with the Auth0 API. If I use a different scheme, the data will not be included (I tried ftp:, git: and the made up foo:). This tells me that the actual rule is not “Must be a URI”, but rather "Must start with the string "http:" or "https:". Accuracy matters in technical documents and it would actually be more direct and take less space to simply define this explicit rule (start with http[s]) and then provide details on why the recommended method of following the rule is by using a URI you control in order to avoid collisions.
  • That explanation makes sense, thanks. I’d love to see a toggle there to enable enforcement of the namespacing rules when using the “Try This Rule” button as if an ID token were being generated (bonus points for showing a message if your data was removed due to a namespace rule). Treating the inserted data differently in the dashboard makes these types of issues harder to debug. If there’s a better place to submit a feature request for that, let me know.

I urge you to get the Custom Claims documentation updated to explicitly name the two possible strings that a namespace must start with. These are Auth0’s own rules (not XML namespace rules, even if that was the inspiration), so your documentation needs to explicitly define the rules it’s using.