Introduction To Office 365 API

This introduction to Office 365 API, describes the significance of using this API into user applications whether it is native or web based application. From a developer's perspective everyone thinks about  how to do office extensibility. To empower developers it's really a two- pronged approach between user and data.

On the user side, we want to be able to view surface(customization inside office clients, it’s a concpt of built in approach) on the other side data must be able to connect in and leverage all the rich data that we’ve collected inside of office 365.

With these foundations we came to know whom to  communicate with and what the collaboration is that they have in the application that we built.

Office 365 connected apps



Standard applications might have some sign in option like login page of C# corner (web based application have different sign in experience).

Application works with mails, messenger, contact and event files.

Common Consent

User is going to see what the application trying  to to in order to proceed further in case want to sign in and read user profile. 

Single authentication flow with office 365

Everything is backed by the office 365 like Exchange services, Share point, one note and Azure AD directory(Secure behind by AD)



All flows that you seen here in the application all go together with a single authentication provided by azure directory services. Apps can be delivered as stand alone applications. In case of consent user may have seen some kind of consent related to application and Admin has inter linked consent to built application that gives better performance for the entire organization.

When we build standalone applications we pin all application sin pin launcher. In the above, the live.com mail has some application in grid view which consists of applications like skype, MSN,one note..

We can pin our own customized app also, so that they pin along with other apps in pin launcher. Make it easier for user to find it and easier to launch that application.

Secure Protocol

All single flow authentication here follows leverage OAuth2.0. There is an advantage of using leverage OAuth2.0, as a developer we don’t want to spend our timing in designing Login pages and asking user to provide username and password. We can use all that in Azure Directory.

Azure handles the sign in process and brings the token for us to handle application. Our job is simply to start with APIs. 

Azure provides these granular permissions to the users to launch application in app launcher. Multi factor authentication or a federated sign in, and longterm access to 2 weeks to 90 days saves user login time via a refresh token that gives longterm access to data.

Concept of Discovery

If someone logs in we can call the end points of the logged user and automatically determine the URL of these services support device apps and web flows. So these are endpoints to discover an endpoint. 

Unify API

Discovery of endpoints is an extra step from user to call file picker, like One Drive for business it's not that efficient so there is an API called Unify that adds a layer of transparency and allows us to provide service to service without refreshing the tokens. It's more efficient to use one token to call for all.

So this is the single resource that is going to proxy all the different services that Microsoft offers.