Theres another topic about this, but that was over a year ago and the solution doesn’t feel like a good long term fix…
Is there not another way now to handle custom domains in the Authentication API Debugger?
The other topic solution was to edit the html and change the value of the input field… which every time the page refreshes, that has to be done. Why can that field be enabled so it can be directly edited? Or why not allow us to save a custom domain to local storage like the other fields? This seems like a big deal considering most production systems would be using custom domains, and the easiest way to obtain an access token is by using that tool.
Just thinking out loud…
Welcome to the Auth0 Community!
Unfortunately, for the moment, the Authentication API debugger does not allow you to change the domain of the request. As you discovered, one workaround would be to edit the HTML, but this resets each time you refresh the page.
Because of this, I recommend running your tests using Postman using our Auth0 Postman Collections.
This way, you can run repeated tests without the need for editing/refreshing the page.
Let me also emphasize that you can use either your canonical domain or custom domain in your tests since they behave the same.
@rueben.tiow Thanks, my goal though is to grab an Access Token for my test user so I can test it on my own applications. I use postman, but maybe I’m missing something, I need to do an OAuth2 flow and authenticate as that user and just get the access token. I was using the debugger for that
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
Thanks for following up.
It sounds to me like you are performing the authorization code flow. In this flow, you will have to start by going to the authorization URL to log in and then exchange the code for an access token (
There is another way to test where you specify the
response_type=token instead in the authorization URL. This way, you skip the exchange for a code for a token and get a token directly. However, be careful, as this will expose the token to the browser and should not be used in production, as it’s not considered best practice.
(Reference: Implicit Flow with OIDC)