Enterprise Mobility and Security Blog

RSS

Howdy folks, 

Today I’m happy tell you about a new set of features we’ve just GA’d. These features make it easy for developers to build daemon applications which call the Office 365 Mail, Calendar and Contacts APIs.

At TechEd Europe 2014, Office announced new APIs, where developers can build mobile and web applications that can sign users in with their work accounts (managed by Azure AD) and then access their work resources like mail and OneDrive for business files.  Now, AAD has enabled a new capability using Application Roles, where developers can build daemon or service account applications that can operate without a user having to login.  For these applications, the application signs in using its own service identity to access resources. For example, an application could archive all the email in an organization’s mailboxes every night.  Other similar applications might be used for compliance, auditing, and analytics gathering. 

The first services (other than our own Graph API) to take advantage of this new capability are the Office 365 Mail, Calendar and Contacts APIs.  When you register your app in the Azure Management Portal you can select application roles that your daemon application requires to Office 365 Exchange Online. 

Once an administrator consents to your application, the application can call Mail, Calendar and Contacts APIs based on the application roles granted.  This Office 365 blog post describes step by step instructions on how to configure your application, how to request consent, how to configure and use X509 self-signed certificates for token acquisition through ADAL, and calling Graph and O365 Mail, Calendar and Contacts APIs. Plus there’s a .Net code sample on github you can get started with! 

I hope you’ll find this new feature useful for building daemon style applications!

And as always, we’d love to receive any feedback or suggestions you have.

Best Regards,

Alex Simons (Twitter: @Alex_A_Simons)

Director of Program Management

Microsoft Identity and Security Services Division