It’s been really exciting to see ISV’s and the community start playing with the new Office 365 APIs. I’ve presented on these at TechEd North America with Thorsten Hans in the SharePoint Power Hour session.

In a nutshell, the Office 365 Developer platform has: the App Model to surface up your business solutions directly within the user interface of the products; and then the Office 365 APIs for you to consume our services from your own standalone web applications or device apps.

The current services available in the Office 365 APIs are: Mail, Contact and Calendar from Exchange, OneDrive for Business and All Sites from SharePoint. There is already a Files API you can call into OneDrive for Business and SharePoint, but not other things like modify SPWebs etc.

One thing to note is that currently the authentication is different. With the App Model, Tenant/Site Collection administrators add the Apps to Office or SharePoint and have to ‘trust’ them. This approach uses the Azure ACS authentication and authorization approach. In this approach, it is trusting the App in the Site Collection/Site that it is added in.

With the Office 365 APIs, tenant administrators have to ‘consent’ that the standalone web application or device apps can have the permissions its asking for. This approach uses the Azure AD authentication and authorization approach. In this approach, it is trusting the application for the user that consented it against all the User data from services that the app asked for.

One really cool thing about the Azure AD authentication is that if you ask for SharePoint Site permissions, you can actually use the Auth Bearer token that Azure AD grants you to call the REST and CSOM APIs. If you only ask for Read access to SharePoint sites, then when you call the REST and CSOM it will enforce it. If you ask for Full Control access to SharePoint sites and the User only has Read to a Site and you try and do something more than that, it will enforce that too.

Using CSOM with the Auth Bearer Token

This is an example method of getting the default list view url using the Azure AD Auth bearer access token.

Setting up your Application permission

The standalone web application or device app still needs to go through and do “Add Service connection” and pick the SharePoint Sites permission level and that in the background will then register the Application under that Azure AD instance in your Azure tenant. You could also register the application directly in Azure AD instance and grab the client ID from there.

Connecting your Azure AD instance to Office 365 Tenant

One of the big questions I get is around the Azure AD instance and where to find it and who to log into when you access it in Azure Management Portal. There is a great blog post on this at http://blogs.technet.com/b/ad/archive/2013/09/10/empower-your-office-365-subscription-identity-management-with-application-access-enhancements-for-windows-azure-ad.aspx and also a MSDN article on the two approaches of connecting an existing or using the default one that gets created (log into Azure Management Portal with your Org account) http://msdn.microsoft.com/en-us/library/office/dn736059(v=office.15).aspx .

There is already a Windows 8 app in the store that leverages this that Wes Hackett (SharePoint MVP) pointed me to too called Classbook.

Full credit for this code above goes to Rob Howard who is someone I couldn’t do my job at Microsoft without in the Office Developer Program engineering group. I hope this helps with further extending what you can do from standalone web applications and mobile applications against Office 365 services.

Yes there is. If you take a look at http://dev.office.com/code-samples you’ll find that there is a Research Tracker project that has a code sample for a Outlook and a Word plug in that talks to SharePoint.

All of this relies on the first assumption in your code in the first snippet on line #3 : “https://tenant.sharepoint.com” – which is an assumption that no developer can make. Can you talk about how to get past hard-coding URLs? This is a much harder problem than using the APIs themselves.

I am trying to build an ASP.Net MVC / Web API web app. I intended to host it as an Azure Web Site and Azure Application in the Office 365 Azure Tenant Instance.

The app will be available as an Office 365 External App (via Azure AD) to the Office 365 users (from App Launcher and My Apps).

I want my app to be able to access back to the Office 365 resources (Site, Web, List, DocLib, Item, Permissions…).

Following your article, I see that I can use BOTH CSOM and Office 365 API.

When trying Office 365 API, I see we only CAN acquire accessToken for Calendar, Contacts, Mail and MyFiles. However, I could not do that for RootSite (SharePoint resources) even on Azure I have granted all possible permissions from my app to Office 365 SharePoint Online.

This is because when I am debugging, the Discovery Service only have 4 capabilities: Calendar, Contacts, Mail and MyFiles.

What I really want is the RootSite (the sharepoint bit).

So the question is: Is the RootSite access available (acquirable accessToken) for Azure App to access Office 365 via Office 365 API and CSOM? If yes please guide me how or point me to anywhere explaining this. If no, will and when Microsoft would likely make it available?

Another question I have for you is that: Will Office 365 SharePoint Online (Azure App) provide certain Application Permissions (not Delegation Permissions) for other apps to access Office 365 in its own context?