[OIDC] - Failed to authenticate - Regression after upgrading to .NET 7

[kbeaugrand]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

My application is a Blazor WebAssembly that is hosted by an ASP.Net server.

I configured my app to get access token for my backend with:

builder.Services.AddOidcAuthentication(options =>
{
    options.ProviderOptions.Authority = settings.Authority;
    options.ProviderOptions.MetadataUrl = settings.MetadataUrl.ToString();
    options.ProviderOptions.ClientId = settings.ClientId;
    options.ProviderOptions.ResponseType = "code";

    options.ProviderOptions.DefaultScopes.Add(settings.Scope);
});

builder.Services.AddApiAuthorization();

builder.Services.AddHttpClient("api", (sp, client) =>
{
    client.BaseAddress = new Uri(builder.HostEnvironment.BaseAddress);
    client.DefaultRequestHeaders.Add("X-Version", "1.0");
}).AddHttpMessageHandler<BaseAddressAuthorizationMessageHandler>();

builder.Services.AddScoped(sp => sp.GetRequiredService<IHttpClientFactory>().CreateClient("api"));

It is working fine with this authentication and authorization flow running in .NET 6.

But after upgrading to .NET 7, I observe that the app fails to authenticate the user.
I receive the auth_code from the IDP and the client request after the token as expected:

N.B: if I disable the additional scope from the configuration. I can see that I have the ID_token, handled by the application, but failed to get token for requesting my backend (obviously)

Expected Behavior

My user should be authenticated. aht the access token handled by the app (as for .NET 6).

Steps To Reproduce

Configure the OIDC With adding an additional scope to the request and specify the authorization code flow:

    options.ProviderOptions.ResponseType = "code";
    options.ProviderOptions.DefaultScopes.Add(settings.Scope);

Exceptions (if any)

No response

.NET Version

7.0.100

Anything else?

No response

[javiercn]

@kbeaugrand thanks for contacting us.

Can you give us more details? Is this happening in development or after publish?

Are there any errors on the console?

Can you tell us exactly what the error is? Is there anything on the screen?

Could you set the login level to debug in Microsoft.AspNetCore.Components.WebAssembly.Authentication? It will print additional information on the console to help troubleshoot the issue.

[ghost]

Hi @kbeaugrand. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[kbeaugrand]

@kbeaugrand thanks for contacting us.

Can you give us more details? Is this happening in development or after publish?

Are there any errors on the console?

Can you tell us exactly what the error is? Is there anything on the screen?

Could you set the login level to debug in Microsoft.AspNetCore.Components.WebAssembly.Authentication? It will print additional information on the console to help troubleshoot the issue.

This is happening during the development

[ghost]

Hi @kbeaugrand. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[javiercn]

Can you tell us exactly what the error is? Is there anything on the screen?

Could you set the login level to debug in Microsoft.AspNetCore.Components.WebAssembly.Authentication? It will print additional information on the console to help troubleshoot the issue.

We still need info on these two questions

[kbeaugrand]

Can you tell us exactly what the error is? Is there anything on the screen?

No error on the screen. No error on the browser console.

Could you set the login level to debug in Microsoft.AspNetCore.Components.WebAssembly.Authentication? It will print additional information on the console to help troubleshoot the issue.

