Slides supporting the session deep dive with the Microsoft Graph at Techorama Belgium 2018. Talking about authentication, authorization, integrations with azure functions and the SharePoint Framework.

1. DEEP DIVE INTO
MICROSOFT GRAPH
BY VINCENT BIRET

2. Passioned by technologies, development and community
Vincent Biret
@baywet
bit.ly/vince365
MVP Office Servers and Services
Azure and Office 365 developer @ 2toLead

3. Devs, devops, deciders. Endless possibilities, faster time to market, focus on business
value
Audience?

4. Microsoft made a subsequent investment for a few years to unify it’s API’s, authentication
modes and data formats as well as deliver a converging model.
Why the Microsoft Graph? Thanks
Yina!

5. Agenda
•Introduction
•AuthZ & AuthN
•SPFX
•Azure Functions
•Better together!
•Throttling
•Conclusion

6. Ready?

7. Azure Active
Directory
Microsoft’s Identity Service

8. Or modern web developers’ nightmare
Authentication & Authorization

9. AAD has become the key central identity service for Microsoft and provides a seamless
experience to end users.
Microsoft’s Central Identity Service
• Leveraged by all Office 365 workloads
• Stores Users, Groups, Applications…
• Provides many capabilities
• Hybrid: SSO, Federation, Synchronisation
• Enforced security: MFA, geo-fencing,
• Increased Productivity: SSPR, B2C

10. Situation is painful, v2 slowly catching up, Microsoft is trying to improve it. When starting
a project, take the limitations into account and go from there.
ADAL and MSAL
• Two auth libraries from Microsoft for AAD
• ADAL talks to v1 endpoints
• MSAL talks to v2 endpoints
• MSAL still in preview but commercially supported

11. V1 is still recommended if you’re only working with O365 accounts. Microsoft is working
hard to migrate services and make models converge.
Two endpoints: details
• V2 brings:
• Unified Authentification and
autorisation for MSID and AAD
• Dynamic Scopes (opposed to
ressources)
• Client credential flow
• On Behalf Flow
• V2 Limitations:
• # of secrets
• securing APIs
• Not showing up in Azure Portal
• no wildcard redirect URL
• Limited « resources » available today
• No SAML or WS-Federation backend

12. Microsoft makes the consent flow much more flexible for developers, and gives more
control to users
Resource VS Scope
• Resource: « an application that can receive a token and provide
services »
• Eg: https://graph.windows.net
• Scope: « a subdivision/permission on that resource »
• Eg: Directory.Read, Directory.Write
• With V2 you need to provide all the resource:scope in the request,
allowing you to have gradual content

13. It’s important to understand which tokens you’ll be getting to avoid confusion.
Token types
ID Token
Access Token
Always Important to remember for which
resource
Refresh Token
Always Important to remember for which
resource

14. Example access token

15. Zooming on
the flows

16. As application developers we DO NOT want to store username/password. Delegating that
responsability to AAD diminushes the exposed surface a lot if our app gets compromised
Basic principle (ultra simplified)
MS Graph
Get a token

17. In this scenario we simply want to display information about the user on the app. The
access token is short lived and you won’t get a refresh token
OIDC Implicit Grant
MS Graph
1 id token + access token A
Open Id Connect + OAuth 2.0
(in her browser)
3 gets the data

18. In this scenario we want to sync some data on the local device. The importance is
getting a refresh token
OIDC Authorization Code grant
MS Graph
1 authorization code
2 access token + id
token + refresh token
(in her App)
Bakground agent
1 presents refresh token to AAD
2 gets access token
4 gets the data

19. In this scenario let’s suppose we want to crawl data for all users with a backend process.
This scenario acts as the application alone.
Client Credentials Grant (V2)
MS Graph
2 access
token
gets the data

20. In this scenario we want to check if the user is under age or not for alcohol drinking and
our API is going to hold the logic. The important difference: we only declared 1 app
On Behalf Flow (v2)
MS Graph
1 id token + access token A
Open Id Connect + OAuth 2.0
4 access
token B
5 gets the data
(in her browser)

21. The Customer: CIA
Immersion Agency

22. The “be nice, eh” solution
The need
• We want to encourage people to have better interactions
• For that we’re going to “scan” their emails
• Score the sentiment
• Have a webpart that displays average score per user on the company
portal

23. The solution requires a minimal development effort thanks to the integration between
the services provides by Office 365 and the infrastructure provided by Azure.
The architecture
MS
Graph
1
4
1 – Users send/receive emails
2 – Exchange communicates with
Graph
3 – Graph triggers our function for
analysis
4 – Users log into SP Portal
5 – SPFX webpart contacts Azure
function for data

24. Demo time

25. Microsoft
Graph +
SharePoint
Framework
A unified API for modern developers

26. SharePoint Framework in a few words
• First party and third extension
model
• Modern tooling
• Open source based
• More examples
• More community support
• Bigger developer community
• Bigger choice of tools
• Smaller footprint
• Better peformances

27. Since v1.4.1 SPFX has built-in partial support for the Microsoft Graph with SharePoint
Online only
SharePoint FrameWork + Graph

28. Graph access from a SharePoint Framework webpart
Demo

29. Serverless?

30. Improving the « pay for what you use » and the elasticity principles, it also provides a
total abstraction of servers
Serverless definition

31. Enable your team to deliver solutions faster, in a mosre structured way moving the focus
on the business logic
Benefits

32. From zero to productions in 7 steps! Microsoft’s answer to serverless
Azure functions
• Pick a language
• Pick a trigger
• Add some inputs/outputs
• Write the business logic code
• (test/deploy)
• Scale your service
• Ship to production!!!

33. Dozens of bindings/triggers available, no more need to build the boiler plate code!
Connectors
MS Graph

34. 10 languages supported in Azure Functions and more to come
Languages

35. Functions project, functions portal
Demo

36. Technologies as a Team

37. Microsoft’s goal is to make « citizen developers » lives easier by providing robust and yet
simple tools
Microsoft Graph + Azure Functions
• Serverless benefits
• Microsoft Graph data access
• Built in security
• More flexible than Microsoft Flow

38. These bindings handle a lot of the boiler plate for you, saving a lot of time and headache
New Azure functions bindings (v2)
Azure Function queries the
Microsoft Graph
Web hook
Calls the function
MS Graph

39. Only with functions v2, still in preview. Most important ones being webhooks + auth that
allow you to do anything. You can also leverage flow as a relay.
Azure Functions + Microsoft Graph
•Excel table input/output bindings
•OneDrive File input/output bindings
•Outlook output binding
•Auth token input binding
•WebHook triggers/binding

40. All the new SPFX capabilities came out with 1.4.1. It’s becoming seamless to integrate
those technologies together.
SharePoint Framework + Azure Functions
• SPFX helps “linking” AAD app + SPFX solution
• SPFX helps “getting the tokens”
• SPFX helps “talking to the graph/secure API” (preview)
• Azure functions can be “secured” via bearer token (AAD)

41. Throttling

42. Microsoft must put safeguards to guarantee service level and customer’s satifastication
Context
• Office 365 is a set of services
• These services rely on limited resources
• (memory, CPU, IOPs, Bandwith…)
• These resources are associated to a cost
• (hardware, cooling, electricity, facility, maintenance, operating…)
• Any service outage impacts customer satisfaction (and revenue)

43. Bounderies are defined for multiple service concepts and levels, which sometimes makes
it hard to understand
Model
• Usage of anything is always limited
• Those limits can be dynamic or fixed
• API usage is dynamic
• Storage for a user/site collection is fixed
• Some of those limits can be increased by the SKU and/or the number
of seats
• API usage is throttled by a per user base (at first)

44. From the Microsoft Graph to the internal service, the user usage will always be
considered first, and then the tenant at large
Local resources
Office 365 perimeter network
Microsoft Graph
Workload’s API
Internal service
Service
resources

45. The idea is to limit your usage of the resource, flatten the spikes, keep key features alive
while shutting other off, or even tell the user to back-off before everything shuts down
What can you do?
• Cache reading operations (if possible)
• In proc, in memory, distributed cache (Redis)
• Watch for Rate-Limit Limit, Remaining, and Reset response headers*
• Watch for 429’s or 503’s and implement incremental backoff policies*
• Or better delay the operation until the Retry-After response header
• Implement Circuit Breaker Design pattern
• Throttle your own incoming traffic using Telemetry

46. The quotats are always per user based, x users = x « quotat points », 1 app only = 1
quotat point, avoid using app only if not necessary
Circuit Breaker Design pattern
MS Graph

47. Conclusion
I swear, I’m going to stop talking soon and let you free

48. The Microsoft Graph allows you to build extraordinary solutions, because it’s an
aggregation of different services, it comes with things to consider
Conclusion
•Getting AuthZ & AuthN right is
crucial!
•Mind throttling from day 1
•SPFX & Azure Functions are here to
help make things simpler

49. Bit.ly/vince365 @baywet slideshare.net/VincentBIRET
Thanks!/Questions?
Vincent Biret
Office 365 and Azure
Developer
@baywet
Bit.ly/vince365
http://bit.ly/ms-
graph-samples