I'm trying to get an OAuth2 token from Quickbooks. https://developer.intuit.com/app/developer/qbo/docs/develop/authentication-and-authorization/oauth-2.0
I've had a good read for an hour but feel no closer to figuring out how to get a token from the OAuth2 service. Does anyone have clear instruction on how to auth (and handle token refresh) in logic apps using OAuth2?
In the previous Legacy version of Logic Apps there used to be Quickbooks inbuilt Connector but now one of the ways that I found is using Custom Connector.
You can refer to this tutorial if you have not added Quickbooks Custom Connector.
Note : Make sure that the logic app and the custom connector are in the same region
And now for requesting for retrieving and refreshing access tokens we need to save the APIs in the same collection that we have created and upload it to the custom connector.
Another workaround is to get the access tokens locally in Visual Studio by publishing the same code to azure functions and then add the same azure function connector to our logic apps flow.
REFERENCES:
Retrieve an Access Token - Box Developer Documentation
c# - Is there a simple way to access the Quickbooks API using OAuth2? - Stack Overflow
IvAlex1986/QuickBooks.Net: QuickBooks API wrapper for .NET (github.com)
I'm trying to help someone to ingest Office 365 Alerts with the Graph Security API. This requires SecurityEvents.ReadAll as minimum permission. The docs mention that the permission setting is done in the Microsoft Graph API Explorer (see e.g. this blog). However, the account admin insists on setting the permissions using Azure AD. The question is how that is actually done. Azure AD / Enterprise Applications / Graph Explorer apparently doesn’t list any permissions. Would anyone know how to achieve this?
Many thanks!
If you want to test Graph Security API in Microsoft Graph Explorer, your just need to set SecurityEvents.Read.All in Microsoft Graph Explorer.
If you want to call Graph Security API in your app, you should set SecurityEvents.Read.All in the app registered on Azure portal.
You could refer to Authentication and authorization basics for Microsoft Graph to learn more about how to handle the permissions and authorization to call Microsoft Graph API.
We are developing an Android Application using MS Graph API to access Exchange Online Calendar info.
I know several enterprises are strict about how the exchange data is shared and may restrict access for our app using MDM or other exchange controls.
I need to understand what changes IT Administrators could do to block access to an app that uses MS Graph and OAuth2? I need this info so that we can test our setup and be better prepared for it.
Thanks
We have a web application that uses the Microsoft Graph API and Outlook REST API. We implemented a code authorization flow. This means that its our web server that handles requests to Microsoft Graph and Office 365 APIs.
We are based in Europe (hosted within Azure). Now we would like to replicate our infrastructure overseas to serve a better end-user experience.
What would be the possible strategies regarding these MS APIs.
Is there a geographical affinity mechanism? Is it based on the geo localization of the requesting app (us) or the localization of the tenant (we have users everywhere)? Staying within Azure Data centers will provide better performance? What would be Microsoft recommendations?
I asked about this, and the answer was that yes, there is an affinity system based on the location of your app. It should hit the instance of Graph or Outlook that's closest to you.
Regarding running in Azure, we are continuously optimizing latencies for Microsoft-owned Azure-based apps & services to access the Graph and Outlook APIs. This work would accrue to all apps and services running in Azure.
I configured an application on AzureAd to be multi-tenant, I chose to require all the permissions for Windows Azure Active Directory and Office 365 Exchange Online.
I can get a user to grant permissions, get access tokens, refresh them, OAuth works for me. I always used the "common" keyword instead of the tenant ID, because my app is multi-tenant.
Now, I would like to have (CRUD) access to a user's Mail, Contacts and Calendar with this token. Here is my problem: I am completely lost in all the possible API endpoints. Should I use: graph.windows.net, outlook.office365.com, graph.microsoft.com? This page seems to suggest that graph.microsoft.com is the Swiss army knife that would serve my purpose, but somehow I cannot find a doc that allows me to find the info I'm looking for. Plus, it seems under development and maybe too incomplete for what I want.
If I make queries against outlook.office365.com, I've got a 401 error.
If I put my access token in this token analyzer, it seems healthy although the scope field only shows the permissions I set in the AzureAd portal for Windows Azure Active Directory, not Office 365 Exchange Online.
I am kind of lost, any help would be welcome...
You have a choice:
Call the separate service apis - Your problem is that you acquired a token to call AAD, and then tried to use that to call Outlook - you need to make a separate call to acquire a token for outlook.office365.com through ADAL or through the token endpoint directly. The token acquired for AAD Graph can ONLY be used against AAD Graph. Similarly the token acquired for Outlook can ONLY be used against Outlook APIs.
Just to clarify - Azure AD OAuth can protect/secure multiple web APIs, including O365 APIs, Azure AD Graph, Azure Resource Management APIs, your own APIs and the new O365 unified API. In the first access token request, you specify the first resource you want/need to call. It doesn't have to be AAD Graph - i.e. it's not the default AFAIK. Based on what is consented to, you have the ability to request additional access tokens using the (multi-resource) refresh token. Vittorio's blog post which you link to in your comments does a great job explaining this.
Call the O365 unified API (which is in preview) and IS documented. See below. The beauty of the unified API is that you only need to acquire a token to call graph.microsoft.com and ALL the entities on that endpoint are available to you AND more. It removes the siloed nature of #1, and the requirement to get and manage multiple access tokens to call these different API endpoints. However #1 is currently GA, and the unified API is preview only at this time.
For more on #2 please see https://msdn.microsoft.com/en-us/office/office365/howto/office-365-unified-api-overview and search for "unified" in the list of samples here: https://msdn.microsoft.com/en-us/office/office365/howto/starter-projects-and-code-samples
We are working on improving the unified API documentation. If you are making pure REST calls, then I recommend starting out with the API explorer (and try things like https://graph.microsoft.com/beta/me/events and https://graph.microsoft.com/beta/me/messages to get your calendar events and mail messages), OR the API sandbox (which can show you JS code snippets, and allow you to test your own easily enough). As you can see on the REST examples, to access mail and calendar features in the unified APIs, you should be able to swap the service roots from Outlook to the unified API ie - https://outlook.office365.com/v1.0 -> https://graph.microsoft.com/beta. On the JS sample - we will be adding more capabilities here and additional samples.
NOTE: Personal contacts available in outlook.office365.com are not available in the unified API yet.
Hope this helps