app_metadata missing when getting a user JWT using auth0-java

We’re using Auth0 as our security provider for a number of microservices / web front end. I’ve been looking at dynamically creating users for our automated tests (we’re currently using fixed users), using the auth0-java library.

Using this library, I can create and delete the users, including setting their app_metadata as required by our services. However, our test framework also needs to insert test data via our microservice APIs, and requires a user JWT with appropriate app_metadata included. I can get this JWT from the users I have created using either a standard HttpRequest, or a curl script, but when I use the auth0-java library’s login method, I get a JWT back with standard contents, no app_metadata.

Code being used:

public static String getUserJWT(String username, String password) {
    AuthAPI auth = new AuthAPI(DOMAIN, CLIENT_ID, CLIENT_SECRET);
    AuthRequest authRequest = auth.login(username, password, CONNECTION);
    authRequest.setScope(SCOPES);
    return authRequest.execute().getIdToken();
}

SCOPES = “openid user_metadata app_metadata”

I’ve experimented with adding an audience for the auth request, but whatever I use (and whether it’s in the allowed callbacks for that client or not) it says it’s invalid for password grant exchange.

At this point, I’m keeping our existing HttpRequest methods to grab the required user JWT, but it would be nice to be able to use the auth0-java library for this. Given I can get the correct JWT using existing methods for my created users, I think the user setup is OK, and there may be a bug with the auth0-java library, but I thought I’d check here to see if anyone has any idea why this may not be working.

The login method uses the /oauth/token endpoint to perform username/password authentication and this endpoint does not support the legacy authentication response where app_metadata would be included in the ID token if you requested it as a scope. In order to obtain that behavior you would have to call the /oauth/ro endpoint instead.

The recommendation is of course to use the non-legacy version of the endpoints and move to OIDC compliant responses; app_metadata would not be included by default as it is not an OIDC standard claim, but you could include the relevant metadata information as custom claims.

If at this time you don’t have the possibility to review your existing integration to leverage how the new flows work then for this specific scenario you’ll need to use a direct call to /oauth/ro endpoint instead of going through the library as to my knowledge the library does not expose a method to call the legacy endpoint.