Which permissions define visibility for SPA pages

Question

I have a ASP.NET React Web Application. For authentication I use Auth0, using the server side (C#) as Backend-For-Frontend (see this blog for more details). So all the client side (React) see, are the cookies the server returns. The cookies are sent along automatically, allowing for easily forwarding the users access token, without the user ever seeing it. For instance like this:

[HttpGet]
public async Task Get()
{
    var accessToken = await HttpContext.GetTokenAsync("Auth0", "access_token");
    var httpClient = _httpClientFactory.CreateClient();
    var request = new HttpRequestMessage(HttpMethod.Get, new Uri(_apiEndpoint, "WeatherForecast"));
    request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", accessToken);
    var response = await httpClient.SendAsync(request); 
    // ...do something with response
}

But what if I also want to hide the UI element corresponding to this endpoint, in my client? As mentioned, all the client see are the cookies. If the weather forecast in this example requires a permission watch:weather_forecast, how would I know whether or not to hide the UI element, when the client doesn't even know the concept of permissions?

My best take on this would be to make an endpoint where the client can fetch the permissions, so that it has something to check against. But on the other hand, this would also mean exposing a lot of what I just managed to hide...

Either way, it feels like this should be a solved problem. Isn't there an existing pattern for this interaction between client and server, when using the Backend-For-Frontend pattern?

Answer 1

From that blog post, in the UI I would be checking the claims in the return from GetUser() and using the information therein to determine which parts of the UI the user should have access to.

Note: you cannot trust the front-end. The ability to change values via a JS Console or whatnot means that a mildly savvy hacker could "turn on" the parts of the UI that you are disabling via the claims check. So any "sensitive operations" that you'd want to do should be done on the backend, not in the UI itself.