IDX40001: Issuer: 'https://xxxxx.b2clogin.com/<TenantId>/v2.0/', does not match any of the valid issuers provided for this application #52283
Assignees
Labels
area-identity
Includes: Identity and providers
Comments
dotnet-issue-labeler
bot
added
the
area-identity
|
Can you confirm that the csproj with I think there is something non-obvious going on considering this was a highly-reported issue in RC1 and RC2, but this appears to be the first report about this with final version of .NET 8 and Microsoft.Identity.Web 2.15.5. I can confirm that Microsoft.Identity.Web 2.15.5 packages on .NET 8 should fix this issue because it pulls in Microsoft.IdentityModel.Validators 7.0.3. However, for some reason, the Microsoft.Identity.Web 2.1.5 NuGet package depends on the older 6.0.33 version of Microsoft.IdentityModel.Validators for projects targeting older .NET versions which I think is a mistake because it can lead to this kind of wonkiness when dependencies target multiple different framework versions. @jmprieur @jennyf19
Agreed. Assuming retargeting to net8.0 and/or explicitly referencing Microsoft.IdentityModel.Validators 7.0.3 doesn't fix your issue, a better workaround in the meantime is likely to set |
|
Thanks for the comment and I am sorry for the delay in replying.
yes, I checked.
2023-11-23_21-32-54.mp4And I tried setting Still, it's failing with the same error. Please find the attached sample project with the configuration. Error log (with .NET 8.0), Working log (with .NET 7.0), I am seeing this (which is to be expected: Security token events return a JsonWebToken), .NET 8.0 .NET 7.0 And .NET 7.0 uses |
|
It appears to be hitting Can you provide the keys and sanitized values for all your |
|
This is the configuration. This configuration is kind of a mess. It's an old project some devs have maintained, I don't think we need all these properties set. Believe only these should be enough. When I changed the But I would think there is still a bug somewhere or some breaking change where Configuration is being handled. |
I'm glad this worked for you. I'm surprised the original configuration worked in .NET 7 with the "MetadataAddress" and "Authority" pointing to different places, but there were some breaking changes we announced when tASP.NET Core authentication handlers switched changed from JwtSecurityToken to JsonWebToken to validated JWTs, so it's not shocking that some behaviors changed in these kind of edge cases. Those wouldn't be as heavily tested as the mainline scenarios. I suspect previously the misconfigured "Authority" was being ignored, and now it is being used for something. https://learn.microsoft.com/en-us/dotnet/core/compatibility/aspnet-core/8.0/securitytoken-events I'm all for improving errors when we get misconfiguration, but it can be difficult to detect. That said, we're open to contributions if there's a simple 100% reliable way to catch misconfiguration early and log them or throw. |
|
yeah, after looking at the config with .NET 7, technically it should have thrown an error in startup.
Will have a look! Thanks @halter73 for your help! |
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Is there an existing issue for this?
Describe the bug
Please note: there are a couple of GitHub issues already created for this, but those are closed as
Resolved.I started seeing this issue after updating an API project to
.NET 8. I am using the followingMicrosoft.Identity.Webpackage.This used to work without any issues with
.NET 7andMicrosoft.Identity.Web: 2.13.3.Expected Behavior
No response
Steps To Reproduce
Exceptions (if any)
.NET Version
8.0.100
Anything else?
Related issues:
#51005
#50725
AzureAD/microsoft-identity-web#2481
Related PR:
#51430
I could get around by allowing all the issuers, but that's not good.
The text was updated successfully, but these errors were encountered: