Azure AD App Registrations, Enterprise Apps and Service Principals

hey everyone welcome to another on board to azure and in this video we're going to kind of deep dive into azure active directory enterprise applications service principles and app registrations it's a topic i've been a little bit afraid to try and create a video around um but i've had a lot of people mail about it so i thought okay time to just get this done now i'm gonna stress um this can get a little bit complex um stay with me you may need to watch this a couple of times additionally i'm not going to talk about azure ad for probably most of the video which is going to seem pretty strange i'm going to talk about the why and then once we understand the why i think the what will actually be very easy to grasp so let's think about this for a second i have a person this is going to be me and it's literally a caricature of me so we have this resource owner i have some resource now that resource lives somewhere and specifically there's going to be a resource server so on that resource server i have some kind of data now this could be emails it could be pictures it could be an address book whatever that might be and this resource server makes that available via kind of a certain api now additionally to that there are things that can be done with that data there's actions and we kind of call these scopes so i can think about well there's various scopes that can apply again these are kind of permissions actions whatever term you want to use that could be done with my resource maybe it's write it maybe it's read it maybe it's sent to it there's a whole bunch of different things that i can do so it's me i have that resource on that resource server but i'm the resource owner now to be able to kind of protect that and permission that well something has to kind of know who i am so what we think about is well there's this authorization i'm going to write that as an author z means authorization or n means authentication there's going to be an authorization server now on that authorization server there's going to be some kind of security principle that represents me and what's going to happen is there's basically a kind of trust this particular resource server trusts that authorization server now that authorization server also does authentication then it's also kind of an idp i i can do authentication something like open id connect i can do authorization like a wharf 2. i'm off too but we're gonna talk about that quite a lot today so we have kind of these these three elements to this story now what i want to do is there's a client there's some kind of client here that i want to use now that client could be a mobile app a native client it could be a web server so there's back-end web servers actually running the process it could run with my browser it could be like a javascript single page application there's different types of client here but the point is i want to use that client with my resource on that resource server now we're used to this idea we're used to this idea that hey i've got this app and hey it can go and mail my friends it can go and hook into my facebook feed and we have those little screens that we say hey yes we're going to consent we're going to let it access my pictures that it posts to my wall well behind the scenes that's all authorization delegation that's something called oauth 2. then it was now auth1 but we don't talk about that no one uses that we talk about a wolf too and so that's essentially what i want to do here because what i don't want to do is hey there's this client application and i give it my username and password that's terrible that's what we used to have in the early days before i was we'd have these services that say hey give me a username and password and i'm just going to quickly connect to your mailbox or your services i promise i'll keep it secure i promise i'll delete it i promise i'll only do this we don't want to do that i don't want to give someone my username and password instead the whole point of what we want to do is delegate to that client hey look you can do this on my behalf and that's that's the key point so what we have to do is this client is going to need to interact with this authorization server so the first thing is we have to kind of do a registration this client has to register so this client will also kind of have a representation on the authorization server that's this client app one whatever that might be now as part of that it's going to have a client id and it may optionally have a secret now that could be actual secret or it could be a certificate and that would all kind of those details the id the secret would be part of that object on the authorization server as well so it's kind of an important point that we will actually have that okay so now we get to actually doing something with this i as that resource owner want to use this client and again it could be a web server somewhere it could be a native app on my mobile whatever that might be so i'm going to go and say hey i i want to use you to do this job now that point the client maybe supports lots of different authorization servers maybe it says hey i can log on with google or facebook or azure id or maybe it just automatically ties into one for example azure id now at this point it's actually going to go and essentially redirect me it's going to say hey i'm trusting this i need ultimately i'm going to need some tokens i'm going to need tokens so i can talk to that api over there you're not giving me your username and password so i need to get something in between so what it's actually gonna do is essentially you can kind of think about it redirecting over to here now it's going to send a few things as part of this request it's going to send that client id so that represents this client remember it's got an object over here as well it's going to send a list of scopes that it wants remember the scopes are kind of those permissions the actions it can perform against that user's resource it's also going to send a redirection url potentially this is not always going to be the case if it was a back-end server and actually has an endpoint that's where it wants to get the response to um if it's just a native client or a single-page app that's not going to apply there's also like a state it sends as well but the whole point here is hey go over to your authorization server now at this point if the user is not already authenticated it's going to make them go and do an authentication they're going to say okay they're gonna do that authentication if they're not already authenticated now it's gonna prompt them for consent so it's gonna pop up a little box and it's gonna say hey consent it's going to consent this act 1 for these various permissions ie the scope and i can kind of say yes or no to that now assuming we say yes to that well for one thing i don't want to prompt the user for consent every single time so my answer if it's yes will kind of get remembered against that representation of the application on that authorization server saying okay said yes um remember that fact now because it said yes the next thing it's gonna do is actually send me back an authorization code now i want to be clear you know wolf 2 there are various different types of flow i'm talking about kind of the authorization code grant flow there are other flows there's an implicit flow where some steps are kind of skipped there are others related to server to server to client authentication but they're all fairly similar now there's not a huge variation in them i'm going to focus on what i think is kind of the main and the more secure approach to this but essentially what i'm getting back is this authorization code from that off z server now if i did send a redirection url if this was like a backend web server this is essentially listening on that redirection url that's where this will redirect back to that's where it will send that authorization code to remember that's an authorization code the user had to kind of authenticate do the consent and now i get that code now an important point remember is it did show me in that consent screen it did say hey it's this app and this is the scope these are the permissions it's asking for so i had full visibility into what exactly am i saying yes to when we get into more details later on that ability to actually do that consent well when we talk about azure id there's actually some changes that happen so the ability for a user to do consent against azure id is something i can configure i as kind of the administrator of an azure id tenant can say our users allow to consent or not for new applications so i can control that it's a setting i can go into enterprise apps consent and permissions and i can say hey no they can't or yes they can to fairly low risk or yes they just can so i can control if users can consent or not to those things for azure active directory now notice for that scope initially when that act kind of registered it probably told this hey these are the scopes i'm going to want there'll be something called incremental consent if i do incremental consent it can actually go and ask for additional levels of scope as things evolve in which case the scopes it registers when it first sets up with the authorization server don't really mean a whole lot the whole point of the scopes is designed for the app to tell the authorization server these are the things that i want to really function the best possible way but anyway i get an authorization code back after user consents everything else i get the authorization code now this is where there can be a variation i said hey we have the client and we absolutely do there's actually two types of client i can think about there is a confidential client and a public client and what these really break down to is i can keep a secret or i speak a different color can't keep secrets and where that would come into it's like where is this running if this client was actually running on a web server in me the app publishes data center that i physically secured i'm trusted in then i know i can put a secret in there in my code i can have a secret that no one can really get to so this would be example of kind of like a web-based server so running in my data center a public that i can't trust this could be a single page application say running in the browser using javascript anyone could just go and browse the source or it could even be like a native app again someone might do say look at traffic could kind of see those secrets and this really comes into what what happens next uh a little bit so i can think about okay so we've got these components i now have this authorization code but the authorization code is is really useless to me as a client i can't really do anything i want an access token the access token is what i can use to go and actually get things from this resource server if this is a web server um i can actually establish a back channel a separate stream of communication from the client's browser and go and talk directly to the authorization server now if i'm running on a single page app or a native client i don't have that ability but if i was confidential what i actually do is i want to exchange this code for tokens so next thing that happens is hey on a back channel if i can if not it will still go by the user's device what i'm going to send is that authorization code so i'm sending the code i'm going to once again send my client id and if i have one this is optional i'm gonna send my secret my cert whatever that might be again i may not have one if i do i'm gonna send it that would be if i was confidential i had the secret um if i don't then i'm not gonna be sending those things now you might say well okay if i don't have the secret this all seems a bit risky um something could go and hijack this and that would be a obviously a bad day there are other things i can do so there's something called a proof key for code exchange and what that is it's just kind of a cipher and it's generated by the client so it would generate this cipher and as part of that original request it would send that cipher that unique thing that it's generated and it would then get stored here so then when i go and exchange my authorization code for tokens i would send the same cipher so then this authorization server knows hey look something else didn't grab that authorization code and he's trying to redeem it because they're sending the same cipher the cipher was sent over https nothing could have grabbed that nothing else would know it so it kind of proves i am who i say i am really that person who should be and it's pronounced pixie that kind of weird um that proof uh key for code exchange but that's another way to add another level of assurance that some bad actor has not grabbed that authorization code and is trying to use it so that's kind of the point anyway whatever that is i'm sending the authorization code and the client id now mentioned an implicit flow if i'm doing an implicit flow this authorization code is not used it just sent me an access token straight away and this does not happen i just got sent an access token here instead of an authorization code it's less secure we don't really want to do it i can't get a refresh token that lets me go and get new access tokens on single page apps it's kind of the only thing we could do but even now things are kind of changing around that the whole point is it will take that authorization code and it will now send me back my access token and my refresh token if as part of the scope i send open id i i want authentication as well it would also send me an identity token and now i'm in a good place because now hey i've got my access token i can now say hey api here's my access token here's my request they'll verify that so how he's allowed to do this scope these permissions on that data do things and then send me back my response if my access token expires because remember it's short-lived i will use the refresh token to go back to authorization server say hey i need an access token they go oh there you go and then i continue those communications the user doesn't get prompted again i've given it that authorization that client will continue to work that is a wharf two so we think about all of that stuff that is all a wharf two this is all about authorization there is another layer that sits on top open id connect that is all about authentication and it's a tiny little sliver it sits on top of a wall it just has a few specifics around hey the protocols the format the jwt tokens etc is going to use but it lets me do authentication there's a user info endpoint i can go and talk to to get more information about the user because the whole point is access tokens refresh tokens are completely opaque to the client they can't do anything with it they just pass it on they can't really open it get anything about the user an identity token well i can actually kind of unpackage that as a client and get information about the user oh okay that's their name that's other information i can then go to the user info point and find out more about them why am i telling you all this like what is the what is the point of this i've not really mentioned azure id at all and it's really all about the point of look at those different components think about what happened well there was a client application i had to register it against the authorization server there was a client id there was a secret it had to remember the state of consent maybe i want to revoke that consensus things i need to do about that and there's various scopes that i can use there are identities so now we can think about okay well all of those things how do i map that to azure id and enterprise apps and app registrations and service principles okay so let's think about what exactly are we doing with azure id so what did we need what were the components of this so remember the client or that client application had an id and potentially secrets certificates i had to have those things there were various scopes the permissions that i might be able to get access to then we had to have consent and kind of store a history of well have we done the consent we had to kind of remember those things then of course we had things like the tokens and the users identity the security principle all of those things so we talk about those terms of app registration and service principle and enterprise apps so how does this actually plan out okay so let's let's look at those things in terms of azure id so i can think about okay there is my azure 80 and i'm saying my because i'm going to be the app developer so you can think about this is my home azure ids it's kind of where the app lives in a lot of ways and i'm going to go ahead and i'm going to write my my vision i'm gonna write my act one now what i have to do when i write this application is well i have to register it so if i want to integrate with azure id i have to register the app so what that would then do is it would actually create kind of an app one now what am i doing there well as part of that it will be given a client id okay i'm starting to to get to that part and when we create an app registration azure id we can pick hey is it single tenant i i can only use it within my azure id or is it multi-tenant other azure ids will be able to use my application so i get to pick that so if we actually go and look at kind of the the azure id i can go to my app registrations and i could say new registration and i can see here i give it a name i can pick hey is it single or multi-tenant and i can also register things like the redirect uri so i kind of have those options available to me so at this point what it's doing is i'm registering that into my azure directory now additionally once i've done that once i've done that registration i can configure certain things so yes it's given me kind of that globally unique id now that is globally unique even if i pick it single tenant it's still globally unique but then what i can do is once i've done that registration i can go into the app and i can add secrets i can go and add well what scopes do i want um to actually make my app really really work now when i do the app registration from the portal yes it creates the app so that is the app registrations if i think about what are the objects well that is the application registration hey the the client id the secrets the scopes all of those things we talked about that we would need up here for the authorization server or azure id is the authorization server so what app registration as a construct is is it is the manifestation the globally unique instance of my app and it lives within the home azure id of the application developer and then within there i can go and add hey i can add those secrets as you can kind of see here again i go to the portal if i go to an existing i'll just go back a sec if i go to an existing kind of app i look at my one i can see hey look i can go and add client secrets i can add certificates i can go and specify what permissions do i want um user.read contacts dot read.shared from the various types of api that are available so i can actually go and hey i want those things now additionally if i create the app registration from the portal yes it does the app registration so we get the application object so i think about that app registration that is the globally unique object for that what it also does is it creates a service principle for that application and the service principle is really the local manifestation of that global application object it's used for things like management it's used for things like the scope configuration that's why i can actually go and remember hey a user has consented to these it's doing all of that kind of scope and that consent tracking so that's what i have in addition now if i'm using the ms graph api i have to do the app registration the application object and the service principle creation separately have to do those two steps but i i'm getting that kind of additional object so i have the app registration handling those things so that's kind of the object and then i can think about well the scope and the consent well that's kind of that service principle so that's where those objects are coming in and that service principle essentially is referencing that globally unique now because i'm the app developer it's referencing that object in the same azure id tenant so what are enterprise apps if i go in the port and look at enterprise apps well enterprise apps really is just a list of my service principles it's enumerating the service principles and it's it's showing me them it lets me go and do that management so when i think about how i actually do the management on the service principle i can see the permissions i can do those things well it's enumerating the service principles for applications and showing them to me again if i jump over to the portal so that was the app registration if i now go to enterprise applications well from within here i can see all the various applications i've got there's my kind of savile native app it's running or i can go and see the permissions i've got user incentive permissions i can actually see well which users have actually done that consent i can go and review those permissions i can see signing informations i can see all the properties of it but this is kind of that manifestation this is the management object that i use but this is just the service principle behind the scenes it's not any other magic this is the service principle so enterprise apps is really just to enumerate my service principles and exposing the management um the consent tracking to me that is powered by that service principle that's really all there is to it okay but what about when someone from a different azure ad wants to use it i made my app multi-tenant so now we have another azure id over here with azure 82 and i've got a user over here that hey this app looks phenomenal i i want to use that application so now what happens is well they kind of go and launch the app and remember all of the flow hey okay i'll get redirected to the authorization server the authorization server is azure ad there's not a different set of servers for my azure d10 versus yours it's still the same authorization server still the same endpoint i just happen to have a different tenant where my object actually lives so i once again get kind of redirected and if i was the first user to use this app in my entire organization or maybe as an enterprise admin i'm going to pre-consent for everyone i will get kind of that consent window pop-up i'll get the consent box and if i say yes and i have the permissions based on if i've configured that to be allowed or not at this point it will go and create me a service principle for app one in my azure ad tenant it will not create an application object it is gonna reference that the object for the application in the home tenant of the azure id does not create another one so the application object there's one it is globally unique it lives in the azure id of the developer of the app essentially every other azure id that wants to use it gets their own service principle that references the application object that's the relationship and it's on this that again i would do the management i would do the consent tracking it is the personif the manifestation of the app in each individual azure ad tenant when i think about getting that authorization code and getting the tokens well it's really that that's acting on behalf of the user for that interaction to get the codes get the tokens and everything else that's you can kind of think about as doing that communication for it and if there was yet again another azure ad tenant over here the one that someone consented said yes they would get their own act one service principle that once again referenced that single application object that lives in the home that's it again these would be enterprise apps in that tenant that would now be an enterprise app in that tenant that's literally all there is to it there's really nothing beyond that so what are um application objects application registration service print principles enterprise apps the app registration is what i do as a developer of an application i register my app to create that globally unique app object in my home azure ad there's only one of those for my for the app every azure id tenant that uses that app that's been consented to they will have a service principle that is the local representation of the app it's how i do the management it's how i do the consent tracking enterprise apps is just showing me the service principles for all the various apps that i've consented to that i'm using within my tenant that's it so hopefully you understand that why we took so long to understand what the components are because now you can kind of see well why i need the various parts in azure active directory no if i'm this azure id i'm not giving a developer from app one permissions in my azure id i'm not making them app publishers or app developers they do not need that that's not the point of it this all just happens automatically but i don't want to give users the ability to kind of consent to a new application in my tenant at apps then as an as an admin i would have to do that consent that would be available i can pre-consent on behalf of all the users in my organization so that that is available as well i hope this made sense one at registration for the application one service principle for each tenant that decides to use it a lot of moving parts i really hope this made sense you might please go and watch it again if this was useful please like subscribe comment share until next time take care yourself you

Channel: John Savill's Technical Training

Views: 47,766

Rating: 4.9553695 out of 5

Keywords: azure ad, app registration, application registration, enterprise applications, service principals, oauth 2, oauth 2.0, oidc, consent

Id: WVNvoiA_ktw

Length: 33min 43sec (2023 seconds)

Published: Thu Jun 11 2020