I put these settings to the web assembly `appsettings.json file:

{
  "Logging": {
    "LogLevel": {
      "Microsoft.AspNetCore.Components.WebAssembly.Authentication": "Debug"
    }
  }
}

On the browser I still not have enough information to diagnose. Please see here the console output I have:

[javiercn]

@kbeaugrand thanks for the additional details.

Could you do it like this?
https://github.com/dotnet/aspnetcore/blob/main/src/Components/WebAssembly/testassets/Wasm.Authentication.Client/Program.cs#L15

This should do it, and you should be able to filter then

[kbeaugrand]

Unfortunatly, not more:

[javiercn]

@kbeaugrand thanks for the additional details.

I think something might be missing between the .NET 6.0 and .NET 7.0 update. Did you update the webassembly.authentication package?

Did you clean the bin and obj folders after the update?

[ghost]

Hi @kbeaugrand. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[kbeaugrand]

@kbeaugrand thanks for the additional details.

I think something might be missing between the .NET 6.0 and .NET 7.0 update. Did you update the webassembly.authentication package?

Did you clean the bin and obj folders after the update?

All packages are up to date:

    <PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly" Version="7.0.0" />
    <PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.DevServer" Version="7.0.0" PrivateAssets="all" />
    <PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.Authentication" Version="7.0.0" />
    <PackageReference Include="Microsoft.Extensions.Http" Version="7.0.0" />

I do not need to clean bin and obj since the whole project will be running on docker and build from a fresh environnement...

[javiercn]

@kbeaugrand thanks for the additional details.

I did spot something. At the very least is making it to:
https://github.com/dotnet/aspnetcore/blob/main/src/Components/WebAssembly/WebAssembly.Authentication/src/Interop/AuthenticationService.ts#L256

Could you open AuthenticationService.js put a breakpoint on the method above? We missed adding traces for those two paths.

• It seems like either https://github.com/dotnet/aspnetcore/blob/main/src/Components/WebAssembly/WebAssembly.Authentication/src/Interop/AuthenticationService.ts#L263 or https://github.com/dotnet/aspnetcore/blob/main/src/Components/WebAssembly/WebAssembly.Authentication/src/Interop/AuthenticationService.ts#L270 is being taken.

[kbeaugrand]

@javiercn, How am I supposed to add a break point to the file you mentionned ? I'm using the build package. So I have only the .js file and it is minified... ,)

[javiercn]

@kbeaugrand It's a bit tricky, but you can find the file in the sources (AuthenticationService.js).

Click the unminify button in Edge

And then search for completeSignIn or for completeSignIn-result inside the file.

[ghost]

Hi @kbeaugrand. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[kbeaugrand]

@javiercn , I have the error :

The exception is:

Metadata does not contain property userinfo_endpoint

I already know this issue (because I was facing this issue with java spring security that needs also the userinfo_endpoint to be provided. This is because I'm using Azure AD B2C as the OIDC provider and ADB2C doesn't have the userinfo endpoint in its implementation...
This is quite strange because regarding the OIDC, this endpoint should not be mandatory since, we could use the id_token ...

Do you think I can bypass this issue ?

[kbeaugrand]

@javiercn, I see that the Authentication library is using the v1.11.5 version of oidc-client.

aspnetcore/src/Components/WebAssembly/WebAssembly.Authentication/src/Interop/package.json

Line 29 in 563c42e

"oidc-client": "^1.11.5"

In the meantime, this package is no longer maintained and has been replaced by oidc-client-ts which was a new major version to support now TS (what a pity not to have taken advantage of the v7.0 release to update this package ;) ).

But what is important for me here is that during this migration, the loadUserInfo flag has been changed from true to false: https://authts.github.io/oidc-client-ts/interfaces/OidcClientSettings.html#loadUserInfo.
I would never have encountered this error with the new package ;)

See here some important notes for the migration:
https://github.com/authts/oidc-client-ts/blob/46fe10b1fe78f10d7764e900f19e98eed704d767/docs/migration.md#oidcclientsettings

[javiercn]

I already know this issue (because I was facing this issue with java spring security that needs also the userinfo_endpoint to be provided. This is because I'm using Azure AD B2C as the OIDC provider and ADB2C doesn't have the userinfo endpoint in its implementation... This is quite strange because regarding the OIDC, this endpoint should not be mandatory since, we could use the id_token ...

Do you think I can bypass this issue ?

Thanks for the additional details. Let me make sure I understood. Are you using Microsoft.AspNetCore.Components.WebAssembly.Authentication to talk to an Azure AD B2C instance?

[kbeaugrand]

I already know this issue (because I was facing this issue with java spring security that needs also the userinfo_endpoint to be provided. This is because I'm using Azure AD B2C as the OIDC provider and ADB2C doesn't have the userinfo endpoint in its implementation... This is quite strange because regarding the OIDC, this endpoint should not be mandatory since, we could use the id_token ...
Do you think I can bypass this issue ?

Thanks for the additional details. Let me make sure I understood. Are you using Microsoft.AspNetCore.Components.WebAssembly.Authentication to talk to an Azure AD B2C instance?

Yes right, and I know that I should rather be using the Msal library.
But in my case, I'm developing a Web App that should take an OIDC provider. The AD B2C is only used for demonstration purpose...

[javiercn]

Yes right, and I know that I should rather be using the Msal library.
But in my case, I'm developing a Web App that should take an OIDC provider. The AD B2C is only used for demonstration purpose...

Yes, we do have a dedicated solution for AAD and AAD B2C, which is what we recommend in these cases. Our auth support can't effectively cover the particularities of every auth provider in the land without exposing all the details of the underlying library. We do want to keep the underlying JavaScript library as an implementation detail, as we might change it or even remove it in future versions.

For example, we want to enable you to BYOJ (Bring Your Own JavaScript) so that you can tweak the code to cater to your providers particularities. For example, like in the project below:

https://github.com/javiercn/BlazorWasmMsalSample/tree/main/BlazorWasmMsalSample/Client

In the meantime, this package is no longer maintained and has been replaced by oidc-client-ts which was a new major version to support now TS (what a pity not to have taken advantage of the v7.0 release to update this package ;) ).

We are aware of this fact; however, we have a plan in place in case we need to patch it and we are looking at options here in the future.

[kbeaugrand]

Thank you for this sample @javiercn .

I think I will add my own javascript client (using the oidc-client-ts) as a workaround for this issue.
I saw that you added a new issue regarding the missing logs, good idea, this will help for the future ;)

Since the original issue wasn't due to this project, you might close this issue.

Many thanks @javiercn for your help...

[javiercn]

@kbeaugrand No problem.

It was good for us to dig into this as we found a gap in our logging, that's something we made emphasis to improve on .NET 7.0 as it was one of the biggest issues when trying to troubleshoot problems like this, so this is hopefully a gap we can close.

[javiercn]

Closing since we have a separate issue for the follow-up work.