I'm not sure this answers your particular problem but I recently came across the same (or a very similar) problem when using Azure AD B2C to sign in users and retrieve a Jwt access token to use as a bearer token providing access to the API's in my application. The reason I cannot be sure it's the same problem is that our applications do not use any of the Microsoft libraries, and instead use either Spring Security in Java or React components supporting OAuth2.0.
I found the problem to be as follows:
- The authorisation and token endpoints are published in paths under of https://<b2c-tenant-identifier>.b2clogin.com/<b2c-tenant-identifier>.onmicrosoft.com/<policy-name>
- Similarly, the metadata endpoint is published under the same location https://<b2c-tenant-identifier>.b2clogin.com/<b2c-tenant-identifier>.onmicrosoft.com/<policy-name>/v2.0/.well-known/openid-configuration
When I use these endpoints to retrieve an access token, the "issuer" claim in the token is in the form: https://login.microsoftonline.com/<b2c-tenant-guid>/v2.0
The standard Jwt decoder implementation in Spring security will then look for metadata in various paths under the ISSUER location - as specified by https://datatracker.ietf.org/doc/html/rfc8414#section-3
As the metadata is not located under this issuer location, it cannot find it, and therefore cannot find the keys required to validate the signature of the Jwt.
I solved this problem by configuring the JWKS_URL for my Azure B2C tenant directly into my application, and specifying this location to the decoder rather than expecting it to discover the URL from the metadata.
Hope this helps anyone struggling with the same problem.