Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

In SSO fallback, getAccessTokenMSAL() returns a different result than Office.auth.getAccessToken() #789

Open
CBullen2 opened this issue Jun 7, 2024 · 0 comments

Comments

@CBullen2
Copy link

CBullen2 commented Jun 7, 2024

URL of sample

Office-Add-in-NodeJS-SSO

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

  1. 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 })
  1. Put a breakpoint in the add-in message handler code to see what's in the full response object
  2. Note that there's an idToken as well as an accessToken
  3. Note that when decoded, the idToken matches the result of Office.auth.getAccessToken
  4. 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants