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?
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?
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?
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.