Custom Domain failing to reflect in the login page

I wanted to use a custom domain for my universal login and have successfully configured it with it saying the following message-“Your domain is configured correctly.”

Let us assume my default domain is dev-xxxxx.auth0.com and my custom domain is johndoe.com

import React from "react";
import ReactDOM from "react-dom/client";
import App from "./App.jsx";
import "./index.css";
import { Auth0Provider } from "@auth0/auth0-react";

document.documentElement.classList.add("dark");

const domain = import.meta.env.VITE_AUTH0_DOMAIN;
const clientId = import.meta.env.VITE_AUTH0_CLIENT_ID;

ReactDOM.createRoot(document.getElementById("root")).render(
  <React.StrictMode>
    <Auth0Provider
      domain={domain}
      clientId={clientId}
      authorizationParams={{
        redirect_uri: window.location.origin,
        scope: 'openid profile email phone',
        audience: `https://${domain}/api/v2/`,
      }}
      useRefreshTokens={true}
      cacheLocation="localstorage"
    >
      <App />
    </Auth0Provider>
  </React.StrictMode>
);

I have replaced my domain with johndoe.com in my .env file. I was wondering as to why it is not being reflected when running my Localhost and clicking on the login button( i get redirected to -http://localhost:5173/?error=access_denied&error_description=Service%20not%20found%3A%20https%3A…). I don’t know what additional configuration is required for my main.jsx React Auth0 Context component.

Hey there @empowerfrontiers !

I see the audience in Auth0Provider is that of the Management API - In this case you shouldn’t use the custom domain, but rather the default domain like https://dev-xxxxx.auth0.com/api/v2 instead of domain as it exists in your .env. I believe updating this should do the trick.

As a side note, Management API access tokens requested in a SPA are limited and generally not encouraged:

1 Like

Thank you. That worked.

I was only using Management API for the following scopes: update:current_user_metadata read:current_use to add some user onboarding status flag metadata and is not of any confidential nature. While I understand the limitations of using it in SPA, might I ask why is it limited and what is the recommended approach?

1 Like

Awesome, glad that was it!

The way you are using it currently is fine, but the recommended approach is to proxy Management API requests through a backend of sorts:

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.