Microsoft Graph

This is a continuation of a series of articles on Azure services from an operational engineering perspective with the most recent introduction of this topic with the link here. This article continues the developer experience before talking about the operations.

Microsoft Graph (aka MSGraph) provides rich context for applications such as who are out of office, what documents they have been working on, etc. It provides deep insights generated from usage patterns, such as trending documents, best team meeting times, or who people typically work with. It provides real-time updates which helps to respond to changes in the data such as to reschedule a meeting based on responses, notify others when a file is modified, or continue a process after it has been approved. It builds solutions that target enterprise users in Azure and Microsoft 365, consumers in Office online or both.

The Graph Growth and telemetry landing page is a central hub for telemetry on Microsoft Graph. It provides a centralized dashboard to view the data.

Authentication and authorization are simplified with MS Graph.  There is a single authentication protocol and a single resource. Clients need to manage just one token, one sign-in and a single set of permissions scopes to consent.  Each of the data access to dedicated stores behind the MSGraph uses a separate identity. Workloads don’t share identity. Once the authentication and authorization complete at the entry point of the MS Graph APIs, the resolved user, application and permission scopes are passed around to the data stores accessed. The On-behalf-of flow in Oauth2 is leveraged for this purpose. The access token is not passed directly to the stores behind the MSGraph to avoid token replay attack. The Protected Forwarded Token pattern applies to Azure Active Directory and MSA accounts as well.

The MSGraph APIs can be improved for better customer satisfaction with the following strategies:

1.       Separate out the high data volume services as premium services

2.       Separate out the high data volume with added value as high-speed lanes

3.       Use the marketplace for ISV solutions.

4.       The monetization occurs with Azure Consumed Revenue where the revenue is associated with usage of Azure metered and suite services.

5.       The APIs must be written such that it satisfies the customer’s need for automation, integration and reporting

6.       It should help the ISV partners to integrate for success

7.       It should support backend scale up and out for a needed backend reliability.

8.       It should provide modern authentication aligned with Azure AD.

9.       It should support testability for its functionalities.

10.   Admin and end-user's persona can be separated

11.   The API usage must be seamless across backend data access.