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.
Related
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
I see the following message "To view and manage your registrations for converged applications, please visit the Microsoft Application Console." (screenshot) under AD app registration screen in Azure Portal? what is this all about?
Clicking on that link takes me to a different page where I can perform App Registrations, trying to understand the difference between registering in Azure portal and in other external site.
It appears that Microsoft has released a new feature in Azure Authentication to support Microsoft account and Organisation account authentication in a single Azure Active Directory v2 authentication endpoint.
Here is the link for the complete article https://blogs.technet.microsoft.com/enterprisemobility/2016/02/23/for-developers-the-first-use-cases-of-the-converged-microsoft-account-and-azure-active-directory-programming-model-are-now-ga/
Key extract from the article
Today I am excited to tell you that the first set of uses cases supported by the Azure Active Directory v2 authentication endpoint are generally available. With the v2 endpoint, you can now build applications that let users sign in using their Azure AD backed work, or school account, or their Microsoft Account using a single button.
Federated sign in has many benefits. If you accept sign ins from Microsoft, you can:
Store fewer passwords in your application and make yourself a less attractive target for attackers,
Avoid your users having to remember another name and password,
Give your users a single sign on experience if they are already signed in to Windows 10, Office 365, Outlook.com, OneDrive, or other Microsoft property,
Seamlessly integrate a user’s data such as their calendar or contacts,
Take advantage of Microsoft’s advanced anomalous sign in detection technology, and let us help you defend your user’s accounts.
With federated sign in, Microsoft can handle identity management for you. With the Azure Active Directory v2 endpoint, we’re making this easier than ever before. Until now, building an application that worked with both Microsoft work and school accounts and Microsoft personal accounts required adding two technology stacks to your application: the Microsoft account stack and the Azure Active Directory stack. We’re bringing these two systems together so that you can integrate once and enable both kinds of users to sign in using a single button:
This converged programming model is exposed by the Azure AD v2 authentication endpoint. Today we are excited to announce GA of the first two scenarios supported by the v2 endpoint:
I'm developing an application that incorporates the Skype for Business Online Web SDK. I've noticed that it is not possible to access information about the signed in user's Skype account/profile (via Skype's mePerson object).
The only way that I see to do this now is by having yourself as a contact and accessing information about that account/profile, via the Skype person object. This doesn't seem possible to me as it isn't feasible to set a requirement upon every client using my application to have themselves added as a contact on Skype for Business.
This issue is related to the one posted here, on the GitHub Skype Web SDK Samples page: https://github.com/OfficeDev/skype-web-sdk-samples/issues/1
My question: Are there plans to add the User.ReadWrite Permissions in Azure AD for an application extending Skype for Business? Or, is there a known workaround to retrieve the signed in user's profile/account information, which includes status, activity, or avatar/avatarUrl?
I've also posted this on the Microsoft Azure forums:
https://social.msdn.microsoft.com/Forums/azure/en-US/27d6ebdc-f023-4829-96dd-eefb9e1aaeaf/userreadwrite-permissions-in-azure-ad?forum=SkypeWebSDK
However, I've had no response so I'm also posting here in hopes of anybody having any input. Thank you in advance.
As you might have noticed from the issue link in GitHub, the permissions for the information you're trying to grab have been turned on in Azure AD.
You can plug in your Azure AD settings into the Interactive Web SDK to see it in action: https://ucwa.skype.com/websdk
Before you sign in, you'll need to do the following in the Azure AD management console:
Update your app to use the permissions in the image
Change your app's reply URL to this: https://ucwa.skype.com/websdk
Make sure you turn on OAuth implicit flow by modifying your app's manifest. Steps here https://msdn.microsoft.com/en-us/library/office/mt622687%28v=office.16%29.aspx?f=255&MSPPError=-2147217396 under "Configure your app for OAuth implicit grant flow"
Paste your app's Azure client ID into the "Client id" field on https://ucwa.skype.com/websdk
After you sign in, you'll notice one of the examples in the left hand navigation will let you view the signed-in user's presence, ID, etc.
I've also created a forked version of the Web SDK samples that you can easily update with your own Azure AD settings and deploy to your localhost. You might find this more useful for playing around than the hosted Interactive Web SDK.
https://github.com/tamhinsf/skype-web-sdk-samples
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'd like to add an Office365/Graph Calendar integration to an existing Node.js app (hosted on AWS). I've already done a similar integration with Google's Calendar, and it was trivial to get set up. I'm not having nearly as much luck with the Microsoft version of things.
I've found at least 4 different ways to register an app (get a clientId and clientSecret), and I seem to get different errors for each of them, but can't get any to work properly.
I think a large part of my problem is that I've never had to work in the MS ecosystem before, so I don't have a lot of the baseline knowledge that the documentation assumes.
I'm not looking to host anything with Microsoft - do I even need an Azure account?
I'd like to allow any user with an Office365 account to connect it to my app - do I need to learn about Active Directory to do this? Does this part of it require Azure?
I've found instructions for using both https://login.microsoftonline.com/common/oauth2 and https://login.microsoftonline.com/common/oauth2/v2.0 for this, do I need to worry about which version I use depending on how I registered my app?
Microsoft Graph leverage Azure AD to authenticate and authorize users. The doc refers as:
To get your app authorized, you must get the user authenticated first. You do this by redirecting the user to the Azure Active Directory (Azure AD) authorization endpoint, along with your app information, to sign in to their Office 365 account. Once the user is signed in, and consents to the permissions requested by your app (if the user has not done so already), your app will receive an authorization code required to acquire an OAuth access token.
So you need to register an Azure account for configure the Azure AD service. Refer https://graph.microsoft.io/en-us/docs/authorization/app_authorization for more info.
Meanwhile, to implement Microsoft Graph in node.js application, you can refer the following code sample for your information.
Microsoft Graph service app sample using Node.js
An Office 365 API sample app using Node, Express and Ejs
Office 365 Node.js Connect sample using Microsoft Graph
Matt, you can do this without an Azure account if you use the oauth2/v2.0 auth endpoint. When you do that, you can register on apps.dev.microsoft.com using a Microsoft account.
See this tutorial for doing it with the Outlook REST API, which is similar to the Graph (in fact, for Calendar operations the calls and entities are identical).