How can I get access token for multiple resources based on sample Office-Add-in-Microsoft-Graph-React about office-add-in-samples HOT 16 OPEN

@tiwarigaurav Please ask this question on on https://stackoverflow.com/. Tag your question with office-js or outlook-web-addins

This repo is only for questions related to its samples.

from office-add-in-samples.

@Rick-Kirkham - not sure why this was closed. My question specifically relates to the sample "Office-Add-in-Microsoft-Graph-React"

Using this sample I can get the Graph Access Token just fine and everything works.

My Question is - How can I get access token for multiple resources using the msalInstance.acquireTokenSilent(scope) within the office-apis-helpers.ts file?

The main idea is to use the login popup once to initiate the msalinstance and for any subsequent scopes/resources (or when the initial access token expires) use the acquireTokenSilent method - so that the user does not need to click the login button again to get another token.

from office-add-in-samples.

@davidchesnut Please let me know if you need more details in investigating our issue. We anticipate quick response and resolution to above.

from office-add-in-samples.

@tiwarigaurav I leave it to @davidchesnut to decide, but I don't think this "relates" to the sample in the way that is intended. The sample doesn't have a bug and your question is not about the sample as it is. You are asking for help for a distinctly different scenario. You really should ask this question on Stack Overflow.

from office-add-in-samples.

@Rick-Kirkham - what I am trying to imply is that the sample provided does not work in real-world scenarios, neither can we make it work in real world.

As per Microsoft documentation the -

Office dialog API, specifically the displayDialogAsync method is a completely separate browser instance from the task pane, meaning:

• It has its own runtime environment and window object and global variables.
• There is no shared execution environment with the task pane.
• It does not share the same session storage (the Window.sessionStorage property) as the task pane.

Which means (my interpretation) is that we cannot use msalInstance.acquireTokenSilent(scope). And that every time we need to get a new access token we will need the user to click the login button.

With the above statement I can safely say that the sample provided under OfficeDev -> Office-Add-in-samples -> auth -> Office-Add-in-Microsoft-Graph-React cannot be used in real world (or the concept cannot be reused in real world). Unless I am missing something quite obvious which is why I have posted this question.

from office-add-in-samples.

@davidchesnut - any updates for us on this issue?

from office-add-in-samples.

Hi @tiwarigaurav,

It appears you are looking for information on how to use MSAL in react to get additional scopes beyond the one used in this sample.

This sample in the Azure Active Directory documentation may be better aligned to help with your question. Specifically, the scopes are what you pass in to specify what API/scope of access you want granted in the token, which you can find in the 'Acquire token for an API' part of that sample. If you are still having issues with MSAL and accessing resources using it, the best spot to ask would be Stack Overflow using msal and msal.js tags.

Closing the issue on this sample as your question is about MSAL usage - if you find issues with MSAL.js you can more information on their GitHub page/open an issue there.

from office-add-in-samples.

@mattgeim - It is possibly my fault - the title of the question is a bit misleading. Let's take out the multiple scopes part out of the equation and concentrate on this sample - OfficeDev -> Office-Add-in-samples -> auth -> Office-Add-in-Microsoft-Graph-React

I am trying to imply is that the sample provided does not work in real-world scenarios, neither can we make it work in real world. i.e. every time we need to get a new access token we will need the user to click the login button and show the dialogue popup.

Perhaps this should be raised as a bug in the sample?

Note: from what I have gathered so far is that "Office Add-In + React + MSAL.JS + Graph API" will not work cross platform and cross browsers.

from office-add-in-samples.

Thanks for the response clarifying @tiwarigaurav.

This sample doesn't do SSO, its MSAL based and isn't trying to reduce sign-ins. If you are interested in SPA flows for SSO, you can read more about it here: https://learn.microsoft.com/en-us/azure/active-directory/develop/msal-js-sso please note this is not related to add-ins, but rather SSO flows and MSAL.

This sample works for what it should do, but I will happily take your feedback and discuss with our team on ways to improve on clarity for others in the future - thank you for the feedback!

from office-add-in-samples.

@mattgeim - this isn't about SSO with Office Add-Ins.

My feedback is that this sample Office-Add-in-Microsoft-Graph-React will NOT work in real world. There is a bug with Office Add-Ins Dialogue API I found this on MS documentation.

This sample should clearly state this in on the wiki page.

from office-add-in-samples.

Hi @tiwarigaurav, If you want to use MSAL caching so that you don't have to pop up a dialog for every API call, see getAccessTokenMSAL in the Office-Add-in-NodeJS-SSO sample. You can also see how to send the home account ID from the dialog box in the handleResponse method. This is all MSAL code based on the Microsoft identity platform, and nothing specific to Office JS. In the comments for authConfig.js and authRedirect.js there are links to the original MSAL samples those are based on. However it is possible there are some Office platform/webview combinations that might not work with this MSAL caching mechanism (in which case it defaults back to popping up the auth dialog.)

I can look into updating the React sample down the road with the caching code. Are there any other issues you spotted in the sample?

Thanks!
David

from office-add-in-samples.

@davidchesnut - thanks for responding. I tried this and it does NOT work.

I tried your suggestion with the below code (in my app's login.ts file):

     let msalInstance: PublicClientApplication = new PublicClientApplication({
      auth: {
      authority: "https://login.microsoftonline.com/organizations/",
      clientId: "xxxxxxx-xxxxxxx-xxxxxxx-xxxxxxx-xxxxxxx",
      navigateToLoginRequestUrl: false
      },
      cache: {
      cacheLocation: "localStorage",
      storeAuthStateInCookie: false,
      },
    });
    const authParamsGraph = {
      account: messageFromDialog.result.account,
      scopes: ["https://graph.microsoft.com/.default"]
    };
    console.log(messageFromDialog.result.account.homeAccountId);
    const accByHomeId = msalInstance.getAccountByHomeId(messageFromDialog.result.account.homeAccountId);
    console.log(accByHomeId);
    msalInstance.setActiveAccount(
      msalInstance.getAccountByHomeId(
        messageFromDialog.result.account.homeAccountId
      )
    );

With the above I was able to pass the homeAccountId from the Dialog box to the app but msalInstance.getAccountByHomeId(messageFromDialog.result.account.homeAccountId) returns null.

As per my research there is a bug with the Office Dialog API in which - the web add-in's Task Pane and Dialog Box do not share the same Local Storage. So, when we initialize a new msal instance in the app it has nothing in common with the msal instance from the Dialog box so the getAccountByHomeId will fail.

Note: I am testing this on Outlook desktop app running on Windows

from office-add-in-samples.