Introduction to IdentityServer for ASP.NET Core

hey friends I'm Scott Hanselman we're here at Microsoft Virtual Academy and we are going to talk about identity server we've got Brock Allen from identityserver.io we're going to learn all about this great open source open ID connect and oauth 2.0 framework for net and we'll build an application we'll do some real authentication today yep thanks for coming yep thanks for having me all right so let's take a look at your browser here you're an identity server.io this is the home page for your your product your open source product yep so yeah so um we my colleague and I Dominic he and I have been working on identity server for for many years and have had many versions and Evolutions over the time and we are trying to help allow customers to build a what's called a security token service this has to do with doing authentication and web API security within your application um sort of ecosystem okay so like right now when we see hello world examples I go file new project file new project and I just end up having my web API call all other apis web apis it's usually no security at all right well um yeah in file new project yeah maybe by default there's no security enabled but that's absolutely something you have to think about and you have to architect into your into your application ecosystem um and so you know of course security is a huge huge topic that's important for everyone to to get right so that's again another thing that we're trying to help with well and even worse I've seen people just roll their own security where they'll have like well just use this HTTP header right we'll have keys that we'll put in a table and then we'll just revoke the keys if there's a problem right and so I suppose you could roll things like that but you're building and inventing your own security we're focused on these protocols called open ID connect and oauth 2. and the idea with these things is that these are protocols that are developed by a large number of people really smart people who know about attacks and and you know they think about these problems and then there's a larger group of people who then read the specifications and they try to poke holes in it to find vulnerabilities or whatever and so um you have a lot of eyes on the specs to help make sure that you know if there's a problem with it it's going to get it you know fixed and and some you know we're going to have a solution to that security problem if you roll your own you know no guarantees that you have enough people looking at it cool except maybe except maybe the bad guys so it makes sense I should not be rolling my own typically if you're writing an application unless it's the next great identity server then you should just use some of the good open source protocols and applications that already exist cool um so can I give you like a little bit of overview of the the the problem space that we're trying to address here so um this is the identity server.io website just a bunch of information about identity server we have lots of links here to offerings that we have one of them is the documentation for identity server and so what I'm going to show you here is sort of the the big picture of um what we're trying to solve with uh with this these protocols but also specifically with identity server so this is a picture showing the the kind of typical kinds of applications that people are building these days and so what this is trying to show is that we have you know server-side web applications uh we might have javascript-based you know Spa style applications sure we might have native mobile or even desktop applications like installed into your you know desktop operating system and so these applications want to know who the user is okay that's authentication right um these apps then of course to perform a lot of their functionality probably are going to be using back-end apis and so those apis also want to know who the user is so what we're trying to do in um you know in our security architecture is identify the user authenticate them and then be able to invoke apis on behalf of that user interesting in the past in the last 10 or 20 years at least in the windows space I've seen things like impersonation sure like an entire thread becomes the identity of someone sure we saw dcom 15 20 years ago trying to call some rather than explicitly calling on behalf of they were trying to pretend to be that person and trying to flow that all the way to the back end it was very fragile and frustrating uh sure um and on this on the other hand though um it was I absolutely agree with that but um you know in back in the day you know you would get security kind of by free in IIs checking the little check box integrated Windows authentication to enable what you're talking about modern apps and modern deployment scenarios make that harder to use imagine you take your web app and running on your web server and previously it was domain joined and that checkbox was checked and so your user coming in if they're on the domain they just get authenticated into your app and you don't have to think too much about it take that web server and move it to the cloud it's not domain joined anymore and you know those older security protocols that we relied upon like Kerberos right um can't work in these more modern and um more modern deployment scenarios and more modern apps same problem with your like your IOS app right you know domain join your your iOS your phone um so anyway those are the problems that we're facing with these modern application architectures okay so um so this picture's showing them the kind of high level idea of what we're trying to build and again as you mentioned every point in here every Network hop is where we want to do some sort of authentication so every arrow on here needs some sort of security check so the idea is that when you're calling from the browser to your server-side MVC app that server-side app needs to know who the user is and that involves something on the network to prove who the user is and then same thing from the web app to the web API same thing you need to pass something along the network to prove that identity do do each of these things necessarily have to be.net these apis could be in PHP or python or whatever what point what's that what's.net and what's not right so um the protocols that we're about to describe here are openid connect and oauth 2 are they were quite anticipated because they were facilitating a lot of interoperability so the design of these Protocols are allowing you know an interoper mix of different technology stacks okay so anyway let me let me go um and talk about the protocols here so if you want to do security in your app and API you could use like the templates out of the box for visual studio file new project and you have your own login page and you have your own cookies that are being issued by your web app and you may have accounts and registration code and account linking from a Google login and the problem is that's fine but the minute you build a second app and a third app and a fourth app you're duplicating that code in all three of those locations so same thing you don't want to you know you wanna centralize that kind of thing especially when you have lots of apps and lots of apis so that's there's a pattern that has evolved over the years and this has actually been a pattern for a long time now of taking all that stuff out of your apps centralizing it and that's what's called a security token service think of this as especially with microservices being the you know kind of buzzword these days the security token service acts as your centralized ident entity service for all of your applications so its job is to know who your users are be able to authenticate them and then what it's going to do is take that authentication result and convey it over to your apps and apis okay so in the pattern of microservices it's all about single responsibility or minimal responsibility in this case it's the STS is itself a micro service you can think of it that's job is to do the author absolutely all right that makes sense so the problem here of course is that the security token service might be running on a totally different domain right maybe it's running the cloud and your apps are running on-prem or vice versa so we somehow need to securely across basically the internet convey the outcome of that authentication to your apps and to your apis so as the name implies security token service it's going to be creating tokens and the tokens are what we deliver back to the apps to prove the identity of the user and tokens are what the app and and we'll use to call the API and these tokens are are significant they're not just a good or a string there's they're cryptographically significant Json web tokens are the typical tokens that we use um in these more modern protocols open ID connect and oauth 2. um so yes so the the token contains information about the user and it's also going to be as you said signed so there's a digital signature and the signature is being created by the security token service itself okay so they encapsulate best practices and I assume that they expire in different things different whatever you need them to do they can sure sure absolutely so there there's a whole um like once you set up the basics then you actually have some more architecture to sort out about things like session lifetime how often do you do you expire these access tokens how often does the user need to go back and re-authenticate so absolutely every environment has different requirements so those are things that you are still going to have to think about and figure out what your what Your approach is going to be but that's the benefit of using a more open system like this is you have the ability to make those customizations and make those decisions yeah yeah specifically with identity server so um so actually I guess we'll get into that but that's exactly the idea here is identity server is a framework for allowing you to build your own security token service okay so it's not so identity server is more than just a security token service out of the box it is a toolkit as well for you to build your own right that behaves the way you want it to work we like to think of it as a framework and so you pull it in and it's sort of like jQuery or even kind of like MVC it's a library You Pull It in and you build around that to solve your you know requirements yes that makes sense now there are other security token Services out there okay there are paid products that you can you can buy uh to solve this problem as well um some of them are um you know deployed on-prem some of them can be deployed to the cloud a lot of cloud hosted so ping Federate is an example of one a commercial and it's very popular in the Java space um some of the cloud hosted ones obviously Azure active directory is a is a cloud security token service that that Microsoft offers um there is a company called OCTA that provides one there's auth zero and there are a number of others as well so it's actually quite a saturated space so there's security token Service as a service yes like you someone else hosts it handles it for you and then there's ones that you can host yourself and you have more control over the flow and the experience yes exactly so the reason we built identity server despite fight this being a saturated you know market for security token Services is that we found that when we were doing security Consulting for our customers they obviously wanted this centralized identity management this also gives you single sign-on and so there are a lot of benefits to it but the business requirements that our customers had the token services that they were using is like some of the cloud hosted ones or the paid products they weren't flexible enough to allow the customer to actually do things the way they wanted to okay so that's actually why we created identity server is uh provide you a framework that does all the hard security stuff according to the specs right but allow you to do the kind of customization and provide you the flexibility that you need okay so our goal over the course of the day here of this MBA we're going to actually host our own security token service on identity server four exactly and we're going to then make both a web API and a web app and they'll communicate with each other via that security token server risk in a secure way and and according to the standard as well so the open ID connect and oauth 2 protocols um so again one more thing about this the beauty about the protocols is that yes you can stick in identity server but if it doesn't work for you down the road we're talking all protocols so you can swap it and pick something later on if it suits you better down the road absolutely but yeah in terms of what we're doing today identity server is going to be the the token service to use all right cool all right is that a good overview yeah I think that actually that gives us kind of an idea of what we're looking for all right so we understand the problem space and we understand what we're going to try to accomplish today we're going to take a quick break and we'll be right back and we'll start building and writing some code hey friends I'm here back with Brock Allen on the Microsoft Virtual Academy we're talking about identity server we talked about the introduction we got a sense of the problem space now we're going to get into some code but before we do that you've got kind of a really nice interaction diagram that's going to explain to me the interaction between the client between my code and the identity server middleware absolutely so ident server is not an out of the box product per se where it's like an MSI and you install that onto your server as we mentioned before the whole point is to provide a framework where you build the product you are gonna you're gonna build up your identity you know and security token service so the way identity server works is that identity server is based on asp.net core okay and the idea is that it's delivered via nuget package okay and it is in terms of how it wires into asp.net core is it's predominantly implemented as a middleware okay okay so what you're going to do is you're going to host um you're going to build a host around this identity server grab the nuget put the middleware into the pipeline okay and the job of the identity server middleware is to implement the end points for those protocols that we talked about open ID connect and oauth 2. okay and just to make sure I understand this I'm not necessarily going to take the app I want to protect and add identity server to it I'm going to make a separate host because I am implementing an STS yes exact token service so this is a file new empty web app exactly that's the idea we do have some templates by the way so.net core has some when you dot net new you can actually specify a template so we actually do have some templates excellent Visual Studio doesn't yet support them but I think it will at some point so within Visual Studio you could do file new project and actually pick the identity server template very cool okay um so yeah so then the idea is that you have this middleware implementing these protocol endpoints what's going to happen then is your client MVC application right the app that wants to know who the user is it's going to talk protocol to Identity server so yes it's a separate application from Identity server it is going to whenever it needs to know who the user is redirect them to log in just as if you would within your normal app but we're sending them to the centralized login okay so when we send the user to the centralized login then at that point the user hasn't ever provided a password for example so we need to authenticate them so what identity server does then is it says okay I'm implementing the protocol endpoint but I don't know who the user is so I need your code to log them in okay so the actual to put not to find a point on it the the text box that collects their username and their password and their whatever right that's me that's not going to be you yes so when the request does come into identity server it redirects the user one more time to yes your custom login page and this is where you provide all the customizations to satisfy your requirements and that's both the That's The Power of identity server is that you can do whatever makes you happy there absolutely so a lot of times people want to use both an employee login and a customer login okay and so identity server you know if you figure that out on your login page you absolutely can do that and then that will be you know delivered back to your application as whichever user logged in um it could be a Google login okay you can even have identity server on your login page um connect to yet another identity provider so if you are trying to log in like um you know Windows users and those are all stored up in Azure active directory you can have identity server sort of chain to Azure active directory okay so I'm starting to understand the power of this let's say that I've got a website it's going to be a social website my admins are going to be Windows act directory act Azure active directory because they're administrators like I'm doing stack Overflow yep but I want my users to log in with Twitter or Google or World password or a password absolutely excellent that makes so that's that's one of the the very powerful use case scenarios of identity and those are the scenarios that aren't easy without a security token service exactly or without the ability to customize it well yeah that's a good point a a regular security token circus off the um off the shelf may not have any customer ability like that I can use Twitter as a login right but then it's like do I want my admins to log in Via Twitter I really rather they use my any existing it really depends on the off-the-shelf product that you're talking about what it does and doesn't support and how much effort it is to do those customizations if it allows that at all so then the power here is you just write whatever code you want to do the customization absolutely all right so um another uh uh motivation for using identity server then is not only can you use whatever identity store or whatever mechanism for authentication you want but also during that login workflow you can Implement any additional logic around that that login workflow that you want for the user so a really simple example is what if you know you have five different apps okay they're all trusting identity server to log the user in and before the user uses any of those apps you want them to sign a Eula oh yeah okay a very common thing I did that log into a game recently read a whole preps exactly scroll all the way down no one reads but still you've checked the checkbook I held down page now for a long time um so you don't want to write that code in each of the five MVC apps good point right if they're already sending the user to log in at the centralized location you could have that log project centralized as well all right okay so that's another uh very common use case and again could be eulos or could be anything else that your business needs the user to do as they're logging in as well as sophisticated multi-factor auth absolutely absolutely that's the other thing too is again that's sort of the same all the same idea you don't want to re-implement any of these things in each one of your apps so you're putting it in one place yeah you do it the way you want to do it and to your point about microservices the the responsibility of your client isn't to manage that stuff that is what a security token absolutely absolutely let's do something okay so yeah so um so identity server is going to receive the request send the user to your local login page your local login page will do whatever it is to log them in then you're going to send the user back to this authorized endpoint the authorized endpoint is the protocol endpoint where the user is shown a UI is this all happening on the glass is this HTTP level uh bouncing around with 302s or is there any back Channel where we're so for what we're talking about right here no there's no back channel so this is just the user in in the browser they went to the MVC app it first goes to the identity server protocol endpoint redirects you to login okay you log in when you log in another Point by this is that the way that your login code communicates the identity of the user over to Identity servers you issue a cookie okay so then yes we're doing all these redirects in the browser the login page redirects back to this thing called the authorize endpoint identity server can read the cookie we know who the user is and we will generate the token back to the client application nice okay and again all based on standards yeah that's the whole point very cool okay so that's kind of a high level idea about how identity server fits in and how you're going to work with it in your application makes sense now for identity server to again do all these things for you you do have to teach it about your environment you need to teach identity server um about your applications okay about your users and about the identity data that you are protecting of those users because think about this the whole point of centralizing this is that an app wants the user's unique ID in their email okay and some other app may want the unique ID of the user and their name so those are identity information that identity service protecting about the user so you do have to teach identity server about these things okay so here's kind of a little picture that shows the relationship between these so again our users are using what are called clients that's like your MVC app those clients are sending the user to Identity service to authenticate and identity server produces then this this you know protection for your resources um so the identity data and also your apis so if I've got five applications and only one of them needs birthday information there's no reason to let that pii that leak out to the other applications yeah and that's all configurable and under your control all right very cool okay so that's the high level idea here so I'm going to switch over to visual studio uh let's see and what we have here just to give you an overview is we have three um projects so let's zoom in on that we've got yep oh actually let me close that here so yes what we basically as a solution with these three three projects so as we mentioned identity server is going to be hosted in its own separate application okay okay so this is an asp that core application hosting identity server and it already has the nuget referenced but it's basically an empty asp.net core application okay so what we're going to then do is we're going to have this other app this MVC app connect up to Identity server to authenticate the user right okay so that's gonna be the first step that we're really going to do later on then this MVC app will invoke a web API on behalf of that user okay so that's we'll get to that a little bit later but that's our main goal right now is to set up identity server and connect the MVC app to it for authentication okay so for this module success is I load up my MBC application and I click login I am sent over to Identity server and then identity server has to make some decision about whether or not it's gonna issue a token on my behalf yep absolutely all right and then it sends the result back to the MVC app and we should see the user logged into the MDC app awesome okay okay so um I guess we'll start with identity server because we have to you know get started somewhere so as I mentioned identity server the starter code has essentially an empty MVC project because you're going to be showing some UI so you probably want to do that with MVC okay I have my startup code this is where all of the the standard uh you know configuration is done for an asp netcore application so configure Services is our standard di configuration configures the method that configures the asp.net core Pipeline with all the middleware so we have all the kind of out of the box middleware here we have static files and we have MVC and our error handling and all that so like I said I already have identity server referenced as a nuget package so to pop identity server into your hosting application so it can serve up those protocol endpoints I'm going to then use identity server okay and that's as simple as that to pop it into the middleware pipeline was it important that you put it before you use MVC and after you use data yeah absolutely that's a really good point too is it so identity server um and uh MVC well actually it depends on the workflow that you're using but no actually in this case because identity servers are listening on a set of endpoints but redirects the user to your MVC app then um no in this case it was it was okay to put it anywhere I'm just so used to putting my authentication middleware right before MVC that's what the reason I'm pointing it out is that I think from a gotcha's perspective if you have something in NBC app that is a greedy route it might if if identity server was towards the end one of your routes might yeah no that's a that is a good point so yes typically you do want to stick this in front of your MVC for things like that okay that makes sense okay so the middleware by itself is actually not quite enough because as I mentioned we have to teach identity server about your clients and your users cool so the other thing um that this project um has is it does have the starter code code like a template code that I mentioned a few minutes ago that all lives under this controllers folder and it has examples or samples for your typical account controller where the user can log in and things like that so these came in when you made this with the template yes when I made this with the template that these got put in here cool this is template code to get you started but this is the code you're going to own and you're going to tweak and change to satisfy whatever requirements you've got so it's very likely it's not completely likely you're not going to use it as it is right it's getting started just to get you started exactly all right so as part of my sample code again one of the things I had to teach identity server about was my users right so what you use for your user database if you will is entirely up to you so you could use asp.net identity if you're you know kind of Green Field brand new identity database sure you may have a legacy database of users this is also a very common thing is that you know you're stuck with this old database of users and you're not ready to migrate it away and you can't import that I think we've all been there somewhere out there there's an access to database exactly called users right so anyway that's the idea is that you're going to plug that in for my little sample code here what I've done is I have these hard-coded in-memory list of test users so that's the idea is that that's my little uh Legacy fake database to get started but I'm hearing ultimately the list of users is responsible you're responsible for it it can be a database it can be files it can be whatever it's up to you absolutely one thing that I think is worth just kind of getting into a little bit as you said and you can use asp.net asp.net identity maybe you can talk a little bit about the relationship between identity server and asp.net identity because some people might have thought well wait is one replacing the other are they complementary or is one and they're both using the word identity so obviously that that can be confusing so fundamentally what asp.net identity is which is the framework for Microsoft that was built into part of asp.9 core is it is a framework or a library for managing the database that contains your users authentication information predominantly that's a password okay it also does many other functionality in terms of things like email confirmation two-factor authentication you know verify your mobile phone number things like that but I think of asp.net identity as simply a library that talks to your database that holds your users okay which is one more thing I don't have to write absolutely and that's another perfect example writing that kind of library and doing it securely is also really really hard so the asp.net identity library in asp.core does a really good job of all those things okay but it doesn't do oauth2 it doesn't do these security protocols okay so the other thing then is the database of users you're going to build this login page that does that check that code like I said has to communicate to the identity server side of things and there's also a cookie involved there so the the login code is going to be you using the cookie authentication middleware to talk to Identity server so actually that's another another thing that I actually that we're going to be adding here so identity server adds the cookie authentication middleware as well to your hosting application okay if you want to take control over that and add it yourself you can okay not a big deal but anyway that's another thing that's in here okay so yes our login page it's going to issue a cookie our demo code here is using these test users so as I was trying to build up here too is that we need to teach identity server about all these different things all right so the other half of identity server if you will is configured via the DI system identity injection exactly it provides a bunch of services that are available in dependency injection so just like MVC has added they have a little extension method we have an ad identity server extension method that will wire up the core services and then you are going to call some extension methods on this to to configure some of the other things okay um so like I said um from my earlier picture we have to teach it about your users your clients and the resources that it's protecting okay um so there are various um extension extension methods that we're going to call now identity server as I mentioned is very flexible and and it's designed for extensibility so there's going to be a bunch of configuration data that identity server needs and we don't mandate where you store that data okay so the list of your MVC apps and the list of your apis could be in a database or it could be an adjacent file or you could even hard code it in your application so we have an extensibility point that you could Implement to go load that information wherever wherever you have it the extension method I'm about to show you is registering our in-memory store for this configuration data the one of test users yes of the test users and the clients and our apis okay so what we have is we have ADD test users now add test users did you write that yes this is our extension method that is just hooking up to the this in-memory list of users okay and uh how is it doing that like I feel like that's we don't want to gloss too far over there did ad test users come with identity server for the purposes of initial testing so in identity server when it's issuing these tokens at some point your app might say I need the email of the user right so identity server needs to query something to fetch the email right so that's an extensibility point okay so that extensibility point is basically saying hey I need the user's email and your extensibility point would return that right okay so this and and it's an interface that you would you would Implement yes okay so if you stick that interface into the dependency injection system we find your implementation makes sense this extension method I'm using here is registering an implementation of that interface that is triggered off of this in-memory set of users okay okay so there are a couple more for the other other ones here so I'm just trying to understand that in a real scenario ad test users would go aware it'll go away something else yes you would Implement what's called our eye profile service okay okay and that's the low user profile data okay so we have similar ones for adding clients add identity resources and add API resources so I'm going to talk about this would you recommend when people get started that they do add test users as they are building up and then they remove that and swap you know like should they start with all these in-memory examples and these test users and then slowly that's actually a good point so yes what we typically recommend is you start with all this in-memory configuration to reduce all the the very moving Parts exactly um and you'll start to get a feel for how identity server works and how your app can wire up to it which is exactly the demo that we're building here right yes once you get more comfortable with that then you're going to decide oh I want to plug in my real user database and that's where you'll replace this with with your own okay that makes sense because I'm trying to get my head around this because yeah absolutely we're going to get this working but it'll all be fake and in memory and test and then then the next step would be to remove ad test users and swap out something real removing memory clients exactly yes exactly okay and that's another thing is that if you do move away from this in-memory hard-coded configuration and want to use a proper database we have a pre we've already implemented the interface on top of Entity framework nice so you could just pop in our Entity framework implementation and then just you know basically configure your connection string and go from there cool okay so for now my hard-coded in memory config I have in this config.cs file okay so I have some apis to load from my configurations and again that can be anywhere this could be anywhere and you would implement the extensibility point so for loading clients there's an interface called iclient store okay and you would load them from the database rather than this hard-coded list so the configuration data that I'm about to fill in here is our object model for our configuration system Okay so we've defined what a client is we've defined what an identity resource is we've defined an API resource so if you did Implement your own your implementation would load the data from wherever but you would have to return our object model so that we can operate on that of course okay sense okay so that's what I'm going to do in here is I'm going to right now they don't return anything but just to pop these in here I'm going to do config.get clients config dot get identity resources and here it's going to do config.getapi resources so just to fill those in even though they're empty and we're not going to do our API quite yet okay so there's one more thing I need to configure and I do understand there is a bit of a a bit of learning curve here trying to try to get get your head wrapped around we're going to do our best to unpack it okay um so the last thing is I remembered identity server issues tokens okay and we said that those are Json web tokens right and those are secure in the sense that they are digitally signed okay so to do a digital signature you need to have key material okay so identity server needs to know what your key material is going to be okay okay A lot of times what people just use is a self-signed certificate okay because it has a public and private key pair sure so I have installed already on my computer a certificate okay it's again you can use make cert it's just a command line tool and so I'm going to tell identity servers that that's the search certificate to use so in my windows certificate store I have a certificate with the common name called STS okay okay so I'm just telling identity server that's the certificate to use okay so that's all this configuration for now so just to be clear though the make shirt you got from where you got part of the windows SDK yes make sure is provided part of the windows SDK should you install the windows 8K you have that make cert and then you have the common name for that you named it STS so you made that cert and you installed it with the cert manager.msc yes exactly yep you use MMC you pull the snap in I think is what they're called and it's the win yeah just wanted to make sure that everyone understands how to do that there's also um you can there's also a Powershell commands to do the same thing okay so that's another option is this under personal like if you if you run right now cert MGR dot MC MSC .nic you'll sew it up so there's your search these are under my local computer because what's going to happen is eventually when you deploy this to a real environment it's going to be running as a system account so you want this available too we're local to the machine um not specifically to my user so yeah I mean actually here's my certificate right there okay exactly thank you all right so that's the certificate I want to use for all of my tokens [Music] okay so now back over here in my config this is where we're going to fill in all of the other details so I'm going to have an MVC application and so I need to create a client in this configuration system to model it so I'm going to create something called a client s are identified with what's called a client ID it's just a unique identifier string you give it a human readable name or you generate a grid whatever so you're doing this client you're putting this client in the host for identity server yes that means it has to know about all clients you can't have an unknown client correct you want your client you want your token server to know about your clients ahead of time okay if you've ever set up Google login sure you've done the exact same thing right you know when you go in and put in an app and you you create a new app they give you a code yes this is the exact equivalent of that scenario for Google okay so you have to teach the token server about the consuming app and that's exactly what this is so in this case you're gonna you're hard coding it that could come from a database and you could invent that thing where people inside of your company could go and register themselves absolute clients absolutely so you could build a UI for your customers to come to you if they wanted to integrate or exactly within your own ecosystem which makes me I'm going like from Step a to step G here but if I have a web API that and I could go and create all kinds of user interfaces to allow people to use my web API to register themselves as clients in a secure way yep okay cool so that's the MVC application yep so there are a few more things in here we're going to give it a name so this is my MVC demo um we are going to configure What's called the allowed Grant type and again my apologies there are some more complexity that we have to talk about here so open ID connect as I showed in the very initial picture we have lots of different types of apps we have server-side apps Spas native apps right okay so what this these protocols have is what are called flows and the flow is a description of the type of application and how that application is going to be communicating with the token server so the interaction model for that like when I was asking you before are we going to be integrating on the glass are we just going to bounce around at the URL level or might our interaction be different if we were an iPhone app correct okay so that's the idea here is that that you have to teach identity server about the type of app that is going to be connecting and that's what this thing called in the spec they call it a grant type okay the interaction model makes sense the name of calling it Grant type is not intuitive uh yeah and the the caveat I'll say here is that if you are using a paid hosted product you're probably doing that because you want to know nothing about how the security works yeah and if you're building identity server I would highly encourage you to read this back so you know what you're building so that unfortunately you know you have to know how this this protocol works so what does implicit imply so implicit means that right now that my client the way it communicates with the token server will only be through the browser right now okay okay you had mentioned a back Channel call right we'll do that a little bit later and that'll change this configuration but for now we're doing baby steps makes sense okay so the next thing we need to know is what is called the redirect URI that's basically the URL of your MVC app where it gets the results okay and I've done this before too even when I've made localhost apps for Twitter yep they want to know I'm sent you over to Twitter how do you get that's exactly what this is okay um I actually don't know off the top of my head what my MVC app is hosted on so I will go and get that URL real quick so it's looks like my file new project created that URL okay so I'm going to pop this in now we don't want to send the user back to just any place in the app so it turns out that in the MVC app we're going to want a designated like Landing Place sure for the user so and in the MVC app the the component that we're going to use to communicate with this protocol there is an open ID connect middleware that will be put into the MVC app okay it defines this path is that an identity server piece of middleware or an asp.net so that middleware the open ID connect one that the MVC app will be using is from Microsoft cool okay okay and you've just put it at sign in dash oidc is that a known thing or you just make that up that is the hard-coded path in the uh open ID connect middleware it is from Microsoft it is configurable though okay well that's cool yeah um okay one more thing is uh I want to configure What's called the allowed Scopes okay Scopes are the uh are labels for the resources that identity server is protecting okay so an example of something that you might want uh the identity is protecting is the email of the user uh okay so Scopes are basically saying which um these are the resources that your identity service protecting and the client can request certain types of identity information about the user okay so this is basically setting up an allowed list remember you said a second earlier that maybe one app should be allowed to get the user's uh age or birthday right but another app should not and that's kind of what this is doing so identity server is going to know ahead of time that this client the scope of its interest in this user's resources is limited to these things yep so actually before I fill these in that's the other thing to fill in here is you have to teach identity server about the total set of resources it's protecting I say all the things you could ever tell anyone about me exactly so that's what this thing called identity resources are the open ID connects back defines ahead of time a few of these already and there's one called open ID which means it's your user's unique ID right okay so that's the most important thing that an app is going to say URI or a good or something that describes the user yeah it's an opaque string but it's going to be the same value when that user logs in again and again and again okay in the.net terms that turns into What's called the subject claim so the subject identifier that's the unique ID of the user okay all right so we might care about the email so the spec defines email there's also something called profile which actually maps to like several things about the user their their display name their username their first name their last name their URL things like that yeah you can invent your own okay so if you're talking about a scenario where maybe your employees are logging in I might want to know identity information about the employee so we might have a new identity resource here and the name is going to be your office location oh interesting so you've got identity Resource as a type and then in this case here it's just uh name value pairs it's an anonymous type um so I'm sorry say again I'm trying to understand how you're making identity resource is name and user claims properties inside of identity absolutely so these are these are the properties on our configuration what if there are ones oh I see and if there's ones that you that don't fit you put them in user claims so what this is doing is we are saying that hey I have for my users they have office information okay gotcha my app might want to know about that and when it asks for this thing called office we are going to give it claims about the user so that might be the office number and you know the building or the cube number and things like that totally open-ended so for example actually in our test users I don't have this right now but let's go hack this up so I'm going to have my user Alice and Bob they're going to be logging in and here's some identity data about them sure so they have a name and a you know email and so on and so forth so those are all and you're noticing you're using JWT claim types so that that they're limited to that in noon but here you're using a name value yeah so the the claim flame type here these are just strings okay so convenience these strings are whatever you want them to be nice and the open ID connect specification as I mentioned earlier predefines a bunch of this data like email and your name so these are well-known claims yours is your own and then this is custom for you know your scenario okay so we're in Building 25 today so we're in oh no sorry not office number what did I call it oh we did call office number okay good so we're in building number 25 good enough you need to put a comma after that uh this is just a collection of spec on the other one I was just thought I missed it oh you read it yes thank you okay that's pair programming good all right I've added my value today good night everybody all right okay cool so there's some custom identity data Maybe for your scenario for example okay so the point is we have these things that we're protecting this application maybe it's uh your MVC app so what I'm saying is here yes allow this app to get the user's unique ID yes allow this app to get this user's email and yes allow this app to get the user's office information this is a knit question but is it appropriate those be magic strings or should you use some of the uh the existing well yeah structures you have absolutely so usually what we recommend people do is put these into constants okay and so that's what you might use down here for like office yeah for a perfect example and even even the claim types here as well sort of like what we you know yeah you could spend a day looking for misspellings yes exactly no you're absolutely right is it case sensitive yes it will be case sensitive okay good to know okay all right okay so I think that's like about all we need right now for the client um so we have users we have things that they claim we have things that we know that we need to protect yeah and we have our little database of them do we have the uh the oidc part that is going to come we're going to bounce back over to the NBC application yeah we haven't touched the NBC app we haven't touched it at all yes okay all right uh and then our login page do we have a login we do have a login page so that's under this account controller this is again the thing that comes from our our templates okay so we got a login page that was like for free because we used the template when we made the identity server but totally configurable up to us yeah and so if you cruise through here I don't want to spend too much time on this because this is code you probably would would change or remove so the idea is this a standard account controller it's going to have a login action method it's going to have one where you post back the username and password and it and the default code here is checking the in-memory test database for your users sure and you make these look however you want them to look and then the view is yes the views are actually under the views folder and as you can see there's a login and a log out and so on and so forth cool okay okay so yes we got past the hurdle of some of the confusing and complicated configuration settings and that's where again like I mentioned you're gonna have to understand how these things work to some extent um the like the names that you were commenting about these are coming right from the spec so the more you know about the spec the more you'll understand well there's like a 90 page spec I have to read or unfortunately yeah yeah and there are actually several of them okay okay but you really do recommend that our viewers and the people who are interested in the space spend some time don't do this blindly yeah and that's another good point is that on our identity server.io docs website we have quite a bit of documentation about this and we also have quick starts so these quick starts are actually you know hand you know step by step walk-throughs basically what I'm showing you here so if you know you want to take more time and do this on your own we have lots and lots here this is where you know getting you started we have one protecting apis we have one that actually uses asp.net identity in here if I can see so we have templates that are getting everybody kind of jump started cool okay okay great so we have our identity server set up let's run it does it compile yeah that's a good point I've written this code enough that I think it might I might have it down by now there we go okay it does compile nice ship it I will run this and oh I'm actually right so what are you running you've got three projects there which one are you gonna run multiple at the same time yes so what I'm doing is as I select a different one it's going to launch that particular one okay okay so I just launched identity server we happen to be running out of the console app right we've configured Visual Studio to do it that way so here it is what's nice about this is when identity server or when you misconfigure identity server yeah identity server will complain the UI you won't see much okay because you don't want to leak information to an attacker or an end user so identity server um heavily utilizes the logging system in asp.net core nice so when there's an error you go to the the logging output and it'll be right there excellent okay so I'm sure I will screw something up but we'll we'll hopefully look for it here no it's good so that's why I like running the console okay because if you're running an is Express sometimes hidden and then if you use a log file you'll have to go find that okay great it's up and running did I did my browser come up oh I did here we go so we just have a little simple home page saying hello it's more for developers but again you maybe even remove this when you move to production cool okay one of the things to prove or test that identifiers really kind of properly configured is in openid Connect um there is one of these other specs is something called The Discovery specification so the idea is that there's a whole bunch of information about this token server that your app is going to need to know you're going to need to know what URL to send them to to send the user to okay let me guess is there some well-known places where I can poke at it and they can tell me about it so it's funny that you even say it that way because that's exactly what the spec calls this this is the well-known endpoint if you even look in the the browser it's called it's called a well-known point there you go right so the idea is that this is a Json document that your MVC app will query to figure out things like what URLs I want to say okay so it's the description language absolutely it's kind of like the wisdle if you will of your token I'm glad that you said that yeah exactly and there's nothing here that's private this is really just exploring the space exactly so the one endpoint that I mentioned earlier is called the authorize endpoint and that's the one that we're going to see the user go to here in a minute okay so I just want to make one comment from a specifications perspective yes it's not necessarily if I understand correctly that the spec describes the shape of the URLs does it just describe those terms on the left left and the URLs are up to the implementation correct this is a very restful sort of interface if you will so yes they Define the um the the the the property names here and then yes what you put in for the URLs it's up to you okay so that's your implementation details so identity server under the connect path we do authorize and we use connect just because it's open so if I were using some I don't know I've never heard of it but let's say there's some PHP identity server out there it might have a totally different URL structure correct but it's well-known location but describe these this way yeah so what your what you always know is relative to the Base address of the token server wherever that is it could still be hosted under subpaths right but relative to that base path you can go find dot well-known slash openid configuration cool okay the other important thing that's under here is remember I said that there's tokens that are signed your app when it receives them needs to validate them against against what well that's the key material that's the other thing that's in these documents right in these well-known documents so this is actually my RSA key that I had configured in identity server if you recall member and identity server I did so if you had not put that CN the common name equals STS if that had failed when you visited that you're not going to see a problem yeah yep and I if I recall correctly I think we even throw an exception if you haven't configured before you get it before you even get that far cool so at this point you've done the smoke test yes that's exactly the point of showing this to you is just to make sure I got it right that I actually configured this property all right cool so yeah that's the key material this is the public keyment by the way not the private key this is this is unauthenticated endpoint and it's totally fine I suppose we could probably go poking around on Twitter or at other places and see they're well known absolutely Azure has one as well yeah you can go look at theirs exactly okay so that's all well and good so let's close this down and let's switch to my MVC app okay so my MVC app now this is a pretty much out of the box empty MVC project so what we have is the standard startup here okay so again this looks very much like the other one did a little bit of MVC some logging static files in MVC cool we don't have anything security yet have you added any nougats or anything so yes I do have the nugets for the two main things I need one is the nuget for the open ID connect middleware that the MVC app uses right so that's a piece of middleware that will know how to redirect the user to the authorize endpoint in identity server get back the result do all the token validation okay once that handshake is done with the token server you need to keep track of the user within the MVC app so you also need to issue a cookie so those are the two middlewares I have is the cookie authentication middleware and the open ID connect one okay all right so let's add those guys in app use cookie Authentication okay and that's at Microsoft this is absolutely this is Microsoft's cookie authentication middleware you have to Pro you know give this guy a name so cookies seems like a good name and there are other properties on that controlling the cookie how long does the cookie live properties does that name matter what this name matters in that um when I need to identify the fact that I want to use the cookie middleware yeah that may matter so in other words we're going to have two security middlewares the cookie middleware and the open ID connect guide they're both security middlewares so you need to give them a name in essence is what that's doing okay okay so app.use open ID connect authentication okay so what nuget package did that come out of I'm sure I can find the cookie one I think I might have more trouble finding out so they both actually come out of very similar names it's Microsoft asp.net core Dot authentication.cookies and Dot open ID connect nice right let's see and we can see it Independence time 99 sure let's go check this guy out so this is actually going right authentication.openid connected all right that's good to know good okay so this configuration over on the client side is where it kind of needs to match the configuration I did on identity server for this app so we need to do things like actually the first thing is what openid connect provider do we trust that's something called The Authority it's basically the Base address of identity server okay so on the other side we told it about a client called MVC yeah now on this side we're giving it the well-known the now well-known URL exactly and you're setting that one on 5000 and of course you had another one on this side yeah and that's because identity server was listening exactly okay all right now we're doing local development here so we're not going over SSL so there's a an opt-out for a security check here um so I'm saying yeah I know I'm running local development testing and I'm sure that we could do self-signed localhost suffolkly yeah that we're fine without worry about it localhost um obviously when you go to production or even staging or QA everything should be over https cool okay okay so that's a little bit about the token server we're using I need to say okay well who am I I'm the MVC client okay and then what I want to do is indicate at the protocol level what it is I want back from the token server okay so the token server had that list of claims which was which was comprehensive yep and on this side you just want the the couple three or four things you want So yeah so that there are actually two different things we're setting that's one of them that was the it's the thing called the scope and the other thing that I want is remember I said that the uh the the token server could issue multiple types of tokens and right now I just want the authentication token so that's this property that I'm setting right now as I'm saying I only want that I'm not yet calling an API so I don't need the access token okay you're proving that we are who we said we are but we're not going to go and figure out my office and all the other information later this will give me the user's identity information okay I'm just not yet able to call an API on their behalf uh okay that's what that that's what I think that's what I'm not yet doing that's an important distinction um and then the scope are the corresponding Scopes that I had talked about before open ID email and office oh I am missing one more property okay so this is telling the middleware who is I trust to tell me who the user is right okay here's my information right I only want authentication right now no no API access okay and this is the information about the user I want and will they give it to us all at the same time yeah that will all be packaged into the ID token cool as claims okay so the last thing is this will deal with all the handshake protocol work with the token server once we come back then remember I said though we do have to issue a local cookie right so I need to wire up this middleware to that middleware okay and that's with a property called sign in scheme is cookies so when you asked earlier about is the name important so that I Said Fred yes that would need to say this is Fred and that's Fred okay exactly so they line up yep okay I think that's all the plumbing here we need this is gonna be exciting if it works yeah now the one last thing is actually if I run this now right now yeah I just want to show you what the home page looks like sure sure so we have a really empty MVC app the default bootstrap yeah yeah it is with bootstrap the default code um I got rid of all of the other starter HTML just to trim it down so login link right it says hey go get me logged in so what I'm going to do is right now on my login link okay this doesn't do anything so that would blow up okay so what I want to do is I want to use a method called challenge what challenge says is challenge the user which means go get them logged in where is that hanging off of okay this is a method from the controller Base Class in MVC really yes it's creating a challenge result object so that would be a different way to call it sure sure and the challenge result under the covers is actually calling a method on the HTTP context context EXT T thank you T E X context um on this thing called the authentication manager this is what allows you to talk to the security middleware right and there's a method called challenge uh okay the challenge is the convenience method that's on the basic class controller so this is like the lowest API this is a little bit in the middle and then that's the MVC helper right okay so it's just easier to and it knows what how to do challenge because it knows about the middleware that we plugged in I'm gonna I'm actually going to be some explicit with my my pressure so there is something called an authentication properties that I need to pass and the formatting of this never looks good and then there's a second parameter that I need to pass oh you know what I forgot Ah that's the other thing I forgot I forgot to name this guy we named the cookie middleware cookies right I forgot to name the open idea then we can refer to it later so we can refer to it so this is also authentication scheme and I'll call it lydc that's a common thing okay so that's what I was missing in this other call so then when you say challenge it will know which thing to challenge it with exactly so this knows to say go to open ID connect rather than um your local cookie redirect for example okay and I I'm noticing that you didn't just say challenge oidc you have to pass in some properties so yes so the last thing in the properties here is once we come back from the token server it does all the protocol validation on that ID token right it issues our local cookie we need to take the user somewhere ah and I want to take the user to the home page this index page so there's a redirect URI slash uh home slash index for example so if it succeeds it goes there fails where it happens if it fails there's an exception that is thrown um in the open ID connect middleware and that happens in that callback URL the sign in dash oidc and then we could deal with it there and they're actually even events yeah so on the middleware there are events you can handle for area scenarios all right okay so if this succeeds at the end of the module we will be able to look at the user will we be able to see their over their office oh yes so the whole point here is then the index action method if the user is authenticated what we can do is we'll have the user object yeah and then user will be able to see their office exactly and the user has a list of the claims right these are the same claims that the token server had cool okay so these are the key value pairs so we'll say uh VAR x equals yeah and so on my view what I'm doing here my index page is if the user is authenticated okay what I'm doing is I'm looping there's your user.claims and your name so we should see all the claims there and if we do it right office isn't there I hope so I think it's going to work so we go here if it doesn't work then it'll have valuable debugging yes absolutely okay so I'm going to trigger login oh unauthorized client so he said NBC on both sides did we sure we named it the right thing so we yeah we went to uh the token server we got an error and that's why I told you we ran in the console so I can debug this I knew I forgot something so requested scope not allowed profile oh yes silly me okay so what's happening here is let's go back to our config this actually is a good point to bring up it's better that it broke yes so in our config I said hey this MVC app can ask for open ID email but not profile but not profile which is the larger pile it's like yeah a bunch of names kind of something we need yep yeah you could be but maybe I don't I don't want to oh so you can solve this in two ways maybe I don't want so yes I could a grant profile right okay now the tricky thing about this which is a good learning point is if we go back to the client app did I specify profile no did you specify something that implied profile the default Constructor for this actually populates this automatically with open ID and profile but you're overriding it though no the the syntax in C sharp adds to the existing collection so you can do not intuitive you can go talk to the team about this one we had a little bit of an argument with them that's interesting so yes what's happening I would not have guessed that the Constructor for this is adding to the collection and this is that list that is the list so how do you clear it you would have to put this into a into its own variable and declaration that is disappointing okay that is I agree with you but we got vetoed on GitHub with that this would have been C sharp seven years ago yeah so we could put profile in here well that's actually redundant so putting it in the MVC app is redundant because it automatically does it but the point would be and in a way I could have discovered that if I didn't know this I could like you say squirrel away the new open ID connect options look at the Dot scope and the watch window and go huh yeah it was profile in there and that's how I and then I figure the behavior yeah exactly that's how I figured that out interesting okay so good that's a valuable debugging let's go back over here and we'll add profile we'll do the happy path too that's right to get the demo working okay but yeah we've talked about the way you could do it the other way okay rerun identity server cool and again those logs were quite useful yeah they were um they told you exactly yes exactly so now we're going to go back to my MVC app re-run my MVC app yeah 25326 yeah hit login oh look at that now now we just want to point out we went from the MVC app on two three whatever point six and now we're over on identity server which is giving us the login yep so then you beat Alice or Bob right so um I uh so we know how to have the user log in this is the thing that's customizable what you do on this page entirely up to you right okay but we're going to do the simple you know Bob did I do Alice or Bob Alice had an office so I'll pop in Alice here Allison Alice okay okay now the next thing we're going to see is something that is the open ID connect specification is asking for oh and more and more users are getting used to this yes absolutely but you've got a blank checkbox so there are two things yeah my blank chat box again is a typo on my part oh is that's not okay that's not the office it is the office and so what I neglected to do was when I defined office guess what I forgot to do some description give it a display name display your office I like these little errors yeah I've decided you're making those errors on purpose genius yeah I always forget these little things but yes that's how people learn and that's why I appreciate this so all I have to do is go back the URL is still up in the browser is it still valid I'm just going to re-ref refresh in the room look at that okay okay so I didn't restart identity server because it's the in-memory config and then I assume there's something Beyond display name like description that could give you that yeah so the one down here is a okay larger description if I unchecked your office info and said yes it would just be not in the in the list correct so this is what's called the consent screen the consent screen is involving the user right before we go back to the app and making sure with them if it's okay for the token server that the user has a relationship with right the token server knows all this information about the user is it okay for for the token server to release this to this MVC app I I really like these kind of things more and more you know ever since like Facebook stopped trying to post on my behalf right I really like it when an app tells me what they want to know about me and what they're going to do with it exactly so um this is an important part of the spec as well this is well you don't always have to show it so the reason for showing it is typically if the MVC app is third party to the Token server okay so in other words you build an app and you're using Google to log in Google and your app are from like two different companies okay now in the case of identity server we do support it obviously and it's the default oh but you're logging into your yourself from yourself exactly if the app you're building is from your company and the token server is your company's token server and it's your user database you're already within a first party trust boundary okay so you can disable this so it'd be really up to you whether or not you want to give that user your respect or not yep and so in identity server not that I'm going to do this but I'll just show it real quick this is another example of the flexibility identity server has is that we have a require consent false that you can just turn off for that particular client nice okay okay this is client by client right so you could have three of your internal apps where you disable it but maybe a third party integrating with you you leave it enabled nice okay okay all right so now this is work okay yes boom and now here we are we are now logged in so what's happening here is the protocol took that ID token right did all the validation and it's full of uh some information about the protocol and the information about your user right and by default they're taking all of that and dumping it into here it's everything we know about this yeah so there's a whole bunch of things like I said about from the protocol here if we scroll down there's a subject yeah yeah that's the unique idea of the user ID and we have their name and their given name that was from profile office number came from our office scope cool and there's email look at that so we are now authenticated all right okay I feel very happy about it it's a bit of a road to get there but yeah that that's pretty powerful so we just took identity server we put it together we put it in its own asp.net host we put came up with some claims we did some custom claims and now we have successfully logged in a user into our MVC app with identity server providing that secure token service we're going to take a break and we'll come back with even more fun with identity server here on Microsoft Virtual Academy hey friends we are Marching forward with identity server here on a Microsoft Virtual Academy we successfully logged in which was awesome it was good that was good but uh we didn't log out no we didn't log out um let's actually show what we have here so we have login right we go and log our user in Bob and Bob okay comes back yeah and we have Bob that's great but right now our logout button doesn't do anything okay and again much like the one we had before if I go back to my MVC app here um right now logout doesn't do anything well ordinarily when I'm logging out like I just delete all my cookies right and yeah I mean think about that that's exactly what we're going to have to do okay um now I got a question for you how many cookies do you think we have uh two two and why did you say two because that's actually the right answer is it really yeah because you put a thing in startup.cs that was like cookie authentication thingy where uh in startup.cs and configure services in which app which app in the MVC and the MVC app we did absolutely so the MVC app like I said when the user comes in through open ID connect once that handshake is done right then we issue a local cookie at the MVC app right so and you said sign and scheme which is really which is using this line 37s and that's the cookie that asp.net created I don't even I haven't even seen that looks like we should probably look at it so we do if I hit F12 here we can go look at that guy under application can we go to cookies we go here and we have this cookie okay that the standard asp.net that's the one that MVC is named cookies because you called it cookies exactly okay now it because we're running both on localhost this is actually leaking a little information it's kind of going to help you answer the other question which is we do have another cookie okay that cookie comes from what do you think from the identity from Identity service so if they were on different domains then it would have it wouldn't it wouldn't appear in the list it wouldn't appear but it would you would still have the two cookies that's a good point now the really important thing about that cookie ad identity server is that's the magic behind single sign-on oh that's a good point so if I went to MVC application B yeah totally different app and I'm already logged in I would expect that it would bounce over and bounce right back it'd be like I'm already there and so we can actually show that okay okay so let's go actually show that real quick so what I'm going to do is to sign you out of the MVC app there's actually a method very similar to this one called oh I know what you're going to do you'll remove my MVC application so the app will think it's signed out then when I hit sign in I remain signed in to the security token server so it'll bounce me that and I'll exactly just work yep and we've seen that when we log into Twitter we log into Facebook or Google and then an hour or two later another app wants that we do a little dance and you just come right back in exactly so if I rerun this oh I'm starting to realize the challenge my MVC app is can't delete cookies from another domain it's going to have to request that someone delete them on Instagram exactly so we'll do that here in a second so we are signed in okay so right now when I do log out okay given the way that I just wrote this code is I triggered sign out it's very much like challenge but kind of the opposite right um and it is specifically right now just talking to the cookie middleware in the MVC app okay so by putting cookies there it's implying clear out those cookies delete those it's deleting um it's telling that particular security middleware to clean up whatever that means for cookies it means get rid of your cookie okay so yes when I click this log out great oh look what I forgot to do redirect okay yeah I should have done a redirect uh I thought you did oh I do have a redirect URI I think there's a little um bit of a snafu here for what I'm doing a little race condition there uh no I'd have to think about what this is doing under the covers let me show it the long way because I know that that definitely works which is unfortunately a little bit more okay so there's a slightly different version of this which is you could do away to http context dot authentication DOT sign out aren't you not supposed to be poking around inside of HTTP context well the HTTP context exposes this property called authentication it's called the authentication manager and it's what allows your app to coordinate and talk to the security middleware so that's actually by design that is okay okay yes okay that's good to know um so I'm going to sign out of cookies here okay okay and then I'm going to do a redirect back to you know the home page for example which is okay the one up there okay so I'm going to bring the syntax back in a minute off the top of my head I'm actually not sure what what's happening under there so um so let's run this and see if this guy works okay okay so we are login okay yeah so actually did you notice what just happened yeah yeah bounce bounce and then it was logged in yeah I wasn't even prompted that's because you deleted your cookies cookie but not your oidc cookie and you can't from the tokens because the token server uh issued that one exactly and while you let me guess if I guess while you might be able to think you get it to work because you're both on local hosts it won't work in production right it can't work the protocols designed for those things to be running on different domains or you know can run on different types so that's exactly the problem that you were foreseeing is that when I need to sign out everywhere I need to send my user back over to the Token Center well I'm imagining that someone who who hadn't read the spec who hadn't thought about it who hadn't spent time with us here on Virtual Academy would hack something together to delete all their Local Host cookies and then freak out when it didn't work in production and you obviously don't want to do that yeah so that's why there are specifications for this there's actually a sign out specification as part of the the suite of specs cool okay so log out right now is just getting rid of my local cookie and again if we click this we just pop over it was actually pretty quick but everything's local but yeah we quickly went over to a token server and it immediately returned us so log out you usually don't just want to log out of the app no you want to log out of both okay so that's why um I'm going to put the other syntax back because I actually prefer it yeah I'm starting to think this is more complicated than we realized I know when I've tried to log out of larger systems like you know Windows Live ID and it goes and it it says logging you out of and then it gives you a list of all of these different clients that it's logging out absolutely it can take so the the joke in the uh you know identity space is that signing out which is harder than signing in okay all right so what I'm going to do now is I'm going to list that I want to trigger both middlewares to sign out okay so what I'm going to do is sign out of cookies for within the app and I also want to trigger sign out of the open ID connect thing okay which basically is this guy which means we're going to have to send the user over there somewhere to sign out is there a well-known place that it'll just know how to go there that's a good question so if we go back to the Discovery document that we talked about before right check it out there's another well-known endpoint called the end session endpoint okay cool and so that's the end point that is implementing the sign out specification that I mentioned a few seconds ago okay cool okay all right so if I rerun that and I re-run do I have identity server running it is okay so we're gonna go log in now Bob and Bob okay we're signed in okay now when I trigger log out hopefully ah oh look where we are now okay so it's bounced us over there and we are sitting on logout so we're now actually back over on 5000 which was identity and they're giving us a second chance okay so the reason there's no no there so they are giving us the second chance um and the reason for that is if you think about this discovery document that I talked about in this and session endpoint it's a well-known endpoint okay so what that means is Imagine um your competitor puts a hidden iframe to this end session endpoint of your company's token server that would be super mean okay so what would happen is your your users are using your website and they happen to go look at your competitor's website and they are denial of servicing your users if this automatically logged the user out oh wow so which means that anyone could log us out of Twitter yeah you can really just wreak havoc so that's why on the sign out page we need to make sure that the user is really intending to do this okay okay so we can hit yes and now we're logged out are we really we don't have our cookies anymore so if I go to the cookies they're gone all right and this is just this is an anti-portrait cookie from the NBC which is yeah you kind of get that for free that's cool yep all right now there are a couple things about this is a lot of times people complain I don't like the prompt okay yeah I can see that and my user now is dead on the token server and they have like no easy way to get back to the app I want the token server to redirect them right but then do I make them click again right so here's the trick is that to remove the prompt what we need to do is because we don't want this denial of service style of attack right so we need to in essence authenticate the request to sign out okay so that sounds so bizarre right but the idea is that I want that no it doesn't you're right I want to make sure that I uh it's a claim I want to know that you have the rights to be logging someone else in a sense are you really you I want to make sure that the request to sign out came from the legitimate MVC app that we had previously logged the user into and not just some random guess not just some random competitors website right and and from a restful perspective you don't typically want to take major actions on it yet that as well yes absolutely so what we need and what the protocol allows us to do this with is we need the MVC app to pass something to that sign out request that proves that we had previously were the app that received the login right something verifiable something verifiable do we have anything in this protocol that's verifiable that we talked about but we have all the claims of the Scopes that we pulled from before but if you just put the passwords as query string parameters would those be verifiable I remember seeing a nonce go by but I don't know yeah but that was a random number okay and that it's a then I'm at a loss no well what did our MVC app receive in the first place to prove that the identity of the user was Bob the initial token yeah the identity token okay so we just return it back so what we're going to do is at sign out time pass it back because we've been hanging hanging on to us this whole time actually we haven't been hanging on to it oh we didn't we received it but we never put it anywhere yeah what we did is we took the I or what the middleware did is it took the ID token and converted the read all the claims and put those into the cookie but it threw away the ID token so what we want to do is save the ID token are we saving it in a cookie okay so um yeah it has to put it somewhere and the only Real Estate Management location that we have so far here is in the cookie are we in danger to having two three four K of cookies you were absolutely in danger of that okay so that would have that would have been bad in the 90s is that bad today no it's still bad today okay mobile browsers are notoriously aggressive about not allowing cookies usually more than 4K oh wow okay okay so yeah they're pretty um it's a serious problem you know for your app so in so what's going to happen is this original ID token will be now stored in the cookie okay it's actually not sort of claims there's like this dictionary that also lives in the cookie and my my view that I showed you earlier where I was showing you the claims I'm actually programmatically uh reaching in and saying oh hey do you have that ID token so there's actually an API that you can query to say give me back the ID token so I'm showing it here in the UI if we have one um but yes the cookie size is a concern so the authentication the cookie authentication middleware has a um an extensibility point where you can take over ownership of the storage so in other words what goes into the cookie is just like a grid right and then you know something um something small sure and then you implement some server-side storage where you put all that other things God forbid sessions whatever so that's uh and we're not going to do that here so I don't think we're going to hit the limit of our cookie size but this will be good enough to when you say it's a concern this is one of those things that I just I deal with it if I'm dealing with maybe perhaps older Android phones and I'm starting to notice that this is a problem in my testing then I would Implement an interface to to deal with this exactly so it's something you run into then you'll you know or if you know about it ahead of time you might proactively you know kind of uh address the problem are we going to have an issue on our desktop browsers um depends you could actually end up if you well with localhost it's very easy to have lots of test apps and I believe around 16k I don't remember exactly but there's a certain limit where the web server will stop accepting because you have too much too many headers that are being sent okay so but yeah so you might run into it you have to take action at that okay okay so let's try this one more time and when we log in okay great so we now have the ID token so that's the original identity token that we had gotten back from the token server okay so what I'm going to do now is at sign out time the other complaint that I had mentioned is that we want to remove the prompt right and now by by including this token when I trigger sign out it will automatically pass the ID token for me so you set save token which means that you're automatically going to serialize that and save it into a cookie where are you pulling that back out when I trigger openid connect sign out oh the middleware already knows how to do this it does it for you that's correct so the other thing I want to do then is once the user has bypassed The Prompt I want to give the user a way to get back to my app okay so there's also a way to do that and that is done um by configuring another you configuration option in identity server so what we have is the open ID connect middleware or the open ID connect protocol allows that when you trigger a sign out to the Token server you can pass along this thing called the post logout redirect URI which is the URL where the user is allowed to come back to afterwards so again this is another thing that the middleware is already implementing for me so signing callback that's the hard-coded path all right okay so you have to teach identity server about a little bit more about your clients capabilities with that configuration option I suppose one could see a see a world where it knew that it was asp.net on the other side and it knew that those were well-known locations yeah possibly I mean you could always provide an abstraction on top of this to pre-configure these for you because you know you're if you find yourself in this more closed system of all just NBC now your hard-coding localhost you know colon whatever that can come out of configuration absolutely absolutely cool okay so let's go back to my MVC app let's try it one more time so we'll log in so our user gets logged in Bob and Bob okay and then when we log out oh no we got an error I didn't behave the way I expected so let's see so we're going to go check the layers I saw invalid request yeah invalid request the I'm going to scroll up here and see if I can get anything more about this looking for red yeah we are looking for red and I don't think that's in here so the invalid request we go to the consent screen identity servers logging out sign in session so here's the request that came in the post logout redirect URI localhost sign out ah you know what it what's that I have a typo so uh identities over here is we're getting all the logs about the request into identity server and identity server this is coming from the browser when we went session and so notice the post logout redirect URI the middleware is actually passing sign out callback oidc and you know what I fat fingered when I copied that sign in yeah so this needs to be signed out which gets to the point that I now apparently presciently was teasing you about was keeping track of those is challenging absolutely good to know obviously here with identity server because you might be using a PHP client or a Java Club it needs to be all configurable and that's another really important reminder here is that even though we're working on the identity server and identity server as an asp.net core application inside of a host its clients could be from anywhere because we're talking protocols because you're non-denominational and your technology choice okay run this one more time okay we'll start over and hopefully if we finally got this all lined up we'll log in Bob and Bob good now when we log out hey there we go okay so it bypassed The Prompt and now we give the user the ability to say oh yeah sure don't want to avoid that that last click because you do want to let them know that they are logged out and leave them typically good practice right you're going to let the user know yep everything's good you're logged out um and so I mean if you really wanted to you could write some code around that to maybe dynamically detect that the page is fully loaded and then once it's done you can go back but yeah um so there's some you know some options there cool so we've got login working we've got log out working yep it'll log them out of all if I log into the log amount out of all clients right so it actually is not right now that's actually one more step okay so imagine um if we do this let's say we go back to our our app over here log in Bob and Bob okay so let's say the browser on the right you're in app one sure okay so the browser on the left let's say we're in app2 and in app two we trigger sign out right okay so we're gonna do the end session request and I'm pretending I have a client over here so I get prompted okay yes we're logged out over on the right though that would mean my Cookie's gone right well if that's your which cookie is gone right the cookie in the MVC you know MVC card cookies that one is still around the one that says that you have a session a live session because right now when you come to sign out through a different path other than the MVC app how is identity server pinging the other app that makes sense and and since this one already has the token that allows it to continue it's issued by MVC app while it may not have the oidc one it doesn't need it because it's not looking at it only exactly you you once you did the initial handshake with the token server you're kind of like done with it because you're just now dealing with your own cookie that you control so would would you have to implement custom code identity everywhere would enumerate all clients and request logouts from each of them so guess what there's a specification for this so they they thought of everything they've absolutely thought of that okay now the interesting thing about the spec is that the way that the STS can come in indicate back to all the different clients that the user is logged into it needs some way to do that in the context of the user's you know browser session some brilliant use of web services I haven't thought of yeah well not quite so the spec is written a few years ago and they've taken their prompt from actually some of the older security specs okay so they use one of the hackiest technologies that the web has had for a while uh-oh and iframe and iframe exactly like multiple iframes then they like Bounce from iframe to iframes they don't bounce from iframe if they do multiples in parallel oh wow okay so I can I can show that to you modern asynchronous well so the thing is though when the specs were written they didn't want to take a dependency on things like Ajax calls because it would involve cores and cores was still not quite well enough support at the time and it sounds like even though we don't like iframes they're not going anywhere no and then they they actually do work reasonably well okay okay so the iframe is where you go and and inject in the log out requests to all of the different right parties as a an app um sends the user to sign in in the token server the token server keeps track of its app one and app2 and app3 okay when the user then comes to the Token server to sign out it has remembered this and for each one of those apps it will render on the signed the logged out page it will render an iframe for each one okay okay you have to then teach the token server about this iframe sign out URL okay fortunately in the MVC app the Microsoft middleware already handles it for you you just have to write the configuration I have to say that I I am impressed somewhat that that the the Microsoft middleware Is providing it what you needed like you would I would have expected that there would need to be dependencies on identity server or custom stuff that you need to write but because you are doing you've built a framework that can live in the security in this in the secure token service and that the Microsoft people have you know embraced oidc in the various specifications they need to do and have made a decent implementation of that that you're really just pointing uh identity server to these things and it's doing its job yeah no you didn't have to work around anything it is working well and again that's again the benefit for the specs right you're leveraging those okay um so there's another property here called logout URI this is the intended to be the iframe uh endpoint and the Microsoft middleware implements that path okay okay so we'll rerun identity server good we'll rerun my MVC app good and so over here in my MVC app we will trigger a sign in okay Bob and Bob good over here in identity server we see that they're signed in here we have Bob okay so now what I'm going to do is I'm going to go to the end session endpoint like we've mentioned okay we'll log out of identity server and now over in the right side hopefully if it all worked I hit refresh and look at that no more cookie so there was a hidden iframes in there we can even take a look at it here if I run the uh so you didn't didn't have a dependency on JavaScript nope this is the whole point the whole point yeah so when we look at the you are logged out page if we drill down enough here there you go it actually is an iframe that contains up the list of iframes oh wow but if we actually drill down here it is so here then is that sign out IDC oidc pointing to the MVC and then it passed in that token from before it actually so again this is also a well-known endpoint right so you don't want attackers automating that right so the way the spec authenticates to that endpoint is they pass what's called a session ID so the session ID is a unique ID that the user is assigned at login time and the MVC app holds on to that that was in the that was in the original ID token and without that then hitting that is a no-off exactly you should reject it nice okay yeah yeah they have thought of everything yes yep okay let's sign up all right cool okay so the one last thing I wanted to show was enhancing the login process and we'll do it very quickly here but the idea is that the login page is where you get to customize this with however you want the user to log in right now we're doing a simple username and password which is we call those local accounts right those are local to your uh your identity server your token server but you might want to support business partners who want to do authentication your employees with Azure active directory or social logins with Google right so you can stick all of that within identity server absolutely being able to log in with a local login or optionally a Google and combine them anything super useful absolutely so the way that works is because identity server is just an asp.net application your asp.net application can simply be a open ID connect client to those Upstream identity providers okay so in other words the same mechanism that we have the MVC app talk to Identity server right identity server can talk to something else and it's become a chain of trust it is a chain of trust yes so just real quick to show this here what I'll do is in my identity server host I fortunately have some pre-configured code here so what I have is two examples of Google middleware and open ID connect so what I'm going to add to my pipeline here is um let's see here I'll pop these guys in that is a scary block of code this is uh should I fear that block of code well this is the open ID connect middleware that we had talked about before okay so this is the built-in Microsoft use Google so yes I'm adding two middlewares because I want my users to be able to use Google right or um some business partners identity system anyway that's generic opening and so what I have here is um for the for Google we all understand how that works right before we went off into it just to be clear you went off into Google you logged in you set up an app you brought in your client ID and your secret exactly okay um and for the open ID connect what we have is we actually have another copy of identity server hosted up in Azure for demonstration purposes I see it's a hosted identity server where that is playing the role of your business some third-party open ID connect business partner exactly so that's exactly so it's remember the authority property we said it in our mpca right the authority here now is our demo identity okay so we have our MVC application talking to a a separate web application which is our local instance of identity your company's micro security tokens the one that we built and we own rsts yes has to be powered by identity server and it can then chain its login and its web of trust to other partners that use openid connect we'll be using a hosted version of identity service right a second identity server or Google or Twitter or Facebook or whatever exactly very cool so if I have my my canned configuration correct here then what's going to happen is when my user the flexibility is starting to really shine at this point so I run my MVC app I go log in and now on my login page my well your your company's custom login code now is detecting that these are also options to pop in here and then you give the user a choice you know a chance to pick one of them how would you decide for example if a certain Google login is Bob or that a certain Google login has abilities like like you know Brock logged in and now he's an admin right so that's a very important architectural decision you have to make usually what you have is at your identity server you have your database of all your users okay include it you have a record for all your users including the ones coming from Google and including the ones coming from maybe your business partner so what's going to happen then is when you choose one of these external providers they will send you back an ID token if they Implement open ID connect right it'll have that external system's unique idea for the user right you have to then map that external system unique ID to your user's unique ID okay and that's all to up to your login code so that's code you do have to write okay and you have to understand that there's some mechanics in doing that sure okay mainly let's say Google gives you a unique ID for the user sure usually your email yeah well no it's actually a random long random threat okay I must be thinking of this wrong so Google gives you a unique random unique ID okay but it's the same ID every time for that user okay you don't want to take Google's ID and then issue it to your apps right okay you want to issue whatever you would have ordinarily issue exactly yes let's say the user also how to use internet password you want to make sure that's the ID that you issue right okay so what we're doing by putting all this logic of finding the Google mapping the Google user to your user we're putting this in our token server you're abstracting all of your apps from that okay your apps don't have to deal with any of this stuff they're just going to get a consistent unique ID for your user could you get into complicated kind of workflows where someone could say I see that you just tried to log in with Google you used your email the same email as a local user would you like to link these absolutely and if that you have to write those yes if and if those are your requirements then you can Implement that logic because I think we've all had that experience where we've you know picked a social game or worked with a website where we logged in with our email before one day we arrived and they have just implemented social login and we said oh cool right I'd much rather log in with Google we log in with Google and it says Hey I've detected yes and we're always impressed by that that's from a user experience perspective that's a really impressive experience right yeah that's now possible yeah absolutely but again you still have to write it and that's all I understand if your requirements like want that to be a scenario sure then Implement them and you can do that very cool okay so one of these should work up at Google I think I'm already logged into Google so that's just immediately that is your consent and so now so I already went to Google and immediately came back okay because you're already like I'm already logged into Google and because I've done this demo a couple times the consent I gave at Google to issue the identity to this identity server was already in their data within two consents Google what you Google would have said this application is interested in you yes and now the application is requesting it from Identity service exactly yep but that's again if it's third but again if you had removed the consent as we saw earlier in the in the uh in the academy that we could do that you would have only seen the consent from Google and then you would have come all the way through and been logged in yes exactly and there's your name and Google remembers that in the future so that if you ever log in again it doesn't bother so then you could go over into your Google list of apps revoke this apps absolutely very cool so identity server could also do the same thing part of identity server if you do have consent you know you can do the remember consent here and the same kind of database could exist at identity server to remember future logins don't have to get re reprompted for consent okay all right that's cool so we've got login we've got log out we've got really true log out of everywhere yep we've got a chain of trust where we can go and have our identity server log into another identity server like a partner or log into social we used Google in this example I will take a short break and we'll come back and then our MVC application will call a web API on that user's behalf thanks for hanging out with us here on Microsoft Virtual Academy all right friends we are back and we're in the final module of the identity server Microsoft Virtual Academy and Brock has brought us through this this Epic Journey where we've done login and logout and now we have the ability to have this application talk to Identity server gets its token now we're going to go and call out to external web apis on that user's behalf exactly all right that's the next step let's do it so as I mentioned earlier when you first have your client app communicate with identity server just for authentication you're getting one type of token called an identity token okay and the intended recipient is the MVC app okay so the MVC app trusts the identity token okay then we now want to call the API on behalf of the user as you said there's a new type of token for that called an access token cool and the access token is where is what's used at the web API so the web API is the recipient of the access token do I tell the web API my identity token and my access token or do I just need the access no that's the exact reason I was pointing that out is because because those are distinct tokens for distinct audiences okay so let me ask this dumb analogy I go into the DMV I show the person at the front desk my identity that then allows me to pull the little uh token with my number that they're going to call later okay so I've identified myself yep which that has then allowed me to pull the number which at that point I moved past that front desk lady right and now I'm inside the DMV I'm authenticated and I sit around and I wait for that token right I don't have to show my ID again I just hand them my number when I get there in a sense that's exactly what we're talking about here because you've gone and issued your you've you've provided your username and password at the token server and it's giving you then something else which is enough of a proof of your identity and that can be used at the you know API in this case how long can it use is it per web app it can be saved all configurable okay but the access token usually has some sort of Lifetime okay and the intent is that you have to periodically go back to the Token so server to get new access tokens to make sure you're still allowed and and that the app is still legitimately allowed to act on your behalf okay so there are some lifetime management issues um that you do have to consider how granular and how thoughtful do I need to be about this is it a token to let me access this web web API or is it a token to let me save data versus a token to let me read data so the granularity of the token is really up to your design okay so Google for example they have lots of different apis they have like a calendar API right and so when you write an app that uses the calendar API on behalf of a user when you go uh when the the the app goes and and asks for tokens it could ask for the access to the read-only calendar functionality or the read write functionality of the calendar so in other words those two things are called Scopes that's actually a term we heard earlier because Scopes represent the resources that identity service protecting so the new type of scope that we're talking about here is an API scope okay so that's an overloaded term in the protocols it is definitely a little bit confusing but sure um but anyway so that's the point so you get to design your own Scopes okay so that's good so if I'm building an API for my shopping cart I can have uh you know adding something to the shopping cart might be one level actually checking out and taking money can be another totally business logic type level sure and you could create different scopes for different apis or multiple scopes with a single API with different access like the read accessory exactly all right that's good to know um so anyway what we'll do here is we'll go introduce a single API because that's what I have here for my demo code we have another project with this web API right now if we look into this this is again a separate hosted web API okay it is using asp.net core but again as you had mentioned before this API or even this MVC app could be written in Java or something else still protected by identity server so it just happens that this sample is using asp.net core cool so in our startup code this again is going to look very similar this is actually kind of a trimmed down sample because we don't have any UI right okay we don't need views in our API it just has straight up MVC so which we have that in here then I have a simple test controller I'm using you know attribute routing to say yeah that's the test API and I'm basically just saying hello world cool okay pretty sophisticated yeah very sophisticated so whenever I run this right now and I go to that endpoint called test right great we were able to hit this through the browser that's not really those unauthenticated one no claim correct right now I have no security all right okay my MVC app then if I run it let's go get the user logged in just because that will enable the button okay that shows you calling the API so we have a little thing here to call the API all right we invoke it and it's also calling the same the same thing okay that's the result of that API just dropped into a div exactly all right no security at this point though okay so I just showed showing you that it works okay now obviously how do we secure these guys you can drop in an authorized attribute right that basically says you have to be authenticated to hit the API but that authorization at this point is still kind of up in the air right we haven't yet yeah we haven't like actually quite implemented that yet but what I want to show you is that when I hit refresh here now we get our own author okay right so I tried to call the API but I don't have the right credentials okay and I would have to say that I think that people will agree with me that who are not necessarily familiar with the identity space that authenticating web pages most people seem to understand it and they get that it's a thing they don't think they don't understand that how to authenticate a web API it's not quite the same like we're all used to browsers in the past that have popped the dialogue and said log into Windows or like basic authentication digest we get that people aren't super clear on how to truly authenticate correctly against the web right and some of the things we've done in the past are subject to certain types of attacks these days so having done like basic authentication against a web API if you're doing it from like the browser in your Ajax code you might be susceptible to a cross-site request uh uh forgery attacks um so um so yeah so this access token approach that I'm showing you is the recommended way to protect web API okay this is the and then in 2017 2018 this is the correct way to deal with it guys so um so great we have my web API it's running we are denying access to the anonymous caller okay so this is again why the the two different tokens have two different audiences the users authenticated to the MVC app but we don't yet have the token to authenticate to the API the access token the access token exactly okay all right so let's go get an access token so to get an access token my mvcf has to request it right from the token server the way we requested is we're going to change some of our open ID connect configuration is this a resource this is another resource because it's different than a separate app that we would log into like you had us log into MVC app a and NBC app B this is not a a thing to log into right think of the idea those are called clients basically your uis right those are the clients and the apis are different okay so the open ID connect Plumbing here what we're going to do is um the first thing I'll do is I'll add a new scope so I haven't set this up an identity server yet so I'm starting with the MVC sample sure so what I want to do is I want to ask for access to Now API one for example named API exactly so this would be some named API this could be your accounting or human resources API or whatever however you want to make sense okay so and again this is where I was saying that the protocol overloads scope for access to two types of things the identity information and the API access okay again a bit confusing but that's that's the way good to be aware of okay um so then the last thing I'm going to change here is remember this response type was what I wanted back from the token server right and previously it was just ID token saying I only wanted the authentication so what I'm going to do is I'm going to change this slightly and I'm going to say something I want a code and an ID token now this gets into some of the bowels of the um the oauth protocol with how we obtain access tokens from my server side application which might be different than a spa application might be different than a native application so what this is using is What's called the hybrid flow previously we were just doing what was called the implicit flow right now we're using hybrid flow okay implicit meant we only came in through the authorize endpoint actually is identity server running here so remember I mentioned the Discovery document I mentioned the authorize or the authorization of the point right that's the end point where the user is delivered in the browser so there's going to be a UI there now that my MVC app also wants an access token the way the protocol works is that you're also going to have the MVC app programmatically talk to the Token server right and that's through What's called the token endpoint so it'll request a token endpoint not by on the glass integration in the browser but by making a back Channel and the reason we we do this so what ends up happening is the token server delivers through the browser the ID token that we had before and this new thing called a code okay the code is not the access token code is not the access to okay the code is delivered back to the server side MVC app okay and the MVC app uses the back Channel and exchanges the code for the access token why the in Direction so the the what they're trying to protect here or or do is minimize the exposure of the access token if the token server delivered the access token via the front Channel and it delivered the token directly back to the client that means there are a lot of intermediaries who may have seen the token so the protocol is designed to try to minimize that that makes sense okay so at the expense of an extra round trip so hybrid means you're using a little bit of one and a little bit of the other okay so that also yeah and it's also interesting that scope is taking a list of stuff but response type is taking a space separated value yeah that's just a design uh Choice by the asp.net team when they were designing this middleware okay okay um so what I'm going to do here is now that we're using the token endpoint also the programmatic endpoint you need to authenticate there the MVC app needs to authenticate to the Token endpoint so what's going to happen is the MVC app is now going to be issued some sort of client Secret okay so this is a new thing that the NBC app has to be collecting exactly and it's standard login for Preparation to call this web API later so yes so what's happening is this allows the MVC app when it when it tries to exchange that code for the access token it will be authenticating as the MVC app to Identity server but it's not as the user it's as the app it says the app itself exactly okay that makes sense so there's a bunch of security you know prevention uh going on here in terms of you know what we're allowing to this but yes it's more configuration but is it that we are logging in Twi we are we are going to this the token server once on the screen once in the browser yes and once in the back end twice and proving ourselves twice yes all in an attempt to minimize the exposure of the access token okay all right so what this means this is the MVC code so what I need to do in my identity server is change the flow the the grant type that we talked about so that the so that identity server knows it's going to be coming on these two two different endpoints will it functionally change the uh the standard login experience it'll still will still go to those same front ends from the end user's perspective the interaction through the authorize endpoint the front channel will stay the same stay the same Okay Okay cool so I need to issue this app a secret and again secret is an awful secret so you should generate a nice 128-bit random number now we've seen that this is starting to look this I feel like our app is starting to look like Twitter or Facebook yeah which give us client IDs and client Secrets exactly just like earlier we had configured Google and when you go add your app to Google they give you a client ID and secret for this very reason yeah this is exactly what Google does all right okay I'm starting to feel like we're really an identity server now yes we certainly are Okay so we've issued a secret I've changed the flow I also now I'm requesting a new type of resource right so I need to you've done all this in the MVC app yes and I now need to go configure all these comparable things in identity servers Okay cool so over in identity server what we'll do is we'll go to the client first we will change this flow to be this thing called hybrid okay okay once you start to learn the common patterns then these start to become a little bit more section you know second nature well I can tell you I'm significantly less freaked out now than I was okay good job I feel empowered you need yeah you need to you know read the specs or have it explained to you or read a book on how these work to know like what are your options yeah and just which one to pick so I need to now have a secret so we have a client Secrets um what this will do is we can now create a new Secret and this is where I create the secret again should be a nice 128-bit random number we actually do a hashing of this because of the ones yeah of the bad secret but sure the idea is that the assumption is that this is coming from a database okay so what we do is we assume that maybe the database gets compromised oh so I don't want the plain text secret in the database so we hash it okay just like you might for a user's password but anyway so that's why that so they are still passing the secret over but we are not validating against that we're evaluating against the hash exactly we do the whole standard hashing comparison to make sure it's the right secret okay and we only do a single hash because it it should be a nice high entropy password when you store users passwords you actually do this looping of hashing to protect against a Brute Force attack of an attacker who stole your database because we know we're going to use a nice high entropy secret we don't need to do a whole bunch of hashing just a single hash is good enough that shot 256 is that an extension method that you added to string yes it is it's an extension yeah an extension method the identity server defines that's cool okay okay so the client secret I changed the flow of the grant type and now I need to tell API I need to add API one so I haven't yet defined API one but I'll go ahead and because I'm here add API one to the list of allowed Scopes okay so now the last thing I need to fill in is this thing I didn't do before which is the other type of resource that identity service protecting okay so I'm going to create a new API resource and we have a convenience Constructor to just fill in the two things that you need which is the scope name of the API that you're trying to get access to cool and then a display name so this is my you know demo API one or whatever cool okay the convenience Constructor is kind of nice because remember earlier I forgot the display that that's what this is making sure I I have okay does it need to know the location of the API or is it just need to know its unique name no so that's a good question the um the scope the string right here is the identifier The Logical identifier for the API Okay Okay so we've been using things like secret we don't use that we use a long number we're using names like API one we could use like a Java style namespace like com dot barackallen.com you know whatever yeah frequently this might be your company you know so Acme Corporation or whatever um and this is like your HR API and if you even wanted to do the the read-only um you know over you know you put dots in here like read only versus read write you could you know it's just a string just come up with some scheme that makes sense so that when there's hundreds of them yes it makes sense everybody cool Okay Okay cool so we have uh we're modeling our API oh and actually yes when there are hundreds of them identity server can handle that sure right now you're hard coding these API resources I can put these in a database identity over can maintain access to hundreds of clients thousands of clients of apis and clients absolutely this becomes a bit of a design discussion remember I said there's still other things you have to sit down and think about like session management also scope design is actually one of the more tricky areas when you're designing this it's like like should I design a scope for all my apis or should I design a scope for every one of my apis and you can get too granular with this so Scopes usually are best as a coarse grained mechanism for modeling an API because fundamentally what this is used for is to prompt the user for consent okay so if you have a a consent screen with 30 different apis the user is not going to know what to say it's interesting that you say that because when you play around on the Google developer console they have such a large amount of stuff and it's all different groups yes even though they've come together in this way with their own any server and tokens it looks overwhelming and honestly I don't know you have to go and individually Grant yourself access to right all these little apis yeah I really just want a class of API well uh yeah and that's definitely the tricky trade-off that you're you know the tricky design that you have to to to solve okay okay all right I think I can run this now there's identity server uh go back to my MVC app run this guy I don't know if I forgot anything it's a really fast laptop thanks I guess I'm logged in so let's go log out and go back okay trigger this again login as Bob hey look at my consent screen look at that okay so now in addition to all my identity data that's being requested by the client by the MVC app it's saying hey this MVC app also wants to access your demo API on your behalf so yes good all right and actually do you remember that flag I had earlier called save tokens that held onto the ID token right it also holds on to the access token of course so this access token actually what I can do is I can take this and um there I can take a peek inside of it so there's a Nifty little utility called on the website called jot.io which allows you to peek inside of this okay JWT JWT and what this is doing is decoding the jot okay jots are signed but not encrypted okay so this is just decoding it it's just using a specific kind of this isn't just it doesn't look base64 it looks like something else it's Basics before URL encoded and then there are sections to it separated by dots and the first two sections are Json objects and the third section at the end is the signature on the rest of it okay okay so this then shows you what's inside of the Json web token so this is the access token and this has things like hey what client obtained the access token what user that's the subject identifier right right that's the unique ID of the user this is the subject identifier um that is a unique ID for the user so when you call the API you'll know which app was using you and which user it was on behalf of very cool okay and the elastic in here is the scope this basically says hey this is good in API one you could build two Scopes and have the MVC app get one access token that could be used at both scopes okay right so that's a possibility as well all right cool anyway now I'm starting to think about when you hit call Api I don't remember us plugging anything in yeah we haven't done anything yet so if we call this it'll still be it's still not using the access token we haven't done anything to pass it along correct so that's a good point where do you think you would pass this access token when you're invoking the web API let's go look at the code for the web API okay how we're invoking it sure so down here I have this little call Api helper okay I'm hard coding the URL I use a good old HTTP client and I'm just calling get on the the API Ural well everything that we've been doing has been a lot of well-known this and well known that there's there's a spec and there's agreed upon strings I'm assuming that there's some x dash something header that we would include so yes there is a spec for this and it's called the HTTP spec okay so the HTTP spec defines the authorization header really so you're just going to use the regular off we're going to use the good old authorization header because that's exactly what it's for that's cool I somehow I thought they'd make a new one because you're right no the the new restful world is using verbs that have been around for years why not yeah and you use all the stuff that's already predefined and proxy servers already know to not log that kind of stuff so you don't want to leak these access tokens which is interesting even though I've been doing HTTP for a long time a lot of the uh my understanding of the headers like authorization it's been fairly opaque it's a magic string and I honestly don't know what they're doing to assert that it is correct okay so when I do a basic auth and I get back on authentic authorization and authentication header just I don't okay look imagine string you're going to generate one well we can authenticate against it we already generated one here that's what we passed that's that's what goes into the authorization as it is as it is and because it's clean and because it's a Json web token when it's sent to the API because it has a signature we can trust we can trust it we know who it's on behalf so it's tamper proof we know all sorts of information about it inside where it came from who it was and whether they have access absolutely so it's very clean let's go update our MVC app to then read the access token so remember I actually showed you earlier the little bit of the code where you can reach into that dictionary that is in the cookie the claims yeah and this is the uh get token yeah that's the skit token async so I'm going to copy this real quick and I'm going to pop this here into my code so there's my access token I need a semicolon and then on the HTTP client there's something called the default request headers okay this is allows you to configure the headers of the HTTP request there's a property called authorization and I'm going to instantiate a what's called an authentication header value somebody didn't quite get the names lined up but anyway that's weird why isn't it just a string right there's well actually the reasons it's an object is because the value is actually um the header is there two values in the header so there are two values the first value is What's called the scheme and then there's white space and then there's actual credential I see so you are overloading one header but you could pass multiple credential types okay so the credential type that we use for our axis tokens is called Bearer and then we put the access token in as a value so this will actually be sent as the authorization header this hard-coded string Bearer one white space and then whatever that access token is if bear is such a standard thing and that's a common thing it seems like there should be a oh an overload or a convenience thing to make authentication header value and the fact that authentication header value doesn't line up with the word authorization you have well this is a you could make a header value helper right that would have Bearer happen for you so we have one [Music] and we can do it that way great minds so yeah did I did I just make that up and you already had it ready to go yeah so this this I totally didn't know that we have another open source Library so identity server is one of our open source libraries we have another open source Library called identity model and that is filling in the gaps that are kind of missing across all the helper stuff all the helper stuff that the.net framework doesn't have so that means at line 4748 is kind of like the standard low level way of doing it and the 46 is the I'm doing this all day long I got tired of it yes here's a helper exactly and what's going on with context that I'm not sure this dot context oh HD oh because in the view it's called context but in the controller it's called the HTTP context so it's hanging off of the page my copy and paste wasn't quite successful all right all right good great minds think alike because eventually you find yourself doing that multiple times absolutely the thing about the bearer token the reason they use the words the scheme Bearer is because whoever Bears the token can use it so I think of a bearer token as like your hotel uh you know the plastic room card that you get anybody can use that to put in the door you know as long as like bearer bonds yeah you lose them yeah that's got your money so that's where that term comes from that makes sense okay so this is now going to pass the token except we still got one more problem because we didn't authorize it on the other side we actually didn't even look at it we ignored it exactly we did put authorize on the top of the web API but I don't think we had a scheme or any exactly so we're um yeah so we have the the denied Anonymous access we're passing the token but nowhere in the web API is it actually inspecting the token to establish trust with which the user is and and I was thinking about that inspecting the token is one thing but all the validation that one could do like a lot of people right now will make a call to https and they assume that that https transaction that that this happening over a cell is Meaningful it's just private there's no proof that I'm talking to who I'm saying I talk to very rarely do people take apart the cert and use it for valid validation of identity right are we going to do lots of different checks on that JWT to determine so right so so you're right with https um there's nothing authenticating the caller right right um so that's what the access token is providing us with is a means to authenticate the caller it's obviously the API knows that it has to be a jot and it is trusting identity server and so that's part of your your trust and it will look in there for eight for API one and and so all of that stuff you're right so for the access token to do valid to validate it yes there are several steps that need to occur validating the signature is a big part of it we need to make sure that the access token comes from the token server We Trust right and we need to make sure that the access token is meant for our API as opposed to some other API so it's kind of like the hotel room key exactly I can only use at one hotel even one room yeah yeah so it's audience scoped okay and identity server does that validation for me I did server created the token it's up to your API to do that validation okay so we need something in the API to authenticate that and what have we used so far in our other apps to do Authentication right we've used the middleware okay we've cookie if the if the credential is a cookie we use that if we're trusting identity server we use open ID connect so in the web API there is a middleware that again I already have the nuget package added for okay um I need to add it into my pipeline right it will sit in front of MVC right so it gets to see the token before my API call and it is called use jot Bearer authentication nice and this yours this is written by Microsoft really okay so um that's cool yeah so that's already there which is nice and easy so we have this and the options that we have on this thing we have very similar to what we had earlier with open ID connect we have the authority We Trust and are you pronouncing that jot like j-o-t j o t is the pronunciation of JWT exactly yes that's the official it even says it in the specs they put quote jot jot okay okay so who do we trust you got it right and who are we is essentially what these two are showing all right good that's good all right I'll run this again and it would be it would throw forbidden if it didn't fit that no what ends up happening is if the token is um invalid or corrupt or or um expired that kind of thing then it's almost like a no-op so then the call comes into your API as Anonymous so you still need the same you still get the 401 yes okay okay so back here let's refresh and look at that okay that's pretty sweet so the call came in to the web API with the Json web token the what Jason Webb token had all of these claims the bearer token um authentication middleware validated it took all the claims out of the payload and turned those into claims on the user object in your you know asp.net code and so that's how you look in your actual application layer like oh who's who who's the user calling me or what app is calling me you just go query that claims collection for the claim you you know you're looking for very cool okay let's return to the documentation at identityserver.io and look at that diagram and let's kind of look at what we did today one of our accomplishments are today so yes here is our big picture for the typical types of applications oops that was not what I wanted to do here we go there we go so what we did is we actually let me scroll down here what we did is we set up this security token server using identity server uh separate asp.net core application it knows all about your users all about your apps all about your apis we then built a server-side MVC application to connect to that to authenticate the user and by doing so obtain this thing called an ID token and uh was granted the ability to call an API on behalf of that user with that thing called an access token so we basically Drew you know filled in that picture you know part of the picture so there are definitely lots of other scenarios that we didn't have time to cover sure but you could build a pure JavaScript Spa style application you could build a native application that also was trying to invoke those apis again and we have samples up on our GitHub repo for those and we have walkthroughs that walk through you know setting up code to teach you about how to how to design for those okay but anyway yes that's uh that's basically what we covered cool so identity server you can get it at identity server.io now help me understand it is an open source project people can use it but there's also there's a Consulting arm and you can get training yes do workshops with you on the identity server.io website we list a lot of our our options we we do provide services around identity server so we have um we provide Consulting so mentoring architectural Consulting knowledge transfer helping you design what you're you're building we can actually do a larger Consulting so we can actually help build proof of concept ups for you or even a full blown implementation and we can transfer you know ownership to your team and we also provide production support So if you you know come through our Consulting and we help you design your system and make sure you're doing it right then we offer um production Support options we have a three-day training class around identity server and we have a couple of customer partner companies that are helping us build additional products on top of this so one example of that would be all the configuration I showed you was all just hard-coded right and we do have an Entity framework implementation but there's no UI for managing that stuff so that's an example of one of the products that we have then on top of this very cool great example of an open source project and a business behind it yep fantastic so we have learned all kinds of great stuff about identity server you can check it out at identityserver.io and get involved right now with this great open source open ID connect and oauth 2 framework for dot net thank you very much from all of us here at Microsoft Virtual Academy thanks

Channel: Code Geek

Views: 9,991

Keywords: identityserver for asp.net core, identity server 4, asp.net core, identityserver4, identityserver, identity server, security token service, security, openid connect, oauth2, secure web api, secure, identityserver 6, identity server tutorial, identity server tutorial for asp.net core, identity server tutorial for beginners, identity server tutorial for asp.net, identity server for asp.net, identity server for beginners, asp.net core tutorial, asp.net core 6, asp.net core 7, codequs

Id: cCxCg4wLYOE

Length: 131min 5sec (7865 seconds)

Published: Thu Nov 24 2022