Authenticate and connect 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 going to find in this screencast specifically you're going to 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 in 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 pick 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 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 going to 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 how we've structured this let's go ahead and dive into the actual module itself in this section we're going to talk about authentication with the microsoft graph but really the authentication that we're going to talk about is really related to just oauth2 and azure ad the microsoft graph just takes a dependency on this so we're going to focus just on like the oauth 2 basics and azure ad here so specifically in this section we're going to talk about the oauth basics different endpoint versions that we have in azure id the key improvements that we have in the v2 endpoint and then we're going to talk about a couple different kinds of tokens like the jwt tokens and the id tokens we're also going to look at different types of flows and then how to obtain a token and connect with the microsoft graph and the application then in the top left corner will be able to take that authorization code and then go log into azure ad and provide this code and say i need an access token for this user azure id is going to look at that code and say i can tell that this is a code that i created i being azure id because it was digitally signed by azure id with their private key so they know that the contents of the of the cert of the code are valid because it has a digital signature that matches one that only azure ad could have signed so it trusts uh that service so it will then take that code it knows that in that code it says things like it was uh the user was me if they're trying to access the microsoft graph and uh that it's coming from this application this native app so azure id 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 hand 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 ad 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's going to match is the private key that azure id uses so microsoft graph can say i trust that this access token was created by azure id and the applications giving it to me 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 oauth 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 uh in a scenario for the microsoft graph anymore one of the scenarios is that azure ad only supported in the v1 endpoint 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.com 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 um accounts with um that leveraged azure id 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 going to have to grant all the permissions up front 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 going to let azure ad figure all that out for us so that's one nice thing that's the first two points converged authentication accepts sign in for both microsoft personal accounts and azure id 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 what's 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 log in 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 going to 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 when they log into my app maybe they're only going to use the capability to reor reorganize their email into different folders when they go to do that i can request another access token that says i need mail.read and mail.right and when i do that then the user's only 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 going to go check to see we need these permissions azure id 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 uh an application may like if you were going to use uh 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 going to 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 had 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 endpoint if you go to aka dot ms aad v2 now let me talk about some of the other improvements from the v1 endpoint to the v2 endpoint in the v1 endpoint you had to provide a resource framework to identify which resources you were requesting an access token for and the challenge with this is that some of the open source libraries were not able to easily incorporate that into their requests 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 adv one you also had to register all the permissions the application needed that was called static consent we just went through that a minute ago the user had to 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 up front 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 a 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 openid 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 aed 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 app 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 and 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 versus v2 uh key now there are two primary endpoints for the v2 authorization and authentication endpoint authorize and token each of these can be scoped based on the tenant section of the url now you can use either a friendly domain name of the azure id tenant or the tenant's good identifier can be used so that's what i'm talking about at the very bottom at the very bottom of this table so if you use something like says contoso.microsoft.com and you would put that in that curly bracket tenant section right there you could use that or you could use a good in that location now what that does is that says that your application is only going to support authentication from a specific tenant and that's great if you're building an application that should only be used inside of your organization now it's there's still a setting that you can put inside the app when you create the app that says that this is only what you want to support but by using the url here it's just an extra capability that you can restrict it to if you use the word common in the place of where you have the curly bracket tenant right there what that does is that's effectively telling azure id says anybody can sign in but azure id you figure out where the person is are they in a microsoft account or are they in a working school account such as an act azure active directory and if they're in a work in school account figure out what tenant they're actually coming from if you use the word organizations there then that's only going to allow users with an azure id account or a working school account to sign in and conversely if you use the word consumers that's only going to allow users with a microsoft account to sign into this application now let's talk a little bit about this authorized endpoint so you can learn more about this at developer.microsoft.com graphs slash docs slash concepts and then slash off underscore v2 underscore user now the response mode is going to indicate if the data should be returned in the query string or if it's going to be using sent back using an http post now what you're going to see in what you see here is we're using the query string so in this then this authorized endpoint what let me explain what the context here is here for this so what you're going to do is you're going to be sending the user across to azure id from your application and saying i need you to authorize the application for use now when you do that when you send the authorized endpoint you're going to specify a few things notice that you're sending the client id that's the application id in azure id that you want to use the response type of code now that's using a specific type of an oauth code we're going to talk about flows in just a minute different oauth flows but what they are are just different options or ways that we can obtain an access token from an author an oauth supported service like azure ad in this case here we're using the authorization code flow the redirect uri is where should the user be redirected upon a successful authentication and the i'm going to jump ahead a bit where you see state at the bottom that state value will always be sent when they are redirected over now the reason we do that is so that somebody doesn't try and spoof your login and say i want to they send they send you to go log into your app from some other location this way you can ensure you can check to see does the state value does it equal what you told what you gave the user when they went to go log in it's nothing special to the user this can be anything that you want it to be now how do they get sent back over to the application well that's the response mode should they be sent using a just a standard query which when you say mode query that's effectively just doing an http get and it's going to include the authorization code in the url and the state value in the url but if you use the the option form post then it would do an http post back to you with the value inside of an encoded payload the scope option there this is a space separated list of all the permissions that you want access to when the user goes to authenticate so this is a space separated list of all the permissions and it may also include a id scope and open id scope for an id token 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 adol it only works with v1 if you're going to 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 client app and one's called a confidential client app a confidential client is one that has a uh like runs in a as a in a web experience where you can put both the client id and the secret in the application where a public client application is one going to be more like a native app uh where i'm not going to be able to provide the the secret i'm going to be providing the client id we also have a couple different platforms on where this is supported there's msal.net for net client windows store uh asp.net core uh android ios xamarin universal windows platform there's a javascript implementation an objective-c implementation for ios and mac os and an android implementation as well now let's talk a little bit about this thing called a jwt token the jwt token also referred to or spelled out or the way you say it is jot token and what it stands for is a javascript or a web token um what it does is it has it's a format of three separate strings that are separated by periods so the first section is a header second section is the payload third is the sec is the signature so let me just first do the signature this is the easiest one what the signature is is this is going to take the header and the payload and it's going to digitally sign the encoded version of the header and the payload using a using a private key a secret now what's nice about this is that the service that is creating the token they're going to publish their public keys and so what you could do is you could go obtain the public key from azure id and if you're you know that you can decode if the signature that you decode with the public key if it matches the header and the payload then you know it's valid and the way the reason why you know that is because only the public key can only decode something that has been signed with the private key and the private key is going to be held under lock and key by azure ad so you this is a way that you can ensure that when you get this this string that it was actually created by azure ad and so you have a level of trust with azure ad all right let's jump back the header section what is that this contains a list of what kind of a token this is in our case it's a jot token but it also is going to contain the algorithm that's used to digitally sign the algorithm so when you have like the key that's been defined it's also going to define things like what key is being used if there's a specific key so like in the case of azure id they use multiple keys and so what you want to do when you want to decode this you would look at the header you look at the key that the type of key that's being used in the algorithm and there's a well-known url that you go to azure and you can say give me a list of all of your keys and then you can take that response look at all the keys that are public keys that are available find the one that matches the one that's listed here in the header and then use the public key in that response to compare it against the signature that i just went through a second ago now the payload section is going to contain a bunch of claims this is all base64 url encoded so you're going to find things that say like aud iis or sorry iss nbf exp and app id so if you go to jwt dot ms you can see you can decode one of these tokens and see what's inside of it so aud what that stands for is the that's going to give it the audience and that says this token is only available for this this resource so think about it like keys in your houses the audience for the key that i have for my house is my house the front door of my house the audience for your key is for your house or your apartment or whatever wherever your whatever the key is for you can't take your key and use it on the front door of my house or my apartment because the audience of your key is not equal to my house or my apartment so that's how that works that's how we can tell when that when i take an access token a jot token and i deliver that i hand that over to the microsoft graph well after they've validated the token when they look at the contents of it and they look at the aud the audience it can check to see is this token even meant for me and it's up to you to decide yes or no now in the case of the microsoft graph and in the scenario that we're going through here you don't need to worry about that because that's all going to be taken care of for you um in terms of the payload so let's talk a little bit about the payload some of the other stuff about the payload what about the issuer this is going to give you the id of who issued this token so what tenant did it come from you could use that to check and see did this purse is this person coming from my tenant my organization or maybe you only want to accept authentication from a specific tenant or maybe just your customers you would have a list of all their azure id directories and you could white list those nbf that says that this access code is only good or access token it's only valid from a specific date time and then exp says it's only valid until this time so you have a nice little window when it's available the app id is also a list of the id of the application that says i'm only going to allow this application access to um uh i'm going to accept the access token for this specific application so you can see there's lots of stuff that we can do with this access code now there are not there are multiple kinds of tokens that we can use they're all i kept using the word access token in the last slide but what i really mean by that is they were all jot tokens these jot tokens are used in different can be used in different ways so we can use them as id tokens as access tokens or as refresh tokens they're all jot tokens or jwt tokens the format and the content of the tokens is going to depend on what the different formats are so for an id token these are going to be consistent for microsoft accounts as well as with work and school accounts in azure ad these are typically used with the openid connect protocol and it's going to contain all the claims that you would use to sign in the user to the app so maybe their email address and their name stuff like that access tokens are requests to include metadata such as additional data in the payload such as like the scopes what permissions that does this access code or this access token include so like mail.read or mail.right you really should avoid the need to parse it when you're using something like microsoft graph you don't need to worry about this let the microsoft graph deal with everything with the access token the v2 endpoint is also going to return metadata including the expiration and the scopes for the for the access token resource tokens are also multi-resourced and this is really cool what this means is that a refresh token that's received in a token request for one resource could be redeemed for an access token to a completely different resource and you may think that that's a little insecure but when you think about it really what it is is it's just saying that the user doesn't have to log in again to get an access token to call a different endpoint they can use that same refresh token and an existing access token to get access to it because the access token like think about an example here let's say i was going to use i needed an access token to talk to sharepoint and then i also needed one to talk to the graph well in both cases i'm going to have to authenticate so once i've authenticated to the graph and i obtain an access token in a refresh token i could take that access token in conjunction with the refresh token and go back to azure id and say hey can you give me one for sharepoint as well without prompting the user to log in again azure ad already knows the user's logged in it's already been validated we already have an access token that proves that azure id knows the access token's valid because he signed it so he can decode it so there's no need to ask them to authenticate again now maybe they don't have permission or they haven't granted the app permission access to sharepoint just yet well that's going to kick in the whole common consent framework that may require them to go back through and consent to the application and we'll talk about that part of it uh in a minute so how do you go about getting how do you go about creating an application in azure id well you're first going to register an application inside of the azure ad admin portal and when you do that that's going to generate an app id so you see that listed here on the slide creating an application secret is required because it's also a web url uh in the in the case of the graph client sdk this is going to be what we call a confidential client which is one that contains a secret in this case here we're not seeing that on the screen but the client secret that would be required in the case of like a web um a a a website um because it's gonna be calling back to a web url uh for example like in a asp.net application it's going to be reaching over to azure id from server side and the app needs to be able to register into azure ad there are other kinds of applications where we would not use a secret such as native apps that would be like on a mobile experience or on a desktop the reason why we don't use a secret in those cases because we're going to be distributing code and we don't want to distribute our secret in our code because well once it's been distributed it's no longer a secret so let's talk about how do we authorize an end user now we talked a little bit about what this looked like a few minutes ago when we talked about the authorization endpoint the authorization endpoint is going to prompt the user to sign in and then once they've signed in they're going to have to grant consent to the requested permissions and you see that in that screenshot there on the slide once they have then accepted those permissions that are being requested so like in this case here we see that the scope is for offline access for open id for profile and for user.read so those are the four permissions and you see all four of those listed on the right hand side once they've gone through and they have accepted that what's going to happen then is it's going to redirect the user over to the redirect url but notice that i have the code is listed there in that um in the query string that's because at the top you saw the response type was equal to code so that is a authorization code that then as that then the web app can use to call back to the token endpoint with azure id and ask for an access and a refresh token now common mistake developers make is that when the redirect url doesn't dir exactly match the one of the redirect urls are configured for the azure id app it's going to have an error so for example let's say for instance if there's a trailing slash or not if i don't include that trailing slash well i would get an error so once i've got an authorization and i've obtained that authorization code or that we looked at just a minute ago the next thing is to get an access token so how do we do that so you're going to issue a request to the token endpoint you see that on the first line you're doing that with an http post now when you do this you're going to be submitting a whole string of information here and so if you look at that body that's being submitted where it starts with client id there's a lot of stuff that's in there what that's going to we're going to include is the id of the app and the secret so you see here we've got the client id is equal to 50d 65 etc and then the client secret is some sort of a secret that's been defined you see this the permissions that we're requesting a token for in this case here offline access openid profile and user.read now if the user does not have those has not granted those permissions then azure id is going to prompt the user to grant it those permissions so what you have to also tell it what kind of a grant type are we doing and in this case i'm saying i'm using an authorization code when you pass that in you also pass in the code parameter that we obtained in the previous step when we did the authorization endpoint and then i say hey once you've done that i want you to redirect me back to this url so the response i get back you can see there at the very bottom i'm getting a token back you see it's a bearer token it's going to list out this all of the scopes now in this case here you see it just says user.read that's because the access token um is only going to be for the user.read where those other tokens like the offline access openid profile those are for different tokens like the id token here we can see that it's going to tell me when does the token expire it's also going to give me a property of the access token a property for the refresh token and a property for the id token in each one of those are the jot tokens that i can pull out now once i have my access token now i can call the microsoft graph so the access token is going to be used as the value for the authorization header in the get request to the microsoft graph that you see there at the very top some data such as http headers have been omitted from this slide here just to make things a little bit simpler but you can see that i'm adding in that authorization header and then i can make my request and you can see i'm getting my data back from the microsoft graph now we're going to look at a demo on how to do this and we're going to do this we're going to simulate do most of this stuff by hand as much as we can and not using any libraries what we're going to do is we're going to use powershell to issue the request so we're going to do powershell is going to first create we're going to use a powershell script that we're going to provide that is first going to create the url that then the user has to copy and paste in the browser because they have to do an interactive login once they've logged in they're going to get a authorization code back so once you get that authorization code you're going to go back to powershell paste it into the powershell interface and then it's going to let the script continue which is going to issue the http request to the token endpoint to obtain an access code a refresh code an access token a refresh token and an id token so let's see how to do all that now all right in this first section we are going to show you how to obtain tokens and connect the microsoft graph using strictly just the rest api protocol the first step is going to be to create a application in azure ad that we're going to use to get tokens using the microsoft graph rest api so i'm going to go ahead and create a new app registration and i'm going to call this my graph authentication test and when it asks me what kind of accounts we support i'm going to use the accounts for any directory we can use anything right here and i'll go ahead and say register now once that's done i'm then going to come over here to adding a redirect uri and i'm going to specify a redirect uri of https localhost 44326 and it really doesn't matter right now you just need to make sure that you keep track of what you're going to use i'm going to save my changes now the next step i'm going to need to do is i'm going to need to create a certificate or a secret so i'm going to come over here to certificates i'm going to go create a new client secret and we'll just call this my one year secret and once this is created you need to make sure that you copy this down right now because if you don't it'll never be shown again so i'm going to come over here grab this and i'll just put this inside of notepad and actually now that i've done that i should go back and also fetch the application id the client id for my application as well so let me come over here and let me keep track of that at the same time okay so now we have these two things now the other thing we need to do is let's come back over here to our authentication piece and what i'm going to do is i'm going to tell it that we want it to also include on the implicit grant i'm also going to include the id tokens this is going to indicate that i want an id token along with an access token and a refresh token we'll see where we get this a little bit later on so i'll do that and then i'll go ahead and click save now the next step we're going to do is i'm going to go use powershell to go execute a call using the rest api so what i'm going to do is i'm going to paste in a big blob of powershell big big snippet of powershell but we're going to walk through and explain kind of what what's going on in here so let me go ahead and create a new powershell document and paste this in and let me explain what's going on here so i've got this method here called get user get current user profile and this is the this is what we're going to pass into it now when i pass this in let me scroll down a little bit let's see what we're looking at here so here i'm going to be getting for the client id i'm going to be getting the username and then i'm also prompting for the current password and then i'm also going to specify a client secret now that's what's going to be passed in i got my credential that i'm defining up here and then i've also got my scopes and my redirect uri and my display tokens now once i've done that i've then got going to specify the v2 url and i've got a bunch of the values that are being set here so i've got scopes that are being set up i'm going to set a code grant is what we're actually looking for adding the apps application id add the redirect uri a couple other things as well all right all these different things that we're going to grab here essentially what this script is going to do is it's first going to create a url to authorize the endpoint and then it's going to by providing the client id permission scopes in the redirect url now if i attempted to use this method invoke rest method right here to this endpoint the result would be the html content of the resulting login screen and you're going to need to log in and authorize this application so i'm going to need to copy copy the url to the browser in order to do that so what i'm going to do here is i'm going to go ahead and run the application so i'm going to run the script it's like this and then it's going to go ahead and prompt me for the username and password now what this using password is these are the client ids in secret that i got earlier so let's go ahead and grab the client id and paste that in and then i'm also going to grab the secret now it's going to return back a url so what i need to do is i need to grab this url and paste it in the browser so let's go grab this url and we'll copy this and go over to the browser and let me paste it in now when i paste it in so it's going to prompt me to sign in so let me go ahead and let me sign in and it's going to also ask me to grant the application these permissions that it needs so access my data and then also sign in and read my profile so what i'm going to do is i'm going to go ahead and leave both of these options here which i can't really do anything with them i'm going to go ahead and i'm just going to go ahead and click accept now when i do this the browser is going to take me back to a page the redirect url that i defined earlier that https localhost 44326 but there's nothing listening at that url that really doesn't matter right i'm going to go to this broken page here and i'm expecting that to happen what i really want is the value of the query string i want this big code that i see here on the very end so let me go ahead and let me copy that code out and i'm just going to paste it over here this code is going to be good for just a couple minutes so what i'm going to do is i'm going to copy this code and i'm going to go right up until the session state so i think that's right here i don't want the session state all right so put the session state like that now i'm going to go take this code and i want to paste it into the powershell window that was something that powershell was looking for so here's the code that it's looking for now what this code is what this code is going to do or what the app the script is going to do now is it's going to take this code and it's going to go to azure ad and say i need an access token for the user that logged in for the microsoft graph and uh i need uh all the the scopes and permissions that this user is granted and so this code azure id knows that this code was created by azure ad uh to um to to display um or by it was created by azure id when i went and logged in and it knows that it was for the microsoft graph and i granted these different permissions so it does that because it knows that this has been digitally signed by with the private key of azure ad so i'm going to go and paste that in and hit enter and what that is going to do then is that's going to issue a call a rest call back over to the microsoft graph and notice that what it's going to give us is a complete or to the azure id it's going to give us a complete azure id oauth access token it gives us a refresh token as well and then it also gives us an id token and then if you look you can see here of the result that came back this is some of the information that came back from the id token this is going to give us some information about the current user so what i want to do now is i want to go get this take this access token so let me copy out this access token and i'm gonna go put this over here in notepad again and i'm just going to make sure that all this is on one line there we go so we have everything now on one line now what i can do with this code is let me go take this if i come over here to jwt dot ms and i drop this code in and if i scroll down you can see that this code has now been decoded and we can see things like where it came from we can see that we did password authentication we see the name of the app we can see the id of the app which we can tell we can go back to our notepad here we can see the app that we use so there's the bff 852 and sure enough bff 852 we can see the name of the application or of the user that signed in i can see all of the scopes the permissions that were requested so we need an open id we need a profile we need user.read and we need to access the email there's the unique name for it uh for the user we got all that information back right this is pretty cool we got all this information back just by making a simple uh rest api call over to azure id to log in in this second section we're going to talk about authentication and connecting with the microsoft graph and i'm specifically going to talk about the protocols that we have in the v2 endpoint for azure ad we're going to start by looking at the authorization code grant and then look at other grants as well like the implicit grant and the client credentials grant these are all referred to as grants you see on the slide they're also referred to as oauth flows and then i'm also going to talk a little bit about the open id connect so let's first talk by looking at native applications and what are these so a native app is like a mobile or a desktop app and these are the kind that we're not gonna really use uh have any kind of like a secret that we can use with our application so what we have here are four different swim lanes in this uh sequence diagram so on the left hand side you've got your app on the far right hand side that's what we want to talk to at the very bottom you can see there i want to get the user's information and i want to go to the graph endpoint of slash v1 me and the whole idea here is that i need to get an access token i need to get an access token because that's the only thing that graph is going to respond to graph supports the oauth 2 um authentication protocol and specifically it supports or it trusts azure ad and so those two swim lanes in the middle that's what we're going to use that's azure id and there's two different endpoints there's an authorization endpoint and there's a token endpoint so the authorization endpoint his job is to make sure that the current user is authenticated we know who they are and they have access to the thing that they want the token endpoint is that now we already know who they are now we're going to give them a token all right so how does this work so at the very beginning of an application the application is going to send the user to the azure id authorization endpoint and it's going to pass in really two things are important the first thing is going to be the client id so what azure 80 app that has been created what do they want to sign in with what what app is going to be granted permission because if you think about it there are three pieces that and that are involved in this whole authentication dance you've got the person that is involved in this you've got the application which is not just the code but it's also the thing that we're using that is going to talk to the graph and then you've got the graph well the user has to give the app permissions to talk to the graph and the way that we do that is we store all that information inside of azure id where azure id stores it for us but you have to do that by registering a new app inside of azure ad and so azure id keeps the whole app and user and endpoint it keeps in the in the permissions that the user grants the app it keeps that whole kind of combination it keeps that in its own database so what i need to do when the app goes to register goes to login it needs to specify the client id that it needs that it wants to connect to or the app id it's going to use that we're going to grant access to the graph the response type of code that's just saying i want to use what's called the authorization code flow so when i send the user over they're going to sign in and if they have not i'm also going to specify that i want to make sure this app has access to the graph and let's just keep things simple right now let's just say that it just wants to connect to it so we can have all kinds of permissions that include but let's just say we want to connect so the user is going to sign in and if they if azure looks in its database and says i have no instances of where this user has granted this app permissions to the microsoft graph then it goes through the consent framework and what the consent framework does is it's going to prompt the user for a um for the permission that it needs all right it's going to prompt the user for the permission uh that they need to grant it and so that's where we're going to get the common consent framework where the users have to say i accept these permissions i delegate this app to have access to that endpoint and once that's happened when that happens the azure ad is going to return what's called an authorization code back to the application now this code is only good for just a couple minutes so what this code is though is it's also digitally signed by azure ad when the application gets that code the one thing i want you to take take note of here at the very top of this slide so right in this section right here the user has never given the application his username and password all the authentication happened over here in azure id so when azure id gave the authorization code back to the application the application well that's great but it doesn't know anything about the user and so what it does is it says i need to give take this this authorization code and i need to go to the token endpoint and say i need an oauth access token and i need it for the microsoft graph and so what azure id is going to do is azure id is going to take that authorization code that we passed right here i'm telling it the grant that we're passing it is authorization code type it's going to use that code to look up in his database and say first of all do i know that this is andrew or whoever this user is do i know who this is and then has this user granted permissions to the microsoft graph on behalf of this application and so what it's going to do is when it says sees that that is true and it knows that this who this user is because it used the code and that code has identified who the user is azure id trusts the code because he created it he will then create an access token and optionally a refresh token and an id token and hand all those back to the application and the application is then going to store all of these tokens for use for later use so let's say the first time you the application then says all right let's go to the graph and let's get the user's profile so it's going to make that request to v1 me to the graph.microsoft.com endpoint and include the access token the graph is going to look at the access token it's going to see as we've already gone through in this in this section here it's going to see that hey this access token is for that user right it was for that app and it has the different permissions that are in it and knows all that stuff about it saying that this is this is valid and it's from azure ad so it trusts it so it knows that it trusts that whole component and trust that that request and so then it will return back the data that was requested here to the user profile now let's just say uh about 10 hours goes by that access token's only good for an hour so once and out once a couple hours have gone by well now it's gone so what happens so what's going to end up happening is is that access token is now invalid so what the application needs to do is it needs to go get a new access token that is not expired and it does that by reaching out to the token endpoint and says here's a refresh token and here's my access token this refresh token is basically a way for us to say hey i've already authenticated and the refresh the access token is no longer good so i'd like to request another token that is still good without making the user log in and if the refresh token's got a much longer lifetime so if i'm still inside that window then azure id will create a new refresh a new access token and a new refresh token and a new id token and hand all those back to the application who he's going to then update his little store for all that user and then use the new access token to go make the request so that's how it works with the mobile in a native application all right so how does it work if i'm using like the microsoft authentication library well in this case here we're creating something called a public client because what the public client is it means we don't have a password or a secret that we can use for our app so here i'm defining my scopes i've created an instance of the public client by saying dot create dot and then passing in the client id and then once that's done i can then say go try and obtain a access token so i'm going to say go try in a token a time silently or interactively i try and get it silently and what that does that's the whole process of do i already have an access token that's not expired if so we'll use that otherwise if it is it expired then let me try and use the refresh token to fetch a new one and if both of those fail so right here those fail and it says hey the microsoft authentication library is throwing an exception and says you need to do an interactive login or what's a ui required exceptions what's failing then i can say okay let's go do a acquire token interactively and that's what's going to pop open the login box in azure id and the consent framework to obtain my refresh token my access token and my id token okay so what about if i'm in a javascript application well in this case here we've got a thing called the implicit grant and what the implicit grant is is that this is simply saying that we are not going to require you to use a secret and everything is going to happen client side this is good for like single page applications or javascript uh client-side only applications and when i say javascript client-side i mean like like a react-based app or an angular app not an app that is like built with node.js that has a server-side component so the call to the common slash oauth v2 authorize endpoint is going to pop up a login request and maybe a permissions consent request at the same time but what's different about this is i don't have to go back to the token endpoint it's going to include the access token in the request now notice i'm not getting an id token and i'm also not getting an a refresh token at least in this case you can you can say i also want to get a id token as part of t