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
Related
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 am asked to build a self service application on SharePoint where users can search through list of Publically accessible O365 groups. All users should be able to Add and Remove themselves from any specific group.
I planning to use Graph API for this.
Can anyone please provide some documentation or examples.
I would try the following steps to build your above application:
Register an Azure AD application and define an auth workflow which suits your scenario
Make a call from the app to AAD using library like MSAL, get a valid access token
Using the valid token, i will call to access the protected resource like Microsoft Graph with necessary roles/permissions defined.
In your scenario, you will access the Microsoft Groups - then i will refer the Graph API documentation for it.
Implement your business logic to add/remove uses from the Group.
You're good to go!!
You can start by looking at the documentations and examples by going through this documentation : Microsoft Graph API
Microsoft Graph is a RESTful web API that enables you to access Microsoft Cloud service resources.
After you register your app and get authentication tokens for a user or service, you can make requests to the Microsoft Graph API.
It has various features that it supports : Major Services in Microsoft Graph
I am having 404 issues trying to get an inbox of a user through microsoft graph. I think I might recall reading somehwere that Graph API can only access emails stored on 365. Is this the case?
There is currently a preview capability that allows you to access mailboxes, calendars and contacts for on premise data if your exchange infrastructure has configured in an hybrid mode. This takes a few pre-requisites on the infrastructure side and you can learn more about it here
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