Token successfully obtained using MSAL is rejected as an invalid claims token when used with protected API

Core Library

MSAL.js v2 (@azure/msal-browser)

Core Library Version

2.14.2

Wrapper Library

Not Applicable

Wrapper Library Version

None

Description

Working with Microsoft’s WVD SDK team and trying to use the MSAL.js library for authentication with WVD. Have successfully obtained an access token with MSAL, but when passing this token to the WVD SDK API for retrieving workspace feeds, the token is rejected with the error “Invalid Claims Token”. I have confirmed that the token is a properly formatted JWT and is consistent with the data originally submitted to obtain it.

The WVD SDK team indicated that I should create this ticket before they can get the identity team involved in helping me work through this issue.

Note that the client application using MSAL is built on top of CEF. It follows a similar approach as that used by the Microsoft WVD SDK team’s Electron client (except that the Electron client not using MSAL to obtain a token at this time).

Error Message

No error message received from MSAL. WVD SDK error code is “InvalidClaimsToken”.

Msal Logs

[0601/122424.251033:INFO:CONSOLE(8)] “MSAL: [Tue, 01 Jun 2021 17:24:24 GMT] : : @ : Info - Emitting event: msal:loginStart”, source: https://fp/static/wvd_client_login.html (8) [0601/122437.331819:INFO:CONSOLE(8)] “MSAL: [Tue, 01 Jun 2021 17:24:37 GMT] : : @ : Info - Emitting event: msal:handleRedirectStart”, source: https://fp/static/wvd_client_login.html (8) [0601/122437.622669:INFO:CONSOLE(8)] “MSAL: [Tue, 01 Jun 2021 17:24:37 GMT] : : @ : Info - Emitting event: msal:loginSuccess”, source: https://fp/static/wvd_client_login.html (8) [0601/122437.622809:INFO:CONSOLE(8)] “MSAL: [Tue, 01 Jun 2021 17:24:37 GMT] : : @ : Info - Emitting event: msal:handleRedirectEnd”, source: https://fp/static/wvd_client_login.html (8)

MSAL Configuration

{
  auth: {
    clientId: "a85cf173-4192-42f8-81fa-777a763e6e2c",
    authority: "https://login.microsoftonline.com/fpttctest1.onmicrosoft.com/",
    redirectUri: "https://www.wvd.microsoft.com/webclient"
  }
}

Relevant Code Snippets

let msalInstance = new msal.PublicClientApplication(msalConfig);

msalInstance.setLogger(new msal.Logger({loggerCallback: loggerCallback, level: msal.LogLevel.Verbose, piiLoggingEnabled: false}));

// CEF ENSURES HASH RECEIVED FROM AUTH SERVER IS PASSED THROUGH TO THIS PAGE ON PAGE LOAD (THIS TECHNIQUE IS USED BY MICROSOFT'S ELECTRON-BASED WVD SDK REFERENCE CLIENT)
if (window.location.hash) {
  msalInstance.handleRedirectPromise().then((response) => {
    console.log(`access token: ${response.accessToken}`); // TOKEN CONFIRMED TO BE VALID JWT WITH LOGIN ID CONSISTENT WITH USER THAT ENTERED CREDENTIALS

    // THIS IS WHERE WE WOULD MAKE WORKSPACE FEED REQUEST USING WVD SDK WITH ACCESS TOKEN
  });                  
}

Reproduction Steps

1. instantiate new PublicClientApplication object with MSAL configuration
2. call setLogger on this new instance to capture verbose MSAL logs
3. call loginRedirect({}) on MSAL instance from step 1
4. CEF-based native client code retrieves access code (?code=xxx) from WVD web client navigation
5. Access code passed as hash portion of URL when loading page (which initializes the MSAL instance from the same configuration information as in step 1) and when present handleRedirectPromise() is called on the MSAL instance
6. when promise resolves, the accessToken property in the response object is used to request WVD workspace feeds with the WVD SDK
7. step 6 fails with an “invalid claims token” error

Expected Behavior

token with valid format obtained from MSAL is able to be used with the WVD SDK successfully

Identity Provider

Azure AD / MSA

Browsers Affected (Select all that apply)

Other

Regression

No response

Source

External (Customer)

[pkanher617]

Got it, when you have more information please feel free to update here, we can help from our end.

[nbanek-fp]

@pkanher617, Brian Taintor on Microsoft’s WVD SDK team asked me to create this ticket as part of an ongoing investigation into this issue that we are conducting jointly with his team. We’ve been working with the WVD SDK team for a couple months on the problem and they believe the next step to be taken is for us to work with the MS Identity team. Brian’s indication was that this ticket needed to be filed here as a prerequisite for that conversation to get started. With that said, I will pass the question about the required set of claims on to that team. We have no insight into claims that SDK may require, so maybe there is something to this.