Management API Access Tokens dead end

Hi All,

I am trying to replace the login in a legacy site, which uses old Azure AD, with Auth0.

I have the login working well, however the existing site has a function for users to create new users. To do that, I need to have the site API (ASP.NET Web API) access the Auth0 Management API to create and edit users.

I got that working, but only if I manually create a testing access token. I need to create a ne Management API Access Token every day. I have been stuck since yesterday at this stage. I have read every page of the documentation FWIW multiple times.

My API checks the age of the access token and, if it is too old, attempts to get a new one. I have registered an API in Auth0 with a corresponding application. I request the access token with the Client ID and Client Secret from the application and Audience from the API.

After working through error messages I have got to the stage of “Missing required parameter: refresh_token”

How do I get a refresh token for a .NET based API? I can’t find anything. Is there any method of getting new Management API Access Tokens without using a refresh token?

Thanks in advance,

Rob

I don’t think you can get refresh tokens for the Management API.

For your own defined APIs, you can request the offline_access scope to get refresh tokens.

Since your calls are coming from a backend, the client credentials grant is a good way to get tokens.

Here is a similar question and answer:

Hi Josiah,

Thank you for the reply.

I had already seen that Best Practices thing. I know I need to perform a Client Credentials Grant. This is what I have been trying to do. However, the available documentation is opaque. I had already tried using the Quickstart ASP.NET Web API example, but the operation of that example is completely obfuscated. I can’t debug it to see what it is doing. I need to translate it to a much earlier .NET, which is trivial for me if I now what I am dealing with.

My back end is secure enough to hold a secret or rotating token. I have been doing that for years with Azure AD. I have read the reference docs linked to in the article and they do not give instructions on how to perform a Client Credentials Grant using any of the tokens, secrets or Client IDs I have found to be available.

There are one or more links missing from Auth0’s documentation. Does anyone have any idea of how to perform a Client Credentials Grant as I need to do?

Rob

See this Auth0 Authentication API documentation:
https://auth0.com/docs/api/authentication#client-credentials-flow

Here is some more documentation:

Hi Josiah,

A have seen those examples as well. They are brisling with refresh tokens, which is one reason I went on the the refresh token wild goose chase.

I completely understand the flow. The part I am looking for is missing. I have really looked at all the documentation I can find. I am a very experienced developer. I have been three days trying to find a solution. There is a major gap in Auth0’s documentation.

Rob

What specifically are you looking for?

I thought you were looking for documentation on how to make a client credentials token request, so that’s what I sent.

To make a client credentials request for the management api, POST to /oauth/token with the following in the x-www-form-urlencoded content: audience=YOUR_AUTH0_DOMAIN/api/v2/
grant_type=client_credentials
client_id=YOUR_CLIENT_ID
client_secret=YOUR_CLIENT_SECRET

Thanks Josiah. I’ll try further tomorrow. It is late and hot and I need to eat something.

Is the /api/v2/ required on the end of the audience? Maybe that is what I was missing.

Rob

Hi Josaih,

Again, the Client Credentials Flow link does not provide any information or instruction on how to preform a client credentials token request. It does explain the process admirably and I believe I have a good understanding of the process.

I did as you wrote in your last email:

I had set up a matching application and API several days ago in the hope of using them to have my backend API code perform a client credentials token request. The application is authorized in the API. Both the User Management API and the API I registered are authorized in the application.

I took the Client ID and Client Secret from the application I registered.

I took the Identifier (audience) from the API I registered.

I ended up with this set of parameters: {“grant_type”:“client_credentials”,“client_id”:“8uFuGOFAb5punxWJQf2qYF6TXSx5tnUN”,“client_secret”:“fhW0fDAd3nXcDtapuSITHPPDdd-UX9HDXxKwRg-UFzHdQ8vWNGYoorQIEsACb_6-”,“audience”:“https://dev-7cdpp4yt.us.auth0.com/api/v2/”}

I added the header “content-type”, “application/x-www-form-urlencoded”

I sent it as a POST and got back {“error”:“access_denied”,“error_description”:“Unauthorized”}

I have been unable to use any of the C# examples in the documentation because they tell me to use an object called RestClient. See:

var client = new RestClient(“https://dev-7cdpp4yt.us.auth0.com/oauth/token”)

There is one RestClient object in .NET but that is an Azure specific thing. There are other RestClient things out there in NuGet packages but there is no clue in the AuthO documentation as to which RestClient to use the native .NET HTTPclient instead. It works fine for everything else.

I know I am probably using the wrong ID or secret. My code for getting a test token using a manually obtained ID and secret works flawlessly. As far as I can see, I do not know where to get the correct ID and secret to use. Can someone please help me with information on how to obtain an ID and secret that will enable my code to get the token.

Thanks,

Rob

Firstly, I recommend that you rotate your client secret ASAP. You can do this in the dashboard by finding the application, going to settings, and looking in the “Danger Zone” at the bottom.

This to me looks like you should actually be sending the request with content type application/json instead of application/x-www-form-urlencoded.

As for an application getting the client id and secret, I’d recommend providing that to the application with some service similar to AWS Secrets Manager and avoid putting either in source code.

Your previous message instructed me to use ‘x-www-form-urlencoded content’. That is why I was not using application/json until I will go.

Is the client secret from my registered app the client secret I should be using? Please answer. Yes or no.

If no, which API do I get the secret from, and what form of request to I need to make to that API?

To reiterate. I need to know:

1, How do I get a client secret so I can generate a new token every day for accessing the Management API to create and edit users?

2.How do I add that client secret into a request for the new token.

I have been going around in circles for three days.

There is no point in rotating secrets until I find the answers to that question. For now I will put the sensitive stuff in the source code until I get the code working on my development machine. I need to take one step at a time.

Rob

The request was formatted as json. You can send it as x-www-form-urlencoded if you format it that way. Since you already have it formatted as json, you can just use application/json.

You should be using the client id and client secret pair from the application that is registered for use with the management api.

You can find documentation here:

There is a button on there to show you the C# code you would run. A little further down is a table that explains where to get the values from.

I have already been to that link many times and tried the example. It is exactly the same as what I described in a pervious message.

I tried again, to see if anything had changed, and the result was exactly the same: {“error”:“access_denied”,“error_description”:“Unauthorized”} which indicates that I am accessing the API but that the ID and secret are incorrect.

I have followed the instructions on that page slavishly, yet it still doesn’t work.

I cracked it, after four days of basically turning over every possible stone.

If anyone wants to implement what I described in a legacy ASP.NET MVC site or API then ask me. I don’t have the energy to describe it here. Always willing to help a fellow sufferer though. @rl_keith

Rob

1 Like

I’m having the same problem, could you please share the solution you found? Thank you in advance