I'm new to the Microsoft Graph API and Azure. I'd like to seek advises to which Microsoft Graph API version I should go with and whether I should be using the "Web API on-behalf-of flow" for my scenario.
I'm building a web services which can store access tokens of multiple Office 365 users from different organisations. This web services can then create web hooks via the Microsoft Graph API to get notifications about calendar appointment changes in these users' accounts, in order to sync these changes to the corresponding appointments stored on our own server.
So it's a mass Office 365 calendar syncing web service in a nut shell.
I have gone through a lot of their GitHub sample projects and managed to create web hooks with the v1 graph subscription API and was able to interact with the calendar of my dev account, all in a sample APS.NET MVC project.
But I'm very confused about the following parts:
Because this web service does not directly provide a UI, so the login UI would be presented by a separate desktop (WPF) client, and I believe when this is done on the client side, I can forward the authenticated access token to my web service to create the web hooks? This sounds like the "Web API on-behalf-of flow" scenario Microsoft described here: https://learn.microsoft.com/en-au/azure/active-directory/develop/active-directory-v2-limitations.
Because this web service needs to create web hooks to multiple Office 365 accounts from different organisations. I'm not sure if this counts as the a multi-tenant scenario. If this is the case, it looks like I can only use the v1 API because the v2 API only allows the web service to receive tokens from an application that has the same application ID (also described in the page linked above).
Microsoft Graph and Azure AD developers could you please shed some light on this part for me? Microsoft isn't doing the best job when it comes to documenting these parts.
Because this web service does not directly provide a UI, so the login UI would be presented by a separate desktop (WPF) client, and I believe when this is done on the client side, I can forward the authenticated access token to my web service to create the web hooks? This sounds like the "Web API on-behalf-of flow" scenario Microsoft described here: https://learn.microsoft.com/en-au/azure/active-directory/develop/active-directory-v2-limitations.
Yes, the scenario is on-behalf-of flow and this flow is not supported for the v2.0 endpoint at present.
Because this web service needs to create web hooks to multiple Office 365 accounts from different organisations. I'm not sure if this counts as the a multi-tenant scenario. If this is the case, it looks like I can only use the v1 API because the v2 API only allows the web service to receive tokens from an application that has the same application ID (also described in the page linked above).
You can only use Azure AD V1 endpoint, because the V2.0 endpoint doesn't support on-behalf-of flow. And here are some steps for using V1 endpoint for your reference:
register 2 apps, one for the WPF(native app) and one for your web service(web app)
enable the multi-tenant for the app for web service
grant the relative Microsoft Graph permission to the web app
set the knownClientApplications for the web app using the clientId of the native app
grant the relative Microsoft Graph permission and web app to the native app
After that, when the users login-in in WPF first time in different tenant, the users can conesent the two apps at same time. And then the service principals of two apps will be register to users' tenant. After that the web service can use the on-behalf-of flow to get the access_token for Microsoft Graph based on the token from native app.
More detail about multi-tenant developing, please refer below:
How to sign in any Azure Active Directory (AD) user using the multi-tenant application pattern
And the code sample below also be helpful:
Calling a downstream web API from a web API using Azure AD
Related
I am new to D365/PowerApps and wonder if i have a Azure Service, (Azure Functions or WebAPP) that is secured with Azure AD tokens (App Registrations).
Can I get an Access Token to my external services using Azure AD from within a plugin step in d365? How do I get such token on behalf of the context the plugin when running as a user.
You'll need to use Flow and compose a http request to get the token:
https://flow.microsoft.com/en-us/galleries/public/templates/edfa8fde25644f149448c8d8cff44699/call-a-web-service-from-a-powerapp/
Here's a good explanation on how to do it using the REST API:
https://stackoverflow.com/a/36982924/1384539
If I understand your question correct,
You have an Azure function APP or external azure service and that is secured by creating Azure AD App with it's roles delegation and so on.
Now you need Access token for this Azure APP with client ID and Client Secret.
We had this similar thing in Dynamics 365 i.e When we wish to use Dynamics 365 Webapi, We need to create Azure AD App and then provide roles delegation so that this app will have access to Dynamics 365.
In Plugin we can give details with client Id and Secret and then generate Token which will be used for Furthure process during plugin Execution.
Note: Most of these plugins we run under System context.
Here are few examples which will lead you to your desired direction.
Most of the Examples also talk about creating Non-Interactive user in Dynamics but in your case that shall not be needed because you are not communicating with Dynamics via (Azure AD App) rather you communicate with Azure functions or so on.
Link 1
Link 2
Link 3
I need to implement authentication for azure web api using azure active directory.
client app(which consumes webapi) may or may not be in azure. how i need to authenticate user, where i should generate token if my app is not in azure(if it is IOS app). authentication should work in all cases even if client app is in azure or not.
Please let me now the best procedure to implement authentication.
You need to define the client app in Azure AD as a native app in the case of a mobile app. Then you define the API there, and add your client permissions to access it. You can optionally customize the available permissions through the API app's manifest in Azure AD. Then when your mobile app opens, you would have to authenticate with Azure AD, and then request an access token for the API. That you can then use to authenticate requests.
I can't answer this question in too great detail because it is quite a large topic and how it is done also depends on your platform. There is a sample app that you can check which does exactly what you want. The whole list of examples for native apps can be found here.
App Service to use different authentication providers Azure Active Directory,Facebook,Google,Microsoft,Twitter.
We can set any type of Authentication/Authorization in the Azure Portal.More info about how to use authentication for API Apps in Azure App Service, please refer to document.
By default, App Service provides authentication but does not restrict authorized access to your site content and APIs. You must authorize users in your app code.
my question is similar to question Multi-Tenant app - OneDrive Business API
but i want my application to access the one drive from tenants of other different azure subscription, is it possible? i understood that if i register my application and mark it as multi-tenant, it will allow me access the tenant in my azure subscription, but if i want to access the tenant using the same application but in different azure subscription whats the way.
What’s kind of authentication flow are you using? Normally, we use the Authorization Code Grant Flow that the user delegates access to a web application. In this scenario, to enables the users on other tenants to login the website and access their Office 365 resource, we only need to enable the multiple-tenant app on the Azure portal.
but if i want to access the tenant using the same application but in different azure subscription whats the way.
It depends on which REST you were using. It is same as we are call the REST API for the single tenant app if we are using the Microsoft Graph to query the OneDrive for business. The endpoint of the list children of a driveItem is still like below no matter which tenant the user login:
GET https://graph.microsoft.com/v1.0/me/drive/root/children
GET https://graph.microsoft.com/v1.0/me/drive/items/{item-id}/children
GET https://graph.microsoft.com/v1.0/me/drive/root:/{item-path}:/children
If you were using the Office 365 REST API, we need to discover the service endpoint. You can refer to here for more detail about Office 365 Discovery Service REST API.
Depending on the permissions that you need normally the tenant admin of the other tenant has to add the application to their own Azure AD. With the newer app model v2 this is quite a lot easier as the admin can simply give consent once in the normal consent screen for the entire tenant. See here for a mor elaborate explanation of how this would work.
I'm creating a Node app that uses OAuth2 to login a user and use the Office365 API to send and receive email, and possibly contacts and calendar events.
I have no need for Azure Active Directory that I know of. However, I am unsure of whether or not I need to register the app with Azure for the OAuth flow.
At first I followed this tutorial, which involves registering the app in the "Application Registration Portal." The OAuth token I receive currently works with the REST API for Outlook. No Azure.
Then I saw this tutorial, which seems to suggest that any app using the Office365 APIs should register an app with Azure. I don't want to do this if I don't have to, mainly because of the cost.
It is not clear to me why I need to sign up for one or the other, and my main concern is that the first tutorial is dated to the point that my app's registration with the "Application Registration Portal" will become deprecated and I will need to switch over to registration with Azure at some point. I have seen plenty of outdated tutorials and information from MS that are not clearly marked as deprecated. Can anyone help clear this up?
Sorry for the confusion. The short answer is that both these methods are still relevant, so none of them are deprecated yet.
Firstly, you're right that you need to register your app to call the Office 365 APIs.
And, you're also right that there are currently two different places to register an app: the App Registration Portal and the Active Directory section under the Azure Management Portal.
Registering on either one of these is enough to get you to a comfortable state where you can call the Office 365 APIs.
However, the convergence of the Outlook.com stack with the Exchange stack means that you are now also able to use the Office 365 Mail, Calendar and Contacts API against consumer Outlook.com accounts in addition to Office 365 accounts. If you wish to take advantage of this, you should register your app in the Application Registration Portal and NOT the Azure Management Portal.
Another advantage of registering through the Application Registration Portal is the support of dynamic permissions scopes. You don't have to specify upfront when you register your app what permissions it requires; rather, you can request permissions at runtime using the scopes parameter.
This new v2 app model for apps registered in the Application Registration Portal is currently in preview. A reason not to register apps in the Application Registration Portal is if they will be using more than just the Mail, Calendar and Contacts APIs. e.g. if your app is also using the OneDrive for Business Files API, you wouldn't be able to request tokens using the v2 app model's endpoint. In that case, you should register your app in the Active Directory section under the Azure Management Portal.
I have the following services
Service1.SomeDomain.com
Service2.SomeDomain.com
Service3.SomeDomain.com
I have a Web application that has a client side script that will talk directly to each of the above services to retrieve information
Web.SomeDomain.com
I also have Native Mobile client applications which also will talk directly to each of the above services
Android
IOS
Windows/Windows Phone
Now this application will be a SaaS solution where customers can sign-up online create their own tenant and then create user accounts for there employees and add the employees to groups and change permissions of those groups.
Now i need a solution that a user can log on to a mobile application or Web and it be allowed to gain access to the above mentioned services depending on there groups permissions, but i want strong separation of each tenant
Looking at the tags it seems you are considering Azure AD. Good choice. Azure AD allows developers to secure their SAAS APIs and Web/Mobile Apps. Azure AD satisfies all the requirements that you've described - it even has client SDKs for the popular platforms.
The following should see you through:
Authentication scenarios supported by AAD (http://msdn.microsoft.com/en-us/library/azure/dn499820.aspx): will answer questions like - how can my mobile app access my multi-tenant web api on behalf of the user, or how can my web app sign-in the user as well as receive a delegated token to access my web api
AAD integrated multi-tenant SAAS application sample (https://github.com/AzureADSamples/WebApp-MultiTenant-OpenIdConnect-DotNet): covers special techniques for multi-tenant apps
Authorization using group membership (https://azure.microsoft.com/en-us/documentation/articles/web-sites-authentication-authorization/): describes how you can perform authorization in your application per the group membership of users.
Enjoy.
Hope this helps.