Description
URL of sample
Describe the bug
In the sample for SSO falling back to MSAL, the getAccessToken() function in ssoAuthES6.js does essentially:
if (useSSO) {
return Office.auth.getAccessToken();
} else {
return getAccessTokenMSAL();
}
The first using Office.auth.getAccessToken will return a JWT containing the user Id details (that then needs to be converted to a Graph access token using OBO flow on the server), but when falling back to getAccessTokenMSAL, the returned JWT is a full MS Graph access token that can be used directly in the add-in (scp has all the Graph rights). Trying to use the JWT returned from MSAL blindly for the OBO flows fails the documented validation rules for a userId JWT (iss starts with https://login.microsoftonline.com, scp=access_as_user etc). Shouldn't both calls return the same thing - i.e. the msal response.idToken rather than response.accessToken?
To Reproduce
- Edit the code in authRedirect.js to return the full response back to the calling add-in
JSON.stringify({ status: "success", result: response.accessToken, accountId: response.account.homeAccountId, response:response })
- Put a breakpoint in the add-in message handler code to see what's in the full response object
- Note that there's an idToken as well as an accessToken
- Note that when decoded, the idToken matches the result of Office.auth.getAccessToken
- Note that the accessToken can be used as the auth token in a rest call to Graph directly, without needing an OBO flow.
Expected behavior
If getAccessTokenMSAL() is supposed to reproduce Office.auth.getAccessToken(), I expected to get the idToken from the MSAL function call.
Environment
- Platform [PC desktop, Mac, iOS, Office Online]: PC desktop
- Host [Excel, Word, PowerPoint, etc.]: Excel
- Office version number: version 2405
- Operating System: Windows 11
- Browser (if using Office Online): ______
Additional context
Activity