API Authentication with OAuth using Azure AD

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
are you sharing a screen yes let me know if you can see it yeah [Music] right can you see the deck yeah you can see the deck yeah okay so just a quick uh disclaimer that this call is being recorded and we will place our recording on our youtube channel if you don't want to be recorded you may want to drop off now malik floor is yours man all right good morning everyone welcome to another session of azure power lunch and today's topic is api authentication with oauth using azure ad so quick introduction my name is molex sony i'm a senior cloud solutions architect at microsoft and will be the presenter today so before we jump into the oauth and ad and implementing the api authentication there are some key terms um that we want to revisit uh most likely you're familiar with all um so first of all oauth 2.0 protocol right so it's an industry standard protocol for authorization it allows user to grant limited access to its protected resources and it is designed to work specifically with http and what separates the role of the client from a resource owner and soon you will see that there are two type of parties here one is the resource and the client so in our protocol basically client request access to the resource which is controlled the access is controlled by the resource owner and hosted in a resource service in this case is the active directory oidc the open id connect is an authentication and authorization layer built on top of oauth 2 and azure active directory allows ydc protocol as well on top of the oauth so tokens specifically called the jwt tokens json web tokens it's pretty industry standard for exchanging information about users on the authentication and authorization information right these tokens are lightweight security tokens generally you will see passing the better information but it's called the banner token to access the protected resource right so client presents this better token to the server and prove itself to access a resource in terms of azure active directory in this case is an identity provider right and there could be many different type of identity provider in this case we are looking at the ad to implement oauth security and azure ad ensures that users identity permissions and access to the resource are controlled and managed by azure active directory so at any given time if you want to disconnect user change the password you want to go to extracted directory instance and you can certainly do that um in terms of there is a concept of app registration for azure active directory and flows for oauth and ydc so app registrations uh basically is a way to provide authentication and authorization service for the users so as an application owner you register an ad application in your azure active directory and use that ada application to interact for the permission and we will take a look at ad application pretty soon in terms of the flows there are various flows that oauth 2 and open id connect provide right the one that we are interested in this session is called the client credential flow so imagine scenario where you have a client application which is non-interactive is a script or something right it cannot enter username and password when prompted so in those type of scenarios the client credential flow is used which permits a web service to use its own credential instead of impersonating a user right and the last key term is the azure ready admin consent right in terms of um so in order to use the permissions and roles um in azure idiot application the the api permission has to be consented by either a global admin which can consent to the application for entire tenant or an application owner can consent for a given application scope right so the the consent has to be provided before you can use this the scope or the rules from within an ada application so just talk about authentication flow right so it's it's pretty straightforward there are two endpoints on azure id uh one is the token endpoint and second one is the discovery endpoint so client request for oauth bearer token from token endpoint by passing the client id and secret and the token endpoint returns a token after authentication so if it validates the client id secret returns the token back to the client then client calls the the protected resource in this case the api with an access token as a authorization header the web api then performs the validation check to make sure whether the token is valid or not it talks back to the discovery endpoint and it validates the token and then if the token is valid it returns the data requested by client i think since this scenario will help understand more about the use case right so in this specific example our use case is that we have a file upload api and we want to expose this api to multiple vendors imagine you are collecting a videos from different vendors right and you want to expose this api securely so each vendor can have their own credential to upload the data to the api now you want your one of your requirement is that you want to control individual vendors access you should be able to terminate access anytime you should be able to rotate the password in case the client is called the client secret in case if it is get compromised right so those are your key requirements so to implement this you can implement you can secure your file upload api using the oauth and azure id so in in this example when is implemented the console application which is a some sort of a script which does automatic uploads first acquires a token from azure active directory right so as an application owner you provide each vendor a client secret um and then they use that their own specific client secret to obtain a token first once the token is obtained they call upload endpoint on your api with authorization header which has your better token which was just obtained the api once it's called it validates the token and i will share a sample code which does the better token validation so any questions so far okay so in for the demo this is what we are going to do we will register an aad application representing a resource which is the api then we will register and another application representing a client and you can repeat this step for n number of clients of your api then we will generate a client secret then we will go for through the consent process and then using postman we will request a token and i will share some code to validate the token and then i can show you how you can revoke the client access okay all right so we can go in here so go to your you can go to the azure portal and azure active directory and start with the app registrations and first we want to register the application which represent the resource right so add a new registration and i will just type as resource or you may want to be descriptive about which resource you are trying to access and click register that's all it needs now this application now you're in that application the resource application uh we need to do a couple things here right first of all we need to set the application id uri so go ahead and click on this one and set basically this we will be using this application id uri in a as a scope parameter when we make a request the second thing is that um we need to create a role so go ahead and create the app rows create a new role now each res think of it this way your file upload api can have different kind of roles right for example which allows user to upload a file um another role allows user to download a file another user allows user to view the video those are all different roles right what operations are permitted you can define it under the rule so in this case i would say file upload and application and then this will be file upload role okay perfect so this is the setup for your resource azure ad application now you need to register a client so go back to the app registrations new registration and this say client one and register okay so on the client side um first thing we need to do is add an api permission so go to api permission and click on add now what we are saying is that this client application has a permission to my resource api so in this case the resource application you can check file upload role this is where you can specify what role you want to give to the client right let's say you have a client one which can only upload the files then you select only upload in case client two who can do everything then you can select all the roles so this gives you the control of what a client application can cannot do right this roles information will be part of your token and that's how the api application knows what is allowed what is not allowed so now you will notice that as soon as you add an api permission it says that not granted for the tenant right the permission so this is where the consent needs to be granted and there are two ways you can grant the consent most real world um you may not be the global admin on the tenant right so what i am going to do now um is not possible because i am the global admin on this tenant so i can go ahead and grant the consent so this is one way the another way you can grant the consent only to your application scope is if you're an application owner then you can use either the graph api or az rest command with appropriate principal id client id and role information and that way you can grant the permission for your application scope without global admins without requiring global admin to grant it for across the tenant right there are two ways to do this but basically you want this green check mark on this api in order for the role information to be present in the token if this is not consented the you will be able to still obtain the token but you will the role information will not be there and for api to recognize what permission user has the role information is important okay now another thing you need is the client secret right because what you're doing is providing a client or the vendor their own unique client id and a secret kind of a username and password so go to the secrets and certificates and generate a new client secret and one and here you can specify how long you want to do this this allows the rotation of secret um to satisfy our need that we should be able to rotate the secret so remove it if it get compromised so go ahead and add so you want to note down this value here because it's only presented one time and after then you cannot read it so you need to copy it somewhere we put it on a notepad okay so while here um so this is all done on the client side so you can generate as many client application as you want based on your number of clients the you want to copy the client id as well so this client id and a secret becomes your username and password when requesting a token right so these are the two piece of information you need to send it to your vendor and say hey these are your credentials when you make a token call use this information okay i think we are we are done on the setting of the application so we registered two applications again recap here we registered a resource which represents virtually represents our api and all the operations and the roles and we registered a client which represents a vendor who can make certain calls based on the permission we gave to them so with this um we can we are ready to obtain the token so if you remember the flow first thing we need to do is obtain a token so i have a postman here the token endpoint you can the url you can obtain it from your application right so you go to the client and then click on end points and take the token endpoint right so this is the token endpoint that you want to you want to pass it to your vendor say put this as a token endpoint so i will copy this one okay all right so it needs um actually four piece of information to obtain a token apart from client id and secret right so let me populate the client id first this is our client id and the secret um another attribute says grant type you want to pass this information and it will always be client underscore credential right this determines the flow so this is the static value you want to pass for the scope we need to pass the scope id that we set earlier so can go back to the portal and go to your resource application and get the scope id so it's called the application id uri so make sure you replace it anything before dot default so for if the app registration um as your adf registration the scope will always be dot default right so the uri of your app id and then the dot default is a scope so now we are ready to request a token so let me go ahead and do that okay so now we have received the token so this the first step to obtain a token is complete now this token is valid for one hour and user can use this token to make a second call to the protected api so that call looks something like this is you have your post endpoint to upload the videos and client will pass authorization header and this will be your better token what they have obtained earlier right just replace this with a new bearer token so i don't have this endpoint available but this is all it takes for to pass the token from the token endpoint to your backend api so let's take a look at the token itself right what we want to see is the token should have the roles so this is jwt.ms it's a quick way to inspect your gwd tokens and once you paste your token here it will decode the claims and information so things to note here is the roles information right so remember when we created a client application we gave it a file upload role and when client request a token token has an information that this client with this token has a permission to upload a file right so what happens is in the api um this is the code for the api uh to to validate the token right and we will would like to go over on this one so every api endpoint depending on what framework you want to use but essentially you want to inspect a authorization header grab the token from the authorization header and then use a jwt security token handler to validate the token right so in this case what i'm doing is i am validating few parameters so i'm validating the audience uri it has to match the audience uri to make sure that it is my application because remember the token is common for many different application um so you want to nail down to make sure that it is the token that your application is expecting the second thing you want to validate the issuer so you can put the issuer here to make sure it's not forged by some some other issuers then the signing keys um is is validated by this well-known open id configuration endpoint that microsoft exposes right so it will validate the key that has been signed in this token with is in fact the key that we are we're telling that microsoft has knowledge of and then validate lifetime so this will make sure that if token is expired it will throw an error message and issuer signing key so all this information the insure signing key again goes back to the azure and say the signing key that's used for the token signing is in fact the one that we are publishing so in this case then just call the validate token method and this particular call will be successful um without any errors if all the criteria has been matched it will throw an error if one of the validation is failing right if it either token expired or the audience mismatch or the issue or mismatch and this is where you want to return the message back to user saying the token is not valid okay at the same time you can also look for the claims right so let me look at the java example you can do the same for on it as well let's see if i have the claims processing okay so as you remember um if we look at our token we have the specific rules that you want to check against the token to make sure that user has the permission so in order to validate the rules it role is nothing but just a claim right it's a standard claim so in the um verify method you can say make sure this claim exists which is the rules and then this will be the role of your application it's a file upload right if that role does not exist which means that the token you have received is not what the application is expecting okay so i'll pause here for for any questions you don't see any question in the chat perfect okay all right so in yeah in terms of demo that's what i have um see there is one more resource that to share is called microsoft graph explorer so you can use graph explorer for one of the purpose with respect to our workflow here i basically want to sign into the graph explorer okay so once you're signed in uh microsoft graph explorer um exposes a lot of functionality but in in this relevance of this session um if you remember the consent grant or the permission assignment for the client application right so that's something you can do it from graph explorer as well it's called the role assignment so you can go and search for role as the app role assignment if you do the approval assignment using this graph explorer it automatically provides consent for the application scope right so this is another way to um to do the the consent grant for the ad application and all it takes is you need to have the service principal ids looked up and then the resource id this will be your client application resource id and the role id so in this case it will be like file upload role so each role exposes the good information so if you go back to your app roles there is this id identifier right so this is where you can grab the id of your role and with this information when you do the app role assignment the consent is granted and again consent is important for the roles to flow into the token okay now i think that's all for for the demo today thank you folks any questions okay thanks um i mean if there are no questions thanks for presenting and you know everybody thanks for joining the call uh i will upload the recording as well as the slide deck in our youtube channel so thanks again and see hope to see everybody next week thank you everyone have a wonderful weekend thank you thanks thank you
Info
Channel: Azure Power Lunch
Views: 5,645
Rating: undefined out of 5
Keywords: 7-30-2021, API Authentication with OAuth using Azure AD, Azure Power Lunch, Maulik Soni
Id: 59YwW8FrLm8
Channel Id: undefined
Length: 26min 35sec (1595 seconds)
Published: Fri Jul 30 2021
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.