How to send client_metadata when using Auth0Client for SPA

Please include the following information in your post:

  • auth0-spa-js
  • 1.13

If I call /oauth/token directly on the back end I can pass in extra meta data that can be used to propagate in the access token but I cannot find how to do that while using the javascript sdk. I looked at the documentation at @auth0/auth0-spa-js | @auth0/auth0-spa-js but nothing seems to have that as an option.

Has anyone done this or know if it’s possible?

I’m using the sample code provided on Auth0 docs.

HI @abunas

That is not safe (assuming I understand you correctly).
If you are passing in information from the SPA/Front End that is included in the access token, there is no way to verify that information since it comes from a non-confidential client.

You probably need to get that information into the user’s user or app metadata instead, and add it to the token there.

John

1 Like

Thanks for helping on this one John!

The data I need to put there is not really something that needs to be safe. It’s to identify the source of the log in. Separate from the safety question, is such a thing possible? If it’s not possible then my other thought is to create a dedicated application just for that one client app to identify it that way.

Also, for the following, @john.gateley can you elaborate how that is done? Thank you.

You can pass in additional parameters to the authorize call, that may help here.
You’d have to add them to the app metadata for use in rules when the token is created.

I’m not sure of another way, as I said before: that information is easily spoofed and thus is of questionable value.

John

I’m using createAuth0Client functionality in a web page and will have to also do similar in a native mobile app with a ReactNative implementation. As far as I can tell I cannot control the authorize call but maybe I’m missing something from the API documentation. I was working off the sample from Auth0 samples.

Yes, that info can be spoofed but in this case it’s just an ID for the app using it. One ID for web and one for Mobile. It’s not something that’ll give extra permission or access to the user.

Thanks,
Andi.