I am developing a SPFX webpart. I need to show the planner task of current user using Graph API. I am able to to pull data Using ADAL. As webpart rendering in sharepoing context we can execure all query with user permission so why we do perform query with APP permision. So i am expecting here some thing like "spHttpClient" for graph API, which will handle the token itself user will only define the end point.
Yeah, I am also interested in using Microsoft Graph from SPFX app / webpart. The context with permission should be resolved by the framework. Any idea how and when this will be done?
I'm not sure this is connected but do I right understand that currently there is a way of using ADAL from SPFx web part using angular? In the guideline here and here it is explained how to add ADAL to the web part but it all starts with installing Angular. Does this mean Microsoft does not provide corresponding tools for JQuery/ReactJS development?
Microsoft have deprecate graph GQL api while access to graph api itself from spfx is quite a headache. Is there any workaround on accessing graph api with SSO via sharepoint?
@jonathanhotono GQL != MS Graph. GQL is Office Graph which is just one of the capabilities of MS Graph.
@waldekmastykarz, so is there a guide for using MS Graph from SP Framework? Should developers use AngularJS?
Hi @waldekmastykarz Thanks, I do clearly understood that gql is a capability of ms graph that can be accessed via sharepoint search. However this feature will be removed by 31 august and i have been using this api for quite on some of my apps(which all suddenly went down on 20 june). In the link: https://msdn.microsoft.com/en-us/office/office365/howto/query-office-graph-using-gql-with-search-rest-api
Clearly stated that we need to start to migrate to graph api before 31 aug while there currently isn't any stable/better SSO solution (not sure whether the GraphHttpClient api works since i got permission issue while testing it).
@shurick81 @waldekmastykarz
Not sure whether you guys have seen this but please check to this thread for the preview GraphHttpClient
https://github.com/SharePoint/sp-dev-docs/issues/621
There are two main ways of using MS Graph from SPFx. First, you can use the GraphHttpClient. It's definitely the easier one of the two approaches but also the most limited one. At this moment it offers access to only two scopes which limits you with regards to what information you can retrieve.
Then, you can use ADAL JS and register an AAD app with whatever MS Graph permissions you need. There are some considerations that you should take into account, like the need to specify the return URL of each web part page in the AAD app, but until more scopes are exposed through the GraphHttpClient, this is an option you should definitely consider if you want to work with the MS Graph in SPFx. It's the easiest to use ADAL JS in AngularJS but with a little bit more work you can use ADAL JS in any JS library.
With regards to the deprecation of GQL and migration to the MS Graph: the APIs exposed through the MS Graph are not even close to what you could've achieved with the GQL. With that, you can't really migrate your existing solutions as there are no APIs in the MS Graph to migrate them to. The only thing you can do, is to remove the Office Graph part from your application until more Office Graph capabilities are added to the MS Graph.
Thanks @waldekmastykarz this is quite disappointing that microsoft removed the api without providing us with a working solution. Got a few custom made apps that implements gql for my clients ans now i have to tell them that some of their favourite feature will be stripped out soon..
Also with ADAL JS, is this solution requires users to be redirected for another authentication process? Or will it be seamless SSO?
@jonathanhotono Did you ever get an answer to the below?
"Also with ADAL JS, is this solution requires users to be redirected for another authentication process? Or will it be seamless SSO?"
Also with ADAL JS, is this solution requires users to be redirected for another authentication process? Or will it be seamless SSO?
Currently, this is separate authentication process, so users is again prompted to authenticate.
That is the reason, why I am asking how to re-use the existing authentication / token, so we should not use ADAL or MSAL for auth again...
@patrickabel @hkusulja I did managed to authenticate to graph api using Azure AD app using NodeJS daemon script. https://github.com/jonathanhotono/nodejs-apponlytoken-rest-sample , however client ID and client SECRET will still be exposed, and not sure if there is any CORS issue to login.windows.net if we perform AJAX call against this login endpoint.
Note: It seem that we still need to use ADAL, but have to re-auth again once expired.
@jonathanhotono you should use only front-end / JavaScript / TypeScript development where code executes completly on client/browser, so you have to use ADAL with "Implicit flow" authentication, there is no secrets in that auth flow that are exposed, only application id and app url which are both public.
We are not talking about serverside/backend solutions (Node.js, PHP, C# .NET etc.) that have other options for OAuth / ADAL authentication, including your mentioned private secret which should never be exposed to the client.
@hkusulja if I use ADAL with "implicit flow" authentication, won't my application require each user to grant permission for it's use? I'm working on a background processor for auditing/data-collection purposes and was hoping there was a pattern for reaching into the graph API via the SPFx without requiring user interaction. Any ideas?
Well, this topic is about using SharePoint Framework / SPFX and Modern pages, to interact with Microsoft Graph using ADAL and implicit flow, without having to authenticate again.
Of course if you use your own server backend and Azure AD App, then you need require token for it.
Wondering about how that approach can scale?
Take this scenario:
I make a cool spfx web part that I want to deploy to the world. My part needs access to MSGraph with a scope that is not one of the default two provided to by a SharePoint token.
Since the oauth implicit flow redirects to the return URL obtained from the application registration, how can that be portable?
If the webpart is bundled with a different client id for each tenant, then alright, it works, but how does that scale? Also, even that would require a dedicated site collection to act as a redirect target to receive the token and thus needs to have the webpart in it to host MSAL so it can save the token and close the popup window.
According to MSFT :
The consequences of this are that the URL of every page with web parts using OAuth implicit flow must be registered with Azure AD.
So this leaves no way for a MSGraph using webpart to be distributed at large?
Am I missing something here?
The recently announced API permissions, introduced with SPFx 1.4.1, solve this problem. First of all, in your package, you can request which permissions your solution needs. When deploying the package, tenant admin will see the permission requests you included in the package and can approve or decline them.
Second of all, the new MSGraphClient, alleviates you from having to manage an AAD app yourself. Instead, you can connect to an AAD app provisioned by Microsoft, which will provide you with a valid access token, assuming that tenant admin granted the necessary permissions. All this is encapsulated in the MSGraphClient and you don't need to worry about obtaining an access token yourself. More info @ https://docs.microsoft.com/en-us/sharepoint/dev/spfx/use-aadhttpclient
Closing this issue. Thank you @waldekmastykarz !
@thespooler can you please tell me how do you distribute your SPFX app with Graph API access to the world. Also, do you use SharePoint Store / App Source? I think SPFX still does not support the Store, right?
@hkusulja currently there is no store for SharePoint Framework solutions, so you would have to have your own mechanism for distributing it to your customers.
@waldekmastykarz Do you have an estimate for when then the MSGraphClient can be used on production tenants? Currently that is not possible, it throws an error.
MSGraphClient is still in preview and at this moment there is no public release date.
Hello,
Is it possible to use Miocrosoft Graph API from jquery/JS from a content editor or script editor web part? If yes, any pointers on how to do it?
Yes, you could do that. You would need to implement the OAuth implicit flow to obtain a valid access token. To get some pointers you could look at https://github.com/waldekmastykarz/office-mygroups-react. It's not a 100% match for what you're looking for but it has all the necessary ingredients like using ADAL JS to get MS Graph access token and the AAD configuration steps. Hope it helps.
Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues
Most helpful comment
There are two main ways of using MS Graph from SPFx. First, you can use the GraphHttpClient. It's definitely the easier one of the two approaches but also the most limited one. At this moment it offers access to only two scopes which limits you with regards to what information you can retrieve.
Then, you can use ADAL JS and register an AAD app with whatever MS Graph permissions you need. There are some considerations that you should take into account, like the need to specify the return URL of each web part page in the AAD app, but until more scopes are exposed through the GraphHttpClient, this is an option you should definitely consider if you want to work with the MS Graph in SPFx. It's the easiest to use ADAL JS in AngularJS but with a little bit more work you can use ADAL JS in any JS library.
With regards to the deprecation of GQL and migration to the MS Graph: the APIs exposed through the MS Graph are not even close to what you could've achieved with the GQL. With that, you can't really migrate your existing solutions as there are no APIs in the MS Graph to migrate them to. The only thing you can do, is to remove the Office Graph part from your application until more Office Graph capabilities are added to the MS Graph.