Differences between client_metadata and app_metadata

I’m reading the documentation on metadata and I’m having issues understanding the difference between client_metadata and app_metadata.

I understand that client_metadata is limited to 10 keys and 255 characters, and that there are different APIs to create/read/update/delete client_metadata vs app_metadata.

But when should I be using one as opposed to the other? Technicalities aside, how are they different? To give some context, my goal is to store a secret that needs to be returned in the JWT claim, and I’m not sure if I should put it in client_metadata or app_metadata.

Hi there.
client_metadata is a multi-purpose key/value hash to store information about an application (i.e. a “client” in OIDC/OAuth2 lingo). You might store, for example, the URL for the application’s home page (a field that Auth0 doesn’t provide by default in the application settings).
You get or set client_metadata either using the clients API (/api/v2/clients/{client_id}) or in the dashboard, in the application’s advanced settings. The client_metadata is stored as part of the application (a.k.a. client) properties.

app_metadata (and it’s close relative user_metadata) are both multi-purpose stores to put information related to a specific user. You use the users API (/api/v2/users/{user_id}) to read or write them. Each user can have different metadata stored in their profile.
The different between app_metadata and user_metadata is that the first should be used for information about the user that is controlled by the application (e.g. the user identifier for a legacy system, or the roles a user have), whereas user_metadata is information that the user can view and control (e.g. user settings, preferences).

More information at Manage Metadata with Rules and Understand How Metadata Works in User Profiles.

Regarding your question about where to store the secret, it depends on the scope of the secret:

  • Is it just one secret per application? Then client_metadata would be a good place. But if this is the case, you should consider storing the secret directly in the application instead, to avoid putting the secret in the ID token.
  • Is it the same secret for the whole system (i.e. for all application, or many)? Then the rule’s configuration values might be a better choice
  • Is it a different secret for each user? Then app_metadata might be better.

Regardless, remember that claims in the ID_Token are not encrypted, so depending on the flow that you use the user might be able to get the token and inspect the contents. So putting a secret in there might not be a good solution.

2 Likes

Hi Nicolas,

Thanks for responding, this was very helpful and makes sense.

There is one secret per application, and it’s immutable, so I’ll store it in client_metadata.

You’re totally right on highlighting the dangers of using the JWT to pass secrets. I don’t think this would be a risk in my case, as the “secret” stored in Auth0 is only part of the “actual secret”, and the user needs to type the other part of the “secret” in a static web app (with no backend). The resulting data, combining the secret typed by the user and the one received in the JWT, is then used to derive an encryption key with a key derivation function. Additionally, only authorized/whitelisted users are allowed to log into the app and get the (part of the) secret from Auth0.

1 Like

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.