[Bug] JWK thumprint computation is against RFC 7638

[JasonYang-MSFT]

Library version used

4.57.0

.NET version

.NET 6.0

Scenario

ConfidentialClient - service to service (AcquireTokenForClient)

Is this a new or an existing app?

This is a new app or experiment

Issue description and reproduction steps

The RFC 7638 has defined the JWK thumbprint. When computing the JWK thumbprint, it should use the required members of JWK. https://datatracker.ietf.org/doc/html/rfc7638#section-3

But in PoPAuthenticationScheme.cs, it used all members of JWK for thumbprint generation. https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/blob/80faef7a08b9385709e507fbbfd970d996ed5865/src/client/Microsoft.Identity.Client/AuthScheme/PoP/PoPAuthenticationScheme.cs#L47

Relevant code snippets

No response

Expected behavior

No response

Identity provider

Microsoft Entra ID (Work and School accounts and Personal Microsoft accounts)

Regression

No response

Solution and workarounds

No response

[neha-bhargava]

@JasonYang-MSFT In MSAL we do follow the RFC 7638 standard. See https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/blob/main/src/client/Microsoft.Identity.Client/AuthScheme/PoP/PoPAuthenticationScheme.cs#L143. Are you facing some issue with this?

[JasonYang-MSFT]

Hi @neha-bhargava , RFC 7638 defines that "Only the required members of a key's representation are used when computing its JWK Thumbprint value.". But in PoPAuehnticationScheme.cs, it used all jwk claims for JWK thumbprint computing.

Actually, I am trying to create a PoPCryptoProvider with "x5c" in the JWK. Is that doable with MSAL?

[bgavrilMS]

Yes, it is possible, but not very discoverable. You can create your own SingedHttpRequest (SHR) - here's an example:

https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/blob/main/tests/Microsoft.Identity.Test.Integration.netfx/HeadlessTests/PoPTests.cs#L300