Build UWP apps with Microsoft Graph - June 2019

Key Takeaways

welcome to this screencast on developing with the Microsoft graph let me first talk a little bit about what this screencast is and what you can expect from it before we start diving into the content this screencast is a going to accompany a hands-on lab and a training module that you can take advantage of that goes along with everything you're gonna find in this screencast specifically you're gonna find in this screencast is really going to be a example of someone presenting the content from the training module as a way for you to learn how you could train use this module and delivering it to a different user group or to at a conference however you can also use it as self-paced learning now the way that this module is set up is that it's broken up into a series of a couple different sections we'll go through each one of them in just a few minutes each one of these sections is going to finish with a demonstration now the demonstration we don't walk through the entire step of creating the application or walking through the steps of writing all the code instead we look at the final solution that has already been built and kind of picked through the code and pick through the important parts that you should take advantage of or you need to take note of and we'll see it working as well if you want to go through and you want to build the application you want to see how it's being built then what we will recommend that you do is go check out the hands-on lab that accompanies this module because the hands-on lab each of the exercises maps to one of the demos inside of this screencast that you're going to see so if you want to see how to build it you want to walk through the steps you can walk through the hands-on lab exercise that accompanies this module and get to the exact same place that we're showing you here in the screencast instead we're not going to show in the screencast all the individual steps of creating the application and part of that is because things change on a rapid cadence and the lab is gonna have the most updated steps and dependencies and stuff that you're going to need the screencast is more or less showing you how the thing works or how the final solution works so that's how you can learn more about taking advantage of this content and how we've all have we've structured this let's go ahead and dive into the actual module itself in this section we're going to talk about building universal Windows platform applications with the microsoft.net SDK this first sections can be mostly an overview to the windows universal platform and understanding the Microsoft graph API how we can get started with this and then how what the process is for creating a uwp application for Azure ad in the Microsoft graph in the future sections of this of the screencast will then look in a little more depth about authentication and in the Microsoft graph specifically office 365 developer vision focuses on the users experience and their data and as a developer you can bring your application into the user experience with over 1.2 billion users of office worldwide this is a huge opportunity to provide a window into your application as well as being able to connect into their data and add intelligence to your application there are currently over 850 million events created each month and a total of over 400 petabytes of data stored in the service that can add value for your users the Microsoft graph is the gateway to your data in the Microsoft cloud as you see there from the bottom of the list we've got a lot of different services and data types that we can actually take advantage of from office 365 and Microsoft and it's all considered part of the Microsoft 365 platform we can work with mail and calendar contacts tasks we can work with content inside of SharePoint sites and lists files inside of onedrive things inside of Microsoft teams think users inside of Azure Active Directory there's so many different things that we can take advantage of the nice thing here is that each one of these different services usually has its own API where we can talk to these different services to get the data out it can be challenging to go get the data from all these individual services as they each have their own endpoints they may have their own permissions and that also means that with their different access control that we have in talking to these different services using an OAuth style authentication via Azure Active Directory that means that each one of these different endpoints is going to have to require their own access token one of the nice things about the service called the Microsoft graph is that the Microsoft graph is to serve as a proxy endpoint to all of these other different services it's gonna in cover encompass things such as office 365 Windows 10 and enterprise mobility and security and it brings all of these different services under one top level service called graph Microsoft comm the advantage to using the Microsoft graph is that it's going to allow you to just have a single point resource which means you're only going to need a single access token to be able to talk to all these different services they still have their own individual permissions or as we refer to them as scopes so that everything is still secured in a very individual way but this makes it easier for developers to build applications all office 365 cloud services including SharePoint Online and the Microsoft graph leverage Azure ad for authentication and authorization this means there's a single authentication flow that you can use inside of your office 365 applications as well as those created to leverage the Microsoft graph this single authentication flow means that we're just gonna have one way that we have to log in to all these different services and obtain an access token either using a web application or a native application it also has a whole consent model and we'll look at that a little bit more in the future section everything is also very secure everything is based off the OAuth 2 protocol which means that the application that you build is never going to collect user credentials we're always going to redirect them over to Azure ad have the users log in and then azure ad will provide my application that I can build as a developer with a special code that the application can then use to exchange for an access token to be able to call these different endpoints and services such as the Microsoft graph on behalf of these different users we also have some very fine-grained permissions otherwise known as scopes so that users can only grant the application specific permissions of different things that they want to allow the application to do and then we can also have some special considerations that we have to take into account if we're building native applications so there's some things like when you build a web application you have a client ID in secret you can protect the secret because there's server-side code that the web application doesn't have to expose to the end-users but as we'll talk about a little bit later the native applications do have a little bit of a challenge where once the code has been distributed we can't include both the client ID and the secret because if we distribute the secret well technically it's no longer a secret anymore we'll see how this works in a native application in just a little bit now office 365 has a single authentication flow for office 365 and the Microsoft graph users are going to sign in using a technology called Open ID Connect which is an open standard and what that does is that once people have logged in there's this nice little envelope wrapper that will include details about the individual who's just logged in as your ad is going to be used for all of the authentication the Microsoft graph is built on top of the authentication model of azure ad office 365 is also built on top of the authentication model of Azure ad so both of these services trust Azure ad by having this single level of trust they are single service that they both trust then we can leverage the authentication to Britain to take advantage of both of these different services with the same authentication flow this authentication flow is also going to support multi-factor authentication also referred to as MFA and federated user sign ons and it's going to support all different kinds of applications from device applications such as those on a mobile device websites single page applications that live 100% mclamb or as a headless application with no user involvement also referred to as a daemon or as a service based application you'll be able to pin applications to your office 365 app launcher from the my apps page which is like that little menu that you have in the top left corner within office 365 platform convergence has been a journey which ends with Windows 10 Microsoft started by using the same Internet Explorer code and engine on Windows Phone 7.5 and Xbox 360 and then they started implementing the Microsoft modern design at that time with the release of Windows 8 we Microsoft converged on the Windows kernel which aligns among other things the hardware abstraction layer and the driver models Windows Phone 8 also took advantage of a new lighter weight kernel to enable CPUs and other improvements and the Xbox one was then built on top of Windows 8 Xbox also introduced something called Xbox or XJS which is Xbox version of wengie so developers could write apps in HTML and win jeaious in the same framework as was available on windows 8 with the release of Windows 8.1 the runtimes for Windows 8.1 and Phone came together as well continuing up the Windows stack and building upon the carl convergence that happened in Windows 8 no aligning the app models and API I said this brings 90% of the API convergence and unification convergence of things like Windows notification services and the back stack behavior sharing contacts live tiles etc then with Windows 10 Microsoft is going to bring a complete or is going to complete the process of the unification of all the windows families and it now provides a Windows core that can be used on embedded devices and IOT devices this makes it very easy for developers now they can just use one central platform that we can use on all different windows-based devices to bring the families together Windows 10 is built on top of a unified core at the windows core and a unified app platform the universal Windows platform which means that all of the device families that run Windows is going to be at the core this provides a consistency that users need and the tailored experiences that they desire gone are the days of Microsoft maintaining a number of codebase that work to build the bridges across the different silos now Windows has evolved into to do all that itself and also gone are the days of ISVs having to build this as well targeting Windows provides a single roadmap to a billion plus Windows different screens now enabling this consistent yet tailored Windows experience are a number of different services that you see at the bottom you get an adapted active UX which is a user interface design that is going to adapt and react to the device family that is running on natural user input such as speech natural ink gesture and facial recognition cloud-based intelligent services such as Cortana personal hubs onedrive office 365 the Windows notification services and a credential Locker in the Windows Store universally available apps games and digital media for the application developers and builders this also means that you can build on one Windows solution that runs across all the windows device families and use these windows services to tailor your experiences at runtime now this is all tailored even though that you have this unified kind of experience you're going to be able to leverage the different experiences that have been tailored to different form factors so you've got Windows PCs which are like a familiar desktop based application where you have like the broad support of the ecosystem the hardware ecosystem and Windows desktop application capabilities you've also got Windows for phones like is a farm your mobile shell and rich long telephony and Windows Phone app capabilities Windows on Xbox which is a 10-inch shell experience or 10-foot sorry shell experience and shared gaming experiences game and app capability and then you've also got Windows for different things like form factor appropriate shell experiences like device specific scenario scenario support is also part of this entire platform all of this is based on one core operating system with a base OS app and device platform runtimes and also a different frameworks so if I talk a little bit here about the adaptive UX that we looked at or that I mentioned earlier well it's nice about this is that you build the same code using the same controls and they're all gonna be rendered out based on the platform that you're currently on so in this case you can see what looks like Skype running inside of a mobile device as well as inside of a tablet or a Windows device you can see how the same codebase is being rendered out in different ways for the different tailor experiences here you can also see how you know you've got a based on the screen real estate you can show a different experience so here based on a set of adaptive controls you can then enable a tailored experience that goes just along with that device now one of the nice things about this is that you're just gonna have one binary that you're gonna build for all of your different devices you no longer have to have a shared project and specific platforms project that are gonna use the shared business logic in the shared project you've got no more conditional code like if I'm on this experience or that experience and you also have one Universal store this is really nice because of Windows Universal platform is then gonna be available to you on every Windows 10 device which is gonna make the deployment model also much much easier now what is the Windows Universal or the Universal Windows platform the UWP it's a collection of a bunch of contracts and extensions so that when you create an application you're gonna target a version of UWP and not target the operating system and said you also have a bunch of platform extensions which are different SDKs to add specific platform api's on top of the Universal Windows platform so how do we go about creating a universal Windows platform application you're going to do this using Visual Studio so you're going to first create the user experience and then when the context of trying to get data of the Microsoft graph you're then going to extend the app to support some sort of authentication and token acquisition from Azure ad and then you're going to integrate something like the Microsoft graphs at net SDK you can also create when you go to create these uwp applications so this is just showing you what the experience looks like so on the left hand side you're going to create the app inside a visual studio and then you implement the user experience and test it prior to implementing authentication and integrating the Microsoft graph so in this first demo what we're gonna see is how to go about building our first uwp application it's not gonna do a whole lot we're just gonna get the user experience set up so that we have a good flow for how everything's gonna work alright in this first demo we're gonna take a look at our application or uwp application now just as a quick reminder as i've explained already we are not in the screencast we are not showing every little step about how to create the application or how to or all the typing that's involved for writing the code and copying and pasting code and all that instead what we're doing is I want to show you an existing application and what we did to actually get this to work if you are interested in learning more about not only seeing the final solution or but or to see how to create the application yourself check out the training module that is associated with this screencast as we have full code samples of the final built solutions and a step-by-step detailed hands-on lab that is going to walk you through all the steps we do it this way so that the videos don't get out of sync and they're a little more timeless whereas we may need to update things for different version numbers and the developer environments may change slightly and so we need to make little changes here and there to make sure things are all gonna work accordingly when you go through and you do you do the lab now I've gone ahead and created an application when I did this I selected a c-sharp and just show you new project I created a brand new project I chose the c-sharp Windows universal in a blank app application so I chose that and then once I did that when I was prompted I chose a version of the uwp that I wanted to target or a minimum version I want to target I also have added in a couple different references to this so I've got references to a couple different uwp control toolkits the community tool kit that we have the this is going to allow us to get some UI controls for Annette notifications and loading indicators the grid is going to be used to show data that we get back from the Microsoft graph eventually the last one for the graph is going to be able to show us the log in and access token retrieval and then I've also added in a reference to the Microsoft graph dotnet SDK or YouTube EPA SDK as well here now once those have all been installed I then went through and I started setting up the app so first if I take a look at the code behind for this inside of Apple dot C s I've created a new property here called is authenticated and that's going to be something we use to determine if the user is currently authenticated or not now the app is first gonna load this main page dot saml file so this guy right here what he does is he contains a basic navigation view element with both a home controller and right here there's our home controller for different menu items and a calendar controller as well these different navigation links they're gonna act as the main view for the application it's also adding in this a sure ad login control to the header that's gonna be controlling the user sign-in and sign-out controls however this doesn't work at all right now it's not fully enabled because we haven't done anything with Azure ad yet they're gonna do that in the second section now I've also gone in and created a new app a new sam'l page here called home sam'l and this is gonna just contain a two text blocks of some text to display to the user when they first navigate to our application to show them something by showing something by default now inside the code-behind for this main page what you're gonna see is I've said in the main page initializer I've got a set off state and a root frame navigate method now the set state is going to set the current authentication authenticated state of the user and then the navigate is gonna go straight to our home page page that we've defined for the set state we've got a method here that allows us to set the state that's what's being called up here and what this is doing is allowing us to set if the user is currently authenticated or not and if they are authenticated then I will regardless I'm going to save it and then I'm also going to save their authenticated State I'm going to set that equal to the is enabled property on the calendar view should it be avail or not and that's the the navigation element that we have and then here when I navigate I want to navigate to the calendar well right now we haven't implemented that but if you navigate to the home page I want to take you back to the home page so let's run this and see what it looks like so I'm gonna go ahead and click on the local machine or f5 to get this running and now you can see our default application there's the text for the application and then there's the please sign in to continue and then I've got my sign-in button right here there's my home and my calendar if I click on counter nothing's happening click on home and actually get taken here to home I was already here so that's the very simple first step of creating our application let's jump back to the the slides and let's talk a little bit about azure ad and authentication and that will be our next step for our application is to go extend this to work with Azure ad in this section we're gonna look at how to implement as your ad authentication into our uwp application we are first going to start by looking at an overview of what the authentication story is going to look like then we'll talk a little bit about the Azure Active Directory and then we'll talk about the app registration process that we're gonna use the azure ad admin portal to do that and then finally we're going to talk about using the Microsoft authentication library to handle authentication all office 365 cloud services including SharePoint Online and the Microsoft graph leverage Azure ad for authentication and authorization this means there's a single authentication flow that you can use inside of your office 365 applications as well as those created to leverage the Microsoft graph this single authentication flow means that we're just gonna have one way that we have to log in to all these different services and obtain an access token either using a web application or a native application it also has a whole consent model we'll look at that a little bit more in a future section everything is also very secure everything is based off the OAuth 2 protocol which means that the application that you build is never going to collect user tensions we're always going to redirect them over to Azure ad have the users log in and then azure ad will provide my application that I can build as a developer with a special code that the application can then use to exchange for an access token to be able to call these different endpoints and services such as the Microsoft graph on behalf of these different users we also have some very fine-grained permissions otherwise known as scopes so that users can only grant the application specific permissions of different things that they want to allow the application to do and then we can also have some special considerations that we have to take into account if we're building native applications so there's some things like when you build a web application you have a client ID in secret you can protect the secret because there's server-side code that the web application doesn't have to expose to the end-users but as we'll talk about a little bit later the native applications do have a little bit of a challenge where once the code has been distributed we can't include both the client ID and the secret because if we distribute the secret well technically it's no longer a secret anymore we'll see how this works in a native application in just a little bit and the application then in the top left corner we'll be able to take that authorization code and then go log into Azure ad and provided this code and say I need an access token for this user as your ad is going to look at that code and say I can tell that this is a code that I created by being as your ad because it was digitally signed by Azure ad with their private key so they know that the contents of these sort of the code are valid because it has digital signature that matches one that only as your ad could have signed so we it trusts that service so it will then take that code it knows that in that code it says things like it was the user was me if they're trying to access the Microsoft graph and that it's coming from this application this native app so as your ad will look inside of his database and say has this user granted this application permissions to the Microsoft graph and the answer is yes because that's what we just did it will then create an OAuth access token and it will in that back and that diagonal line going from the bottom left to the top right that says issue token it will send that over to the back to the native application and that access token will contain the user it will contain the resource that the token is is valid for in our case the Microsoft graph and it will contain all the Scopes or permissions that the user granted the application and now from the top left corner the native app can then request the make an add an access data request over to the Microsoft graph that's the horizontal line across the top going from left to right to the resource server the Microsoft graph the Microsoft graph will get that token it will look at the token and it will say is this token valid it knows it's valid because it's going to look at the digital signature and it knows that it's going to be able to match the digital signature against the public key that Azure ad uses because the only thing that that's going to match is the private key that as your ad uses so Microsoft graph can say I trust that this access token was created by a gerrate he and the applications giving it to it's then going to open up that access token and know that I can see that this is a request for this specific user this access token is intended for the Microsoft graph and it has these permissions so it will then access the data that's being requested and then hand that back to our native ooofff client our native application and that's how the whole authentication dance and authentication flow is going to work here you notice here that both the client and the resource server need to know about the authorization server which in our case is Azure ad let me talk a little bit about different endpoint versions that we have in Azure ad we have a v1 endpoint and a v2 endpoint v1 came first obviously v2 came second now how did this work well in the v1 endpoint there was two characteristics to it that were that are worth noting here that and why we don't use it in a scenario for the Microsoft graph anymore one of the scenarios is that Azure ad only supported in the v1 only supported the azure active directory authentication it did not support any other styles of authentication and so what that meant is that if the user was logging in with a personal account or consumer account also known as a Microsoft account and they wanted to access things like their onedrive consumer account or their Outlook comm account things like that they our application would have to know what kind of account they were signing in with and we would have to send them to a whole different authentication model so that's one downside because azure ad or the v1 endpoint only supported work in school accounts or accounts with that leveraged Azure ad the other challenge that we had is that with a v1 endpoint it required what's called static consent which meant that every single permission that our application was going to need when the user first logged in they were gonna have to grant all the permissions upfront at that time had to declare everything at the very first time but what that's going to allow us to do then is that we don't have to worry about that that extra complexity we're gonna let azure ad figure all that out for us so that's one nice thing as the first two points converged authentication accept sign-in for both Microsoft personal accounts and Azure ad work in school and it enables the same code the code that we write for using the Microsoft graph for things like reading mail and retrieving contacts now the next thing that's really important here is the dynamic consent and with nice about this this differs from v1 where we had static consent where now every time you go to request a access token from Azure ad you specify the permissions that you need for that access token now let's say for example in the example I gave a minute ago when the user went to login they had to grant all permissions that this application could possibly need up front well now when the user signs in all I really need to do is I just need to request the user impersonation scope and that's gonna allow me to get information about the current user just get their name their email address etc and now they get a much better experience and they login to my app maybe they're only going to use the capability to reorder reorganize their email into different folders when they go to do that I can request another access token that says I need mail dot read and mail dot right and when I do that then the users only be prompted for those permissions if they had not already granted those permissions to the app the next time they go to use the app same thing it's gonna go check to see we need these permissions as your ad says I can tell this user has already granted those permissions so we don't need to go through that whole process a second time but we don't have to request permissions for their calendar for their tasks or for their files in onedrive we only need to ask that stuff when they actually need it so that's a I think that's a better experience because your users aren't hit with a lot of stuff and you've seen a similar model with this like on your mobile devices you an application may like if you were gonna use one of these social apps and you wanted to post something to this social network let's say you just want to post some text well it doesn't need a permission for that but then if you wanted to say post a picture that you had taken they need access to your photos on your phone and so it prompts you for do you grant this application access to your photos yes or no the next thing is maybe I want to take a picture and have it send right away so then it's gonna ask for permissions to your your camera or you want to do a little video so now it wants permissions to your camera and your microphone if you would installed the app and the first time you went to login it says I need access to your microphone and your camera and your photos you may be a bit turned off by the app and say I don't want to give you all those permissions I just want to post some text to this social network that's what dynamic consent is all about it allows you to incrementally just grant these permissions and you can learn more about the v2 end point if you go to aka.ms/offweb rare EES were not able to easily incorporate that into their request so now we use the scope parameter which is supported by all the libraries to compound and combine both the resource and the permission when you build applications with Azure ad v1 you also had to register all permissions the application needed that was called static consent we just went through that a minute ago the user had to consent to all of those things statically but with v2 we can now send scopes that you want at the time you want them we don't have to ask for them all upfront that's the dynamic consent we also going to change the contents of the ID token this is the the token that is going to be included with the response from the login that contains information about the current user like their email address and their name etc and this is going to better conform to the open ID connect v1 specification for example we're using things like preferred username claim instead of a claim called UPN and also in the past if you needed a client application or a single page application or a web app or a web api or a daemon service we had to create multiple azure ad registrations and wire up each of the relationships between each one of those and it was a bit of a pain but now in the v2 this now is going to enable us just one after registration across a single logical application and we can then open up all the different areas that we support for the different applications such as representing a native in a web application if we wanted to for more information you can use that link at the bottom of the slide to learn more about the v1 vers v2 key improvements now let me talk a little bit about working with the different SDKs when it comes to Azure ad now the nice thing about this is that you really are going to self-select yourself into which one you're going to use if you're using the v1 authentication endpoint you have to use the Azure Active Directory authentication library or a towel it only works at v1 if you're gonna be using the v2 endpoint with the dynamic consent and some of the other things we've talked about which is the recommendation from the Microsoft graph team you're going to be using the Microsoft authentication library this targets the v2 endpoint it's got a new conceptual model of two different kinds of applications one's called a public line and once called a confidential client app a confidential client is one that has a like runs and a as a web experience where you can put both the client ID in the secret in the application where a public client application is one going to be it to be more like a native app where I'm not going to be able to provide the the secret I'm going to be prying providing the client ID we also have a couple different platforms on where this is supported there's MSA l net for dotnet client Windows Store asp.net core Android iOS xamarin Universal Windows platform there's a JavaScript implementation and objective-c implementation for iOS and Mac OS and an Android implementation as well now where are we going to register our applications this has changed a little bit over the years but now where we would recommend that you go is to go to the azure ad admin portal that's at aad portal de asher calm now there's a bunch of advantages to using this first advantage here is that you don't need to have a asher subscription to get to the azure ad admin portal you can log in with either a Microsoft account or an azure ad account and you'll see in the demo when we log into this it looks like the azure portal except the options of all the different azure resources that are available to us are all gone except for Azure ad this new admin portal is also going to allow you to create and manage both v1 and v2 style azure ad applications so you can have access to both the v1 and the v2 authorization endpoints you're also going to be able to leverage either a towel or MSA L for authentication and again as I said in the last slide that really is going to be dictated based on what you end up doing with you're using either the v1 of the v2 endpoint but because we're dealing with a Microsoft graph as I said before you really are going to want to focus on using the v2 endpoint so what does it look like well you're going to go to the azure ad admin portal and you're going to create a new application so here I give it a name and then I specify what account types are available to me so I could say that I want to use this is where you're really gonna pick are you going to support work in school accounts in Azure ad or Microsoft accounts and the first two choices that you see they're worth accounts in the organization directory only or organizations in any organization directory that basically is saying is it multi tenant or single tenant the first option is saying single tenant meaning only people inside of my Azure ad or inside of my organization can use this app the second one is multi tenant saying the apps gonna be registered in my as your ad but anybody can use it that has Azure ad and then the last one is saying really anybody both anybody in any Azure ad and anybody with a personal account a Microsoft account or an MSA such as a Skype account an Xbox account or an outlook.com account once you've done that your application has been created and you're gonna have an application ID so you're going to grab that ID and copy that down and then you're gonna have these redirect URIs and this basically it's gonna say once someone logs in where should they be sent or what valid places can they be sent and at the top you see that there's a web option and that's where if I was building a website where would I redirect them to after they signed in but that doesn't work on a mobile experience or on a native experience like on the desktop and so instead we're gonna choose this first option here which is using MSA L which basically is gonna have a special kind of a code that includes the ID of the application that the native SDKs are gonna understand how to work with now the app registration from the azure ad admin portal what you're gonna do is once you log in you're then going to go in and create your application using the portal so once you create your your application in the portal you're then gonna be presented with an overview of your application so here you're gonna copy the applications ID now it's hidden from the slide that you see here but you'll see that in the demo in just a minute but we're gonna make sure you grab that ID you're then also gonna set up a redirect URI and so in that case you have to have a native platform that you're going to be adding that it's a special string that the Yuta he is going to be looking for and to know that you're coming back from Azure ad so how do we implement azure ad authentication inside of a uwp application you're going to add in the Microsoft authentication library dotnet SDK to your application as your ad is going to provide a dotnet implementation of the MSA L library you're going to add that using NuGet and what's nice about this is that the MSL navigation or library is gonna handle all the integration with.net to use the default browser to display the azure ad login and the delegated consent experience you wanna make sure that you're using the most recent version of the application or of the library you'll find the library as the Microsoft identity client library and you want to make sure you're using the most recent one we'll go through that in the demo in just a few minutes so now in the demo we're gonna do two things we're gonna first go create an azure ad application using the azure azure active directory administrative portal and then we're going to go integrate the authentication libraries and do the configuration we need to setup in order to add authentication to our applications so let's go ahead and dive into the demo and do that now in this demo we're going to integrate Azure ad into our UW P application that we saw in the previous demo and the first step to do that is to first go create an azure active directory application so what i've done is i've logged in to the azure ad administrative portal and once i've done that i'm gonna come over here to my app registrations and i'm going to create a new app registration so i'm gonna go ahead and call this my graph tutorial and i'm gonna select that we can use any account for testing this and then i'll just go ahead and click register to go ahead and create the application so once the application is then thing has then been created i'm going to create a copy of the client ID i'm gonna need this later so let me go ahead and just make a note of this now once I have the client ID the next thing I need is ena set up some redirect URLs or redirect your eyes and so that's gonna be a little bit farther down I'm sorry that's right here at the add redirect URI so I'm going to click on this and when I did this it's gonna give me a list of suggested your eyes for the different public clients so by default we would usually be able to type in or select one from this this list right here but in the case of what we're doing right now that's not going to be an option the one that we're looking for is not going to be presented here so instead what we're gonna do is I'm gonna come over here to the redirect your eyes and I'm going to specify a public client for mobile and desktop and I'm going to type the following in your in colon IETF : WG : Oh auth 2.000 d and so this is what we use for a for uwp application is this string that you see right here so once I've done that I'll go ahead and click Save and now my app is all been set up and now the next step is going to be to go to my application inside a visual studio and to start configuring it to use the authentication library all right in this section we're gonna extend the app from the previous section that's gonna to support authentication with Azure ad this is gonna be required to obtain the necessary Oh access tokens to call the Microsoft graph and in this step we're going to integrate the ad logging control from the Windows community toolkit into our application now you saw we had already created our azure ad application so what I'm gonna do is come over here to this resource file and what I'm going to do is grab that ID for our application and I'm gonna paste that in to this section right here so I've got an app ID that's being defined and I've also got some scopes that are also defined with this as well now once that's done I'm now going to go configure the azure ad login control so if I come over here and look at the main page dot sam'l file actually I need to go to the code-behind for this guy by going to here I want you to take a look at some of the code that we've added for this so it's going go fullscreen make it easier to see so here what you can see I've done is I'm loading in the OAuth setting so I'm loading in the settings there are all settings from that resource that we created or that was created and then I've got a reference to the app ID and then all the scopes so get all those all that stuff that's already set up I'm checking to see is assuming that I have these values which we do I'll come down here and I'll initialize the graph so what I'm doing is is I'm initializing the graph using the v2 authentication model and then I'm initializing it by saying app ID passing in the current user profile and I'm splitting the Scopes based on space as you saw a minute ago I had two scopes and there was a space separating each one once I've been navigated or I've then logged in I'm then going to navigate to the home page now this code is going to load all the settings from my off resource file and initialize the global instance of the graph now it's not having me log in just yet but what I want to do is I want to add in a some sort of a handler into my login control so if I look at the right here my sign-in completed on this so I've got this way I'm gonna set the all state to true if sign-in has been completed or completed successfully and I'm gonna navigate to the home page otherwise I'm also going to set the off state to false and navigate also to the home page now when I do this I've come over here to my main page zamel and if you take a look at the login control that we have you can see I have a sign-in process that's been set up both for the sign-in process going this way for the signing completed and for the sign out completed so those are the two methods that we have set up here now the next thing I need to do is inside of the home page app what I'm going to also do is inside of here what I'm going to specify is if the user is currently authenticated where it says they've been authenticated then I'm gonna say go ahead and use this to select the view so we know that they will have already been authenticated and will be able to access the calendar so let's go ahead and let's run this I'm going to switch this back over to the 64-bit emulator I'm gonna go ahead and start the application all right here we go there's the control the sign in control so let's go and click on that and it should be able to log in to our site we're into our ad application so I'm going to go ahead and let's paste in our login and I will do the same with my password and now I've never used this I'm going to go ahead and say that I want to grant these permissions I have to go through the common consent framework the very first time to ensure that I want to accept this so I'll go ahead and say accept these permissions and we should see there we go cool so it's working so we can see that we're successfully logging in with this account and then I can select it and sign out and everything is working exactly as we would expect cool so now that's everything's been set up for this now the next thing we're gonna have to do is we need to start integrating in the Microsoft graph so we're gonna see how to do that in the next section in this last section we're going to look at integrating the Microsoft graph dotnet SDK into our UWP application we're going to look at an overview of the Microsoft graph net SDK we'll talk about the graph service client and then how to go about making requests the Microsoft graph REST API is always available to every kind of an application doesn't matter the language the framework that you're using the platform because all it depends on is just an HTTP request but the Microsoft graft dotnet SDK abstracts away the specifics of calling the REST API and you can learn more about it at NuGet org slash packages slash Microsoft graph it handles updating the HTTP request headers and the other details that are required by the REST API and furthermore it also provides a fluent API for creating Microsoft graph requests so how do we integrate the graph into uwp applications you're going to add the Microsoft graphs UW P dot n SDK to the application and this is going to provide a dotnet implementation of the SDK similar to the MS AL SDK you're going to use new get to add the Microsoft graph net SDK to your project so in this case here you can see that I'm adding it using the new get Explorer inside of my visual studio experience you can also take a look at the SDK documentation for additional steps that may be required depending on the size of your project if you run into issues so how do you use the dotnet sdk well here's a little snippet showing you what it's going to look like so in this case here I'm creating an instance of the graph client I'm doing that by having a method called get authenticated client what that's going to do is that's going to be using the authenticated authentication helper or specifically that's gonna be using the delegate authentication provider to make a request out to Azure ad using the Microsoft authentication library which is all included in the authentication helper that we're gonna create and that's going to include or add in the header value of an authorization header value of bearer space access token that we're going to use to talk to the Microsoft graph so in this last demo we're gonna see how to integrate the Microsoft graph dotnet SDK into our uwp application to go fetch about data for the current user and display it inside of our uwp application or in this last section of the screencast we're going to incorporate the Microsoft graph into our application and we're gonna use the Microsoft graph dotnet SDK to do that so I showed you earlier how we had already added in the Microsoft graph net SDK into our project so if we come over here and we look at our calendar page we create a new calendar page here if we look at the code for this what you're gonna see is a couple of references here to the Microsoft toolkit the the community toolkit and to Newton soft which is going to help us with our processing of JSON now I've also got a new an app page here or a function here called show notification and this is going to show the main page it contains the in app notifications and then so it's going to show the notification control and or initialize it and then go ahead and show this and the unnavigable gonna override I'm going to get a reference to the Microsoft graph instance of the client and then I'm just gonna use that to go ahead and make the calls to the Microsoft graph so you can see here I'm just going to go get all the data from those events and then I'm going to bind those events to the current page on the events list the the grid that is going to be created for the UI of my application so if I come over here and I look at the the sam'l file for this you'll see here that I have a grid setup called event list where it's got just a data grid that's got columns and I'm going to binding those columns to the different elements that we see here now I've also created a little utility here called the converter this little time zone converter and all this does is it's going to convert a time from two different time zones based on what comes back to me as like a UTC time or not UTC time and you can see that it added a reference to that right up here as one of the options you can see this guy that's being created is gonna be referenced right down here inside of the binding that's being set up so let's go ahead let's run our application and let's see this application run right go ahead and run so our application is now loading and once it loads what we'll do first step is going to be to login so let's go ahead to our sign-in button and let's go ahead and sign in to Azure ad using the same account that we tried earlier so I'll just use this account and let me go grab my password and now that I've gone ahead and signed in do you see I've signed in here now I can go click on my calendar and so we should see a list of all of our calendar items and sure enough we do we could see a list of all of our calendar items that are coming back from the Microsoft graph so this is really easy to see it was not that hard to go through and set up what our navigation was how our navigation was gonna work and then how to navigate or to redirect over to Azure ad to go have the user login and then once they've logged in we then went in and added in support for the Microsoft graph to go fetch data from the Microsoft graph and display it inside of the UDP application using the community toolkit grid control now we've reached the end of this screencast for this module you've seen a lot about how to do development with the Microsoft graph based on the topic that we've covered here keep in mind that everything you saw here i