I’m having a React single page application and a web API which is authenticated. The authentication is all set up and I’m able to make authenticated requests from my web app to my web API.
However, the issue that I’m facing now concerns the cloud deployment of my app. On the client side, I need my auth0 domain, my auth0 clientId, callback URL, API audience to create the Auth0 web login. I’m avoiding hardcoding these details as a JS object in my source code and check it into source control.
If I add an unauthenticated API on my API code to provide me these details and call this API endpoint first to get these values on client side and then redirect to Auth0 for the login screen with the details fetched, is it safe? My concern is that anyone can access these details since it will be an unauthenticated API.
I feel it’s a common enough problem to be faced by many people. How do you tackle this?
None of the information you mentioned (identity provider domain, client application identifier, callback URL and API audience) is considered confidential information so it’s acceptable and, for the majority of them, a requirement of how the underlying protocols work to somehow disclose this information to the client application running on an environment you don’t control (in this case the end-user browser).
In relation to the method you disclose or make this information available to the client application it’s mostly a matter of preference. I would agree with you that it makes no sense in hardcoding the actual values into the source code, however, using additional calls to obtain them also seems like an unnecessary overhead with no real benefits.
I think the most recommended way would be to have placeholders at the source code level which are then automatically replaced in a build/release pipeline that take in consideration the target environment. This would allow the same source code to be build both for a debug and production environment.
I agree @jmangelo . I had earlier considered templating for these values at build time (where the JS scripts would be bundled) on a build agent, but the problem is that it doesn’t make the output build bits environment agnostic.
Suppose I’m using Azure with two slots in production each slot having their own environment variables with these values, it won’t play out since these values would then be hard-coded at build time. So I’m going with a public API route which would then return the values based on each environment’s own variables.
I agree @jmangelo . I had earlier considered templating for these values at build time (where the JS scripts would be bundled) on a build agent, but the problem is that it doesn’t make the output build bits environment agnostic.
Suppose I’m using Azure with two slots in production each slot having their own environment variables with these values, it won’t play out since these values would then be hard-coded at build time. So I’m going with a public API route which would then return the values based on each environment’s own variables.
Yes, I understand your point and like it was mentioned, obtaining that data through another call has the same characteristics of bundling them at build time from the perspective of the information is disclosed either way.