Thanks for reaching out on this issue and giving us some feedback.
I am going to default to the GitHub ticket you raised as this is the most direct way to communicate with the owners of that library. Please let me know if there is anything else I can do.
The library ‘fix’ will mean we’re tolerant of / handling the error gracefully.
Update…
I just had a hunch it was the Auth0 UI posting back to the Auth0 API so I opened up my developer view and watched the network traffic and noticed that the problem is someone had created the scopes with a trailing space (copy ‘n’ paste methinks).
Maybe this ticket should instead request that when scopes are created then whitespace should be treated as invalid since subsequent processing of JWT scopes would be impacted.
I would just like to clarify and confirm that this issue is not with how scopes are configured in an auth0 api (management api or authentication api), but was due to a typo in a custom api, correct?
As far as the suggestion/issues with that repo; that would be best handled in the github repo directly, as you have already done.
I am using the https://manage.auth0.com UI to manage scopes.
I have just created a scope like so: scope with spaces successfully.
The UI sends a PATCH request to https://manage.auth0.com/api/resource-servers/{api-id}.
Part of the body of the request is: {“value”:“scope with spaces”,“description”:“bad scope”}.
I then assigned that scope to my Client/Application.
When I get a JWT (via the Quick Start tab of the Auth0 management UI) and decompose it, the scopes claim has scope with spaces. The Auth0 Java library will split the scope value using spaces. I suspect most libraries in most languages will behave the same. This will result in any application that uses it thinking the requesting JWT has three scopes ‘scope’, ‘with’ and ‘spaces’ which is not what was intended.
Ideally, the request to https://manage.auth0.com/api/resource-servers/{api-id} would reject my request with a 400 Bad Request error to prevent any downstream use of this scope.