Blazor Server Authentication not working after publishing to Azure (linux)

[drma-tech]

https://site.azurewebsites.net/
signin-google
?state=xxx
&code=yyy
&scope=email+profile+openid+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile
&authuser=0
&prompt=none

Sorry, there is nothing at this address.

This error occurs after trying to log in to google in a blazor app after publishing in azure linux (the same did not happen in the windows environment).

logging in normally (user + password) works, but cannot communicate with the API.

[javiercn]

@drma-dev thanks for contacting us.

@blowdart this is not Blazor server specific since auth happens before the Blazor application starts (this is server-side Blazor). From what I can tell, the callback is not hitting the auth endpoint and going through the catch-all route that SSB defines instead. Note that it if goes there is because no other endpoint/handler was available.

[drma-tech]

It started after a certain time. I'm not sure if it was from a certain version of blazor or something that happened on azure.

another mistake is that if you log in with email and password (without google), it cannot call the API, because it cannot recognize the user's token or authentication.

[blowdart]

This doesn't sound generic to me @javiercn - perhaps something with the identity server integration give the inability to call the api.

regardless, @drma-dev what's in the server logs? Can you up the verbosity and try?

[javiercn]

@blowdart Blazor server doesn't use Identity Server (at least our templates). We only use it on Blazor WebAssembly.

Blazor server apps use whatever auth mechanism you want to use for a regular Web Application, all the auth happens before the Blazor Server app starts.

What is likely happening there is what I mentioned above, the auth callback endpoint is somehow not correctly configured, and it's going through the fallback route that server-side Blazor defines, but the issue is that the auth handler is not correctly configured in some way.

[blowdart]

OK in that case, startup.cs pleas @drma-dev

[drma-tech]

Even using the template (with authentication option) without changing anything in the code (forgetting this google issue), it will give an error when accessing the api with [Authorize].

And it only happens in azure (linux environment), if I publish in azure (windows environment) it works normally.

I believe that both errors (API and google) are related to the same thing.

[blowdart]

OK what template, what error? What's in the server logs?

[drma-tech]

https://github.com/drma-dev/BlazorApp1

https://app-verusdate-beta.azurewebsites.net/ (fetch data page)

I don't know how to catch errors (verbosity) in azure

[javiercn]

@drma-dev thanks for the repro.

This turned out to be Blazor webassembly, not server-side Blazor. Moving to the blazor area

[javiercn]

@drma-dev just co confirm, your scenario is that you have a hosted Blazor WebAssembly application that uses individual auth (Identity + Identity Server) and you are trying to offer the option to users to authenticate using their google credentials as part of logging in with Google, and it's failing after you click login with google on the UI and tries to come back to the application?

[drma-tech]

Yes, but this error only occurs when it is published in azure (web app - linux environment).

And if you log in using the traditional method (email + password) the login works, but the APIs stop responding due to authentication failure.

[javiercn]

That seems like two separate issues to me:

• The authority/issuer are out of sync, try setting up the authority and the issuer explicitly in the IdentityServer options and JwtBearer options respectively,

• Your google callback-endpoint is not correctly configured and is not being picked up. That doesn't have anything to do with Blazor.

[drma-tech]

No. I believe it is a limitation of the linux web app

[javiercn]

No. I believe it is a limitation of the linux web app

Not sure what you mean by this

[drma-tech]

localhost does not have these errors.
azure web app (windows environment) does not have these errors.
azure web app (linux environment) has these errors.

[drma-tech]

@javiercn is it clear now?

I haven't found any place that can report azure bugs, so I'm here

[carlingkirk]

I was experiencing this issue - the "/signin-google" request was being served from index.html. The fix is to add the endpoint into the list of exclusions in onFetch in service-worker.published.js

In Client\wwwroot\service-worker.published.js:

async function onFetch(event) {
    let cachedResponse = null;
    if (event.request.method === 'GET') {
        // For all navigation requests, try to serve index.html from cache
        // If you need some URLs to be server-rendered, edit the following check to exclude those URLs
        const shouldServeIndexHtml = event.request.mode === 'navigate'
          && !event.request.url.includes('/connect/')
          && !event.request.url.includes('/signin-google')
          && !event.request.url.includes('/Identity/');

        const request = shouldServeIndexHtml ? 'index.html' : event.request;
        const cache = await caches.open(cacheName);
        cachedResponse = await cache.match(request);
    }

    return cachedResponse || fetch(event.request);
}

[drma-tech]

thanks. you save my life.

[drma-tech]

Although I am able to login, there is still an error when accessing a protected api. did you go through this @carlingkirk?

crit: Microsoft.AspNetCore.Components.WebAssembly.Rendering.WebAssemblyRenderer[100]
      Unhandled exception rendering component: net_http_message_not_success_statuscode, 401, Unauthorized
System.Net.Http.HttpRequestException: net_http_message_not_success_statuscode, 401, Unauthorized
   at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode()
   at System.Net.Http.Json.HttpClientJsonExtensions.<GetFromJsonAsyncCore>d__9`1[[VerusDate.Shared.WeatherForecast[], VerusDate.Shared, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]].MoveNext()
   at VerusDate.Client.Pages.FetchData.OnInitializedAsync()
   at Microsoft.AspNetCore.Components.ComponentBase.RunInitAndSetParametersAsync()
   at Microsoft.AspNetCore.Components.RenderTree.Renderer.GetErrorHandledTask(Task taskToHandle)

www-authenticate: Bearer error="invalid_token", error_description="The issuer 'https://....azurewebsites.net' is invalid"

[carlingkirk]

@drma-dev Yes - unfortunately I had to set it explicitly in AddIdentityServer - see

services.AddIdentityServer(opt =>
{
    opt.IssuerUri = "https://....azurewebsites.net";
})

[drma-tech]

thanks

[mcguireuk]

I was experiencing this issue - the "/signin-google" request was being served from index.html. The fix is to add the endpoint into the list of exclusions in onFetch in service-worker.published.js

In Client\wwwroot\service-worker.published.js:

async function onFetch(event) {
    let cachedResponse = null;
    if (event.request.method === 'GET') {
        // For all navigation requests, try to serve index.html from cache
        // If you need some URLs to be server-rendered, edit the following check to exclude those URLs
        const shouldServeIndexHtml = event.request.mode === 'navigate'
          && !event.request.url.includes('/connect/')
          && !event.request.url.includes('/signin-google')
          && !event.request.url.includes('/Identity/');

        const request = shouldServeIndexHtml ? 'index.html' : event.request;
        const cache = await caches.open(cacheName);
        cachedResponse = await cache.match(request);
    }

    return cachedResponse || fetch(event.request);
}

Yes, worked a treat. but I'd suggest to make the string '/signin-' this way if you add multi providers which usually default to signin-google, signin-microsoft etc these will all work.

[javiercn]

You need to specify the issuer explicitly when deploying to App Service on LInux.

            services.AddAuthentication()
                .AddIdentityServerJwt();

            services.Configure<JwtBearerOptions>(IdentityServerJwtConstants.IdentityServerJwtBearerScheme, options =>
            {
                options.Authority = "https://my-service.azurewebsites.net";
            });

@guardrex can we add a note to the docs?