As per https://msdn.microsoft.com/office/office365/APi/use-outlook-rest-api#RegAuthAzure , the only option to access data in Outlook.com using REST API is to use v2 app model which is in preview. Is there no other way to access data on Outlook.com.
Also Microsoft Azure only supports Office365 and not outlook.com. Is this correct?
I was running into issues trying to use the REST API's with an Outlook.com account and in my experience you are correct that the only way to use the REST API's with an Outlook.com account is by using the v2 app model.
I was using the v1 (or non v2) app model and could not get an Outlook.com email address to authenticate with my app, even if I added it as an external user to my AAD. As soon as I switched over to the v2 app model everything worked as it should. It think this in particular is the main feature of the v2 app model.
Yes this is correct. You need to use the v2 model to access outlook.com accounts.
Related
I need to work with Azure services, so I use github.com/Azure/azure-sdk-for-go but also want to get a user email. Do I have to use the graph SDK (github.com/microsoftgraph/msgraph-sdk-go) for this?
My app allows authentication of both multi-tenant AD users and personal accounts.
Do I have to use the graph SDK
(github.com/microsoftgraph/msgraph-sdk-go) for this?
Yes, you would need to use msgraph-sdk-go SDK to interact with Graph API. You can find more information about using the SDK here: https://learn.microsoft.com/en-gb/graph/sdks/sdks-overview.
In my case I used an oauth2 token to authenticate both azure and graph SDKs. It's impossible to work with both SDKs using the same token because specifying scopes for both graph https://graph.microsoft.com/.default and azure services management https://management.azure.com//.default returns error about the scope being invalid.
So, you can't use Azure SDK for personal accounts, it must be a work account. Microsoft allows to have both personal and work account using the same email (and different passwords). Azure SDK does have graphrbac service that in theory can be used to fetch a user email but this service has been recently announced as deprecated.
I've ended up realizing I don't really need a user email, I'm fine with having a subscription ID.
I would like to try out Microsoft GRAPH API. But as far as I can tell there is no way to test it without App Registration client and tenant id in the Azure Portal. Is this correct? I don't have access to App Registration on Azure so if this is correct then I need to contact admin, which means I need to start a whole long-winded process.
No, this is not possible, to access the graph api, (for a work or student account) there must be an app registration to give you permissions to those endpoints.
It is possible IFF you are just trying to do CRUD operations and other GET requests that doesn't require an admin consent.
You can check the same inside Graph Explorer, for the requests that require your/admin's consent.
You must also consider that the access token gets refreshed when you try to integrate it with any code.
The accepted answer is misleading. This is possible using the Microsoft Graph PowerShell SDK.
I want to read mails of users of a specific domain (tenant) using Outlook API. However, I don't have privileges to register new app in Azure portal, for that domain, and so am not able to use Graph API. We cannot use Outlook API without an OAuth app. In this case, using IMAP/POP3 is my only choice? How secure is to use IMAP/POP3 to read mails when compared to Azure AD Graph API? Please advise.
It depends on what you really want to achieve.
If you just want to read the messages, configuring your mailbox in Outlook or other email provider with IMAP/POP3 is a preference. You don't need to worry about its security, it has been in service for decades.
For Microsoft Graph API, to call Microsoft Graph, your app must acquire an access token from the Microsoft identity platform. See Authentication and authorization basics for Microsoft Graph to learn more details about it.
So the point is how you want to read your email.
If you are developing your own app, using Microsoft Graph API is certainly the best choice. You can test GET https://graph.microsoft.com/v1.0/me/messages to list your emails in Microsoft Graph Explorer without registering an app in Azure AD.
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).
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.