Integration Tests Custom Claims or Pre-Created Users

In some of my tests I need to identify the user in terms of my application. For us this means, extracting a custom claim we place in the user’s metadata with a rule.

Right now my tests authenticate by requesting access token form “.us.auth0.com/oauth/token”, providing my client id and secret. This works for general tests that only validate a user is authenticated.

Maybe I missed something in the documentation, but I’ve not been able to figure out a way to authenticate AS a given user. I wouldn’t mind doing what is suggested in this questions but I don’t know how I would then specify which user to authenticate with.

Another option that would work for me is being able to create a valid token, and also attach that custom claim I put using rule. Is there a way for me to authenticate and add custom claims using the API?

Thanks

Hello @jhenriquez,

Welcome to the Auth0 Community.

I’ve not been able to figure out a way to authenticate AS a given user

Do you mean impersonating an arbitrary user? If so, there is no facility for impersonating a user in Auth0. Or more to the point, there is no facility in OAuth 2.0 and / or OpenID Connect for impersonating a user.

Or are you just trying to authenticate with a test user for which you have the credentials?

Hi @markd

I think a simple pre-created test user would work for me. That’s the accepted answer in the post I referenced.

But my ideal solution would be to be able generate a valid token with a custom claim in it. In production, this custom claim is set by Rule.

In my test environment, it would be nice if I could add that same claim to a valid token.

If this is not possible, I’m willing to try the pre-created test user approach. How can I go about that?

In you original post, it sounds like you are using the client credentials grant, which is a way for an OAuth client to authenticate itself to the authorization server (AS), which is Auth0 in this case. You can add custom claims to the resulting tokens by using the client credentials hook.

If you want to authenticate a user, you’ll need to use a different flow, like the authorization code flow. Which one you use depends on your use case. It sounds like you are already doing all of this in your production environment.

Thanks for the quick response @markd , I really appreciate it.

This sounds really promising. I’ll try it!

I barely use the APIs in production. At least directly. Specifically I only use the ClientCredentialsTokenRequest to a get a token for the management API and the GetUsersRequest to validate a user exists based in the user_metada.id.

All other Auth0 interactions are handled by the JWTBearer middleware of dotnet core.

In my tests however, I’m using the example provided my Auth0 Management API Test section. Specifically:

var client = new RestClient("https://<my-domain>.us.auth0.com/oauth/token");
var request = new RestRequest(Method.POST);
request.AddHeader("content-type", "application/json");
request.AddParameter("application/json", "{\"client_id\":\"<my client id>\",\"client_secret\":\"<my-secret>\",\"audience\":\"<my audience>\",\"grant_type\":\"client_credentials\"}", ParameterType.RequestBody);
IRestResponse response = client.Execute(request);

Since I am using the client_credentials grant_type, I assume the Client Credentials Exchange
hook will be able to help me. Is this assumption correct?

Hello @markd

I’ve been reading the documentation and it seems that the client credentials exchange hook is analogous to the rules and would allow me to update the token with custom claim I want.

Maybe I am asking too much now, but I was hoping I could pass additional information that I could then access in the hook, that way I could let the hook know I’m in a test so that it does add the additional claim, or avoid doing it if does not receive that parameter.

I guess it won’t affect me in any way to have the hook always add the claim with some random uuid, which would be enough for me test. But it doesn’t feel right to have this happening all the time.

I am assuming that this hook will only execute when I call the authorize api with client_credentials grant, and that my users when authenticating in the SPA are using the Authorization Code flow, so there is no way the hook and the rule would collide. Is my assumption correct?

UPDATE

Is there a way to pass along information that could be then used in the hook?

I think I figured this one out. I guess I only need to differentiate my tests by having a different tenant, then in that tenant I would configure the hook. But not in dev or production.

Is this good practice?

We do this with one of our clients. We use our simulator to generate specific tokens that we use to test specific flows and scenarios.

It’s not trivial to set up, but possible.

Checkout our post about our approach to getting more control in tests

https://community.auth0.com/t/auth0-simulation-for-ephemeral-deployments-and-reliable-automated-testing/78334

Taras

1 Like

Thanks for sharing that with the rest of community!