It’s been an extremely busy few weeks for me, and everyone at Microsoft, working on Office 365 developer extensibility. We made some very big announcements around: building Office everywhere, connecting to our APIs and building on an open platform. Personally for me, this was my first major launch. I joined weeks after the SharePoint Conference 2014, where our team made some other major announcements like the Office 365 APIs Preview.
To summarize, the announcements this week are:
- Extend Office everywhere
- Extend My Apps page and pin to App Launcher
- Extend Outlook.com consumer (Preview)
- Connect to Office 365 APIs
- Generally available
- Mail, Calendar, Contacts from Exchange
- Files from SharePoint and OneDrive for Business
- Build on an Open Platform
- Generally available
We had presentations to explain what was new at TechEd Europe 2014 in Barcelona, which are available on demand at http://dev.office.com/training. The kick-off session also included some bits on our Vision too where we demoed the Microsoft Graph, extending Office for the iPad and hover cards in Outlook. I also recorded a podcast with Brian Jones, Group Program Manager for Office Developer Program (ODP), which you can listen to right now. We also have over 30 hours of FREE on-demand training and accompanying hands on labs available at http://dev.office.com/training already.
It’s been really exciting to see the pick up on this with a variety of technology outlets writing about the news like: Apple Insider, eWeek, etc. I’m really looking forward to the developer community getting their hands on the new APIs and extending the My Apps page. There have already been a bunch of questions on Twitter, StackOverflow and Yammer around the news. I figured I’d respond to a few of these here as I fly back from Austin to Seattle after a great weekend of race cars at the Formula 1
Is this yet ANOTHER App Model with My Apps extensibility?
This was actually the first question I got after we revealed this in the Developer Foundational session where I demoed this with Jay Schmelzer, Partner Director of Visual Studio, on day 1 at TechEd. Extending the My Apps page requires you to register an Azure Active Directory Application in the Microsoft Azure Management Portal. You simply define the web site address that clicking on the icon on the My App page directs you to after an authentication flow occurs and grab the client id and secret the page gives you and use that to make calls back to the API. This is very similar to the flow for the SharePoint Hosted and Provider Hosted app model, where the icons land on the Site Contents page of a SharePoint Site. The main difference is that the SharePoint app model uses Azure Access Control Services (ACS) auth flow, which are registered via appregnew.aspx. The engineering teams are working on converging the auth flow used by both and we’ll have stuff to show in the coming months.
The way to look at it as a developer is that you can extend at the: Office level; SharePoint level; or Organization wide. There were many scenarios where developers were using SharePoint Provider Hosted apps and deploying them to a Site Collection just to get the auth flow hooks even though it didn’t leverage the parent SharePoint site at all. Some organizations even deployed the same app to every site collection for discoverability. Essentially now you could just adjust the web site to make these appear in the My Apps page. I also believe that some business solutions will have a combination of every approach: Office, Site and Organization wide.
Can I call SharePoint CSOM/REST APIs using Azure AD auth flow?
In actual fact, you can also call the SharePoint CSOM/REST APIs by posting the same Azure AD access token, as long as when you register your Active Directory Application you request for permission to SharePoint Online. The new Office 365 Files API that connects to SharePoint Online, only works against Document Libraries so there is still a need to use the SharePoint CSOM/REST APIs to connect to SharePoint Lists, Workflow, Managed Metadata, BCS, Search etc.
Can I get an app-only token with Azure Active Directory auth flow?
One of the neat bits about Apps for SharePoint is that you could request different types of auth flow: user; user and app; or app-only. This allowed my app to interact with the parent SharePoint site and where it created things in document libraries or lists, the auditing would show the app had modified it and NOT the user. Azure Active Directory auth flow does not support app-only at this time.
Can I use the Office 365 APIs with an elevated user account in my web sites?
For many ISVs this scenario is very common, for instance those ISVs building back up and recovery solutions where they have to use an elevated administrator account that has access to everything. The purpose of the Office 365 APIs is really from a “me” use case, as indicated by our RESTful endpoint URLs. These APIs are not intended to use elevated or impersonated credentials at all. If a user is accessing your web site and the web site is calling the Office 365 APIs, it will only have access to their own Mail, Calendar, Contacts regardless of whether that user is a tenant admin or not. The exception to this rule is SharePoint Online, where you can request “Full Control” of all SharePoint Site Collections that the user has full control over. For these elevated scenarios the existing Exchange EWS API and SharePoint CSOM/REST APIs should be used.
Can we submit to the Office Store extensions for the My Apps page?
The team is actively working on the ability to support not only Office level and SharePoint level apps but also My Apps extensibility in the Office Store. Right now, the only way for you as an ISV to land in customers tenants is through:
- Dedicated – providing them with your web site to host and getting them to manually create the Azure AD application and drop in the client id and secret into the web.config of the web site; or
- Multi-tenant – configure your Azure AD application to be multi-tenant and point them at your web site and go through the consent flow. This was actually demoed in the kick off where we showed both SmartSheets and Xero acquisition process.
The announcements this week were really to enable web developers to extend the My Apps page and to call the Office 365 APIs. In the old world of 3 year releases, we would have shipped this with the whole story completed, but with milestone releases every 6 months and continued improvements every month we have taken a different approach. We do know that web developers will use these APIs against Office and Site level right now. So below are a few common questions we are hearing already:
Should I use Office 365 APIs or continue to use SharePoint CSOM/REST APIs in Apps for SharePoint?
The main benefit of using Office 365 APIs in Apps for SharePoint would be the fact that once registered you could also call Mail, Calendar, Contacts and User and Groups APIs too. In the future as we add new API endpoints there, for example Office Graph, Yammer, and Lync this will become more compelling.
Apps for SharePoint natively work with Azure ACS auth flow and you can use the access token you receive on launching the app to call the SharePoint CSOM/REST APIs.
The new Office 365 APIs cannot be called by the ACS access tokens. Right now, if you deploy an App for SharePoint that uses the Office 365 APIs, it will not register this in Azure Active Directory Application register so that you can get an AD access token. So, right now you’d have to register this manually in the Azure Management Portal and plug in that client id and secret, therefore having two in there…one for Azure AD auth and one for Azure ACS auth. As mentioned above, there is work being done to converge this.
Should I use Office 365 APIs or continue to use SharePoint CSOM/REST APIs in Apps for Office to talk to SharePoint Online?
There are a lot of scenarios where you extend the Office client and want to call into SharePoint Online or Exchange Online. We’ve had some great samples out there to request on the fly permissions to SharePoint Online using Azure ACS auth flow and registering the application in appregnew.aspx and getting the ACS client id and secret. There were already samples of how to call the Office 365 APIs using Azure Active Directory auth flow and registering the application in Azure Management Portal and getting the AD client id and secret. I would encourage the use of Azure AD auth flow here rather than ACS auth flow moving forward for SharePoint Online scenario due to our focus on Azure AD.
Should I use Office 365 APIs or continue to use Exchange EWS APIs for Exchange Online?
Although the Office 365 APIs gives great coverage of Mail, Calendar, Contacts there are still things that the EWS API has coverage over. So it would make sense to call these from your application. Typically this would require capturing the user name and password to use to call these endpoints directly via REST or using the Exchange Client. One of the main advantages of calling using the access token is reducing the need to store the user name and passwords or even request them off the user. I have blogged previously about how you can call the EWS APIs using the Azure AD access token.
How does the Office Store acquisition flow work for Azure AD applications?
If you are an ISV building an App for Office or Apps for SharePoint that uses the Office 365 APIs, you will need to register your application in Azure Active Directory and mark it as multi-tenant. When the user gets the app from the Office Store, they will prompt the user to “Trust” the app, which grants the app an Azure ACS authorization token. The first use of the app where it calls the Office 365 APIs will result in a user being asked to consent the app, regardless of the fact the user would have already “Trusted” this app from the Office Store. The reason for this is because the “Trust” flow from the Office Store is trusting the app for Azure ACS, not Azure AD. As discussed in our kick off session, there is work being done to streamline this too.
I look forward to sharing more with you in the coming weeks as we get more feedback on all these things!