Multiple SPFx web parts using Graph API on the same page, is this possible?

%3CLINGO-SUB%20id%3D%22lingo-sub-103333%22%20slang%3D%22en-US%22%3EMultiple%20SPFx%20web%20parts%20using%20Graph%20API%20on%20the%20same%20page%2C%20is%20this%20possible%3F%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-103333%22%20slang%3D%22en-US%22%3E%3CP%3E%3CSTRONG%3EScenario%3C%2FSTRONG%3E%3A%20You%20have%20two%20SPFx%20web%20parts%20that%20users%20can%20add%20on%20a%20page.%20One%20web%20part%20is%20fetching%20user%E2%80%99s%20calendar%20events%2C%20another%20one%20is%20fetching%20user%E2%80%99s%20emails.%20Both%20use%20Graph%20API%20and%20both%20need%20different%20rights.%20User%20authenticates%20the%20first%20one%20and%20browser%20gets%20a%20token%20with%20rights%20to%20read%20his%2Fher%20calendar%20event.%20Then%20user%20tries%20to%20authenticate%20the%20second%20web%20part%20but%20according%20to%20what%20I%20have%20read%20from%20%3CA%20href%3D%22https%3A%2F%2Fdev.office.com%2Fsharepoint%2Fdocs%2Fspfx%2Fweb-parts%2Fguidance%2Fcall-microsoft-graph-from-your-web-part%23limitations-when-using-adal-js-with-sharepoint-framework-client-side-web-parts%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%22%3Ehere%20%3C%2FA%3Ethis%20will%20not%20work%20because%20there%20already%20is%20a%20token%20for%20Graph%20API%20with%20rights%20only%20to%20read%20the%20calendar%20events.%3C%2FP%3E%3CP%3E%3CSTRONG%3EQuestion%3C%2FSTRONG%3E%3A%20Is%20it%20possible%20to%20%E2%80%9Cflush%E2%80%9D%20the%20token%20(with%20Storage.removeItem%20for%20example%3F)%20that%20is%20already%20there%20in%20the%20browser%20and%20get%20a%20new%20one%20with%20a%20broader%20scope%20for%20both%20reading%20the%20users%20calendar%20%2B%20reading%20his%2Fher%20emails.%20Could%20this%20be%20easily%20done%2C%20so%20that%20every%20time%20we%20are%20adding%20a%20new%20web%20part%20that%20is%20using%20Graph%20API%20to%20a%20page%20%2C%20we%20could%20check%20if%20there%20already%20is%20a%20token%20associated%20with%20Graph%20API%20and%20if%20there%20is%20one%20with%20not%20enough%20rights%20for%20the%20new%20web%20part%2C%20we%20could%20flush%20that%20token%20and%20ask%20for%20a%20new%20one%20with%20more%20rights%20(the%20old%20rights%20%2B%20the%20new%20rights%20needed).%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-103470%22%20slang%3D%22en-US%22%3ERe%3A%20Multiple%20SPFx%20web%20parts%20using%20Graph%20API%20on%20the%20same%20page%2C%20is%20this%20possible%3F%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-103470%22%20slang%3D%22en-US%22%3EFollowing%20this%2C%20I%20ultimately%20want%20to%20do%20the%20same%20thing.%20Right%20now%20I%20am%20doing%20this%20on%20a%20classic%20page%20with%20multiple%20script%20editor%20web%20parts%2C%20trying%20to%20learn%20SPFX%20currently.%3CBR%20%2F%3E%3CBR%20%2F%3EI've%20got%20one%20function%20that%20gets%20the%20token%2C%20then%20once%20I%20have%20verified%20I%20have%20the%20token%2C%20I%20call%20the%20various%20functions%20that%20make%20the%20graph%20calls%20and%20populate%20the%20results%20in%20each%20SEWP.%20Havent%20figured%20out%20how%20to%20mimic%20this%20in%20SPFX.%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-103456%22%20slang%3D%22en-US%22%3ERe%3A%20Multiple%20SPFx%20web%20parts%20using%20Graph%20API%20on%20the%20same%20page%2C%20is%20this%20possible%3F%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-103456%22%20slang%3D%22en-US%22%3E%3CP%3EGoing%20to%20reply%20to%20myself%20%3AD%3C%2Fimg%3E%20How%20about%20if%20the%20token%20handling%20etc.%20for%20the%20whole%20page%20(all%20the%20web%20parts)%20was%20done%20with%20a%20SharePoint%20Framework%20extension%20(Application%20customizer).%20So%2C%20the%20SharePoint%20Framework%20extension%20would%20handle%20all%20the%20authorization%20request%20and%20keep%20track%20of%20the%20Graph%20API%20rights%20needed%20for%20all%20of%20the%20web%20parts%20the%20users%20adds%20to%20the%20page%3F%20Could%20this%20be%20done%3F%20Is%20the%20SharePoint%20extension%20capable%20of%20doing%20this%3F%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E
Occasional Contributor

Scenario: You have two SPFx web parts that users can add on a page. One web part is fetching user’s calendar events, another one is fetching user’s emails. Both use Graph API and both need different rights. User authenticates the first one and browser gets a token with rights to read his/her calendar event. Then user tries to authenticate the second web part but according to what I have read from here this will not work because there already is a token for Graph API with rights only to read the calendar events.

Question: Is it possible to “flush” the token (with Storage.removeItem for example?) that is already there in the browser and get a new one with a broader scope for both reading the users calendar + reading his/her emails. Could this be easily done, so that every time we are adding a new web part that is using Graph API to a page , we could check if there already is a token associated with Graph API and if there is one with not enough rights for the new web part, we could flush that token and ask for a new one with more rights (the old rights + the new rights needed).

2 Replies

Going to reply to myself :D How about if the token handling etc. for the whole page (all the web parts) was done with a SharePoint Framework extension (Application customizer). So, the SharePoint Framework extension would handle all the authorization request and keep track of the Graph API rights needed for all of the web parts the users adds to the page? Could this be done? Is the SharePoint extension capable of doing this? 

Following this, I ultimately want to do the same thing. Right now I am doing this on a classic page with multiple script editor web parts, trying to learn SPFX currently.

I've got one function that gets the token, then once I have verified I have the token, I call the various functions that make the graph calls and populate the results in each SEWP. Havent figured out how to mimic this in SPFX.