For OAuth 2.0 flow for OneDrive for Business, should one use:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize
As well as passing along a scope?
According to this MS blog post, onedrive, onedrive for business, etc should be able to use this new V2 OAuth 2.0 flow:
https://blogs.msdn.microsoft.com/richard_dizeregas_blog/2015/09/04/working-with-the-converged-azure-ad-v2-app-model/
Or, should it be:
https://login.microsoftonline.com/common/oauth2/authorize
And have permissions set up in AAD for the application?
When using the former (v2 OAuth), I keep getting errors saying my scopes are invalid: AADSTS70011: The provided value for the input parameter 'scope' is not valid. The scope offline_access onedrive.readwrite is not valid.
When using the latter I keep getting the following error:
unauthorized_client
AADSTS70001: Application 'xxxx' is not supported for this API version. Trace ID: d5d359ad-2e6b-468d-9a95-df51656e9cc9
I have OneDrive working for user accounts using the live APIs, but since they are deprecated and it looks like the user and business OneDrive accounts should use the newer APIs, this is getting confusing.
Thanks for any assistance.
To access the direct OneDrive for Business end point (instead of using Graph API) you need to follow the steps to Register an app for OneDrive for Business. This requires an Azure subscription (even though its free) and using the Azure Portal to define the permissions the application will require. After going through this provisioning, you use the second authorize end point (without v2 in the URL).
It sounds like you registered an app using the new app registration portal (apps.dev.microsoft.com) which is only compatible with the v2 OAuth end point, which only works with Microsoft Graph.
You can sidestep the Azure stuff by creating a new application ID from the Office 365 Getting Started page, however will need an Azure subscription if you need to make changes to the app later.
Also, we're working on fixing the 4MB upload limit with Graph API, although I don't have an ETA for when that will be resolved.
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'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.
I would like to know if is possible read/write data from/to azure active directory ad by Javascript.
I read that there are REST services on Azure but the main issue is generate the token to talk with that and it seems that JS library doesn't exist for that.
Yes, there is such service. It is called Windows Azure Active Directory Graph API.
It is REST based and one can authenticate via OAuth to use it. Please note that currently the Resource Owner Password Flow is not supported in WAAD, but the regular token based authentication is. What you will need is:
Get an overview of the Graph API here.
Create an application inside Azure AD so that you get an application credentials to use with the Graph API (tutorial here)
Find some good JavaScript library that can generate OAuth headers (you can start here).
UPDATE
Actually you can't query the graph API from JavaScript as there is not CORS support for it. The only CORS supported services are Azure Mobile Services and Azure Storage. Which makes the use of a middle tier "service proxy" inevitable.
The only "JavaScript" stuff that will work with WAAD (Windows Azure AD) is the developer preview of ADAL for Windows Store.
As for where to keep OAuth key and secret everyone shall use their imagination. I never mentioned neither suggested to keep these on the client.