ASP.NET Core Cookie Authentication (.NET 7 Minimal Apis C#)

welcome to the raw coding YouTube channel my name is Anton today we're going to be talking about cookies if you understand the authentication landscape you understand that cookies are at the center of it if you understand cookies you know that your authentication solution is secure we'll go through the simplest possible example of obtaining a cookie and then we're gonna dig into the various options and underlying infrastructure of how cookies work in asp.net core how you can configure them and then how they behave in the browser let's go ahead and get started here we have a simple application that's already running and I'm just gonna start filling it out we're gonna have an MVC at the JavaScript example if you're wondering about Spas just take the JavaScript example and do exactly the same thing it's just a Fetch and if you're wondering about Frameworks like next and next JS we are going to take a closer look at them later because they have a server side rendered component which have some specific scenarios that you need to deal with let's start with the MVC example I am going to add default controller route and I will add controllers to Services add controllers this now allows me to pick up controllers from my file directory so directory controllers and here I can have my home controller and this home controller doesn't need to be too complicated for demonstration purposes all we're trying to do is issue out a cookie here's the skeleton for the action that is going to help us assign in or deal out a cookie what we have to do is first we have to create a claims principle we have to convert that claims principle to a cookie the thing that does the conversion will be an authentication Handler specifically a cookie authentication Handler which is built into asp.net core first let's take the HTTP context and on here we will call the sign an async function this is going to trigger the underlying cookie Handler in my authentication video I showed how this function routes back to the cookie Handler and in the cookie Handler how it then deals out the cookie here we want to specify a claims principle and we will await on this function inside the claims principle we will supply a claims identity inside the claims identity we will need to specify a bunch of claims amongst all of those claims I will specify a claim that will just contain a user ID there is a static class present in the.net framework which just contains a bunch of names for all the claims one of which is name identifier which represents a user ID I'm just gonna assign a good to it and convert it to string so it actually fits the claim here is the basic way that you are going to attempt to sign in now you just need to be able to select the mechanism which is going to perform the conversion of the claim principle to a cookie the mechanism the way that you register the mechanism is through going to Builder Services adding authentication and then on here you specify the mechanism you can add schema add your own custom mechanism or a pre-built one which is going to come in the form of add cookie and just to make things simple I'm gonna call this the default mechanism this is called an authentication schema if you don't specify this automatically by default it will just be a string of cookies all I'm doing is I'm opting in to just call this default I will now have to specify that I'm signing in under this cookie authentication schema and that this cookie authentication schema is also the identity provider before I do this let's run the application and see what happens when we try to hit this endpoint we're gonna get an error but let's just make sure that we see what the error looks like first of all I will need to use authentication this is the thing that is going to try to pick up the cookie open it up and read it using the cookie Handler that is registered as part of add cookie I will also use static files and I'm going to create an HTML page in a WWE root folder which is just going to submit a form to that endpoint here is my mdc.html inside the WW root folder let's go ahead and add the form and here is the simplest form that I could come up with again we are going to have an error because we're not specifying the authentication schemas on here let's come back to the browser and the application is already running by the way and I can see that there is an error that I haven't added controllers and that's actually add connections so add controllers there we go that I believe will restart while that's restarting let's talk a little bit about the developer tools when you're working with authentication and you're working with cookies and you're trying to understand what is going on your only option is the network Tab and the application tab those are the main points of interception of communication between your browser and your backend forget about the logs the network tab is your best friend and to inspect the state of cookies the application tab is your best friend let's go to mvc.html here we're gonna find find the login button and from the beginning we have no cookies and the network tab make sure you have preserve logon that is just going to keep the history as it's going along if we take a look at mvc.html and in the response headers that is when the response is being returned to the browser this is what we're going to see and then these are the request headers so this is when the request is being made to the back end so request is out from the browser to the server response is back from the server to the browser I'm going to clear the logs I'm going to Press login and first of all what we're going to see is the request not containing a cookie and the response not containing a cookie either and we can see that we're getting a 500 and again I said that we are about to get an exception and this is what the issue looks like when you're not specifying authentication schemas under which you're trying to sign in let's come back around here we will grab our authentication schema we will specify that we are signing in as this authentication schema and that the identity provider is this Authentication schema as well if you don't understand what I mean by signing in an identity provider think of it this way your identity may come from Facebook so you're assigning in externally they are the providers of your identity and then you're signing in locally you're doing dealing out a local cookie to represent that authentication session so they're the providers you're the one who deals out the sign-in session this is what these two values will represent now that we have specified these let's come back over here come back to mvc.html we still shouldn't have any cookies and the network tab should look something like this so I'll clear it I'm going to log in and we're gonna get a 200 response if I open up login we are gonna see that there is a set cookie header and a cookie value with a couple of parameters which we're just about to go to the original request that's made does not contain any cookies now what I want to highlight is one the cookie is in the browser any new request that is made is going to contain the cookie for that specific domain in the request right so the cookie will be automatically attached to each request that is made from this same domain if we take a look in the application tab we are going to see that we have a name of the cookie which is just prefixed by this authentication schema that we have then there is the value the value is essentially what we've gone ahead and created over here the claims identity is stored encrypted inside the cookie then we have the domain or which domain is this cookie D Delta out then we have the path which is essentially for which path is valid which we will take a look a little bit closer we then have session how long does this cookie exist for then there is the size which is essentially the size of the payload HTTP only is this cookie allowed only to be used over HTTP and you're gonna see how that this value can be configured and affected secure means that it goes over https or not same site can be none lags or strict as this controls at which point the cookie is actually attached to the request so we will take a look at the examples of this as well then we have the other cookies which are same party priority and partition key these are not so important for security as more for privacy and specific feature enabling to cut this video short we're not going to be talking about these but rather primarily focusing on the other ones starting with the name let's for example say that we want to name our cookie differently for this you have the options that you can specify for the cookie oh Dot cookie and do feel free to walk around have a look at what this is open at cookie you can see that you are meant to be supplying an action of cookie authentication options and this is the value that you're essentially configuring ever read through through the documentation see what's on here see if you can try to make sense of it but on the cookie over here you have the name and we can configure it to something like my cookie place a semicolon on the end come back over here come back to this MVC page Log In I'm just gonna re-log in if I take a look at the login call over here actually I want to take a look at the bottom login call not the first one because I have preserve logon so when I travel between Pages the whole log is kept coming back to the bottom I can see that on the request the cookie is present and it's the default cookie once I have re-logged in I can see that there is a set cookie header and by the way said cookie means issue a command to the browser to save the cookie in the browser and whoever is the browser vendor Google Chrome Firefox have to implement the feature of saving a cookie in the browser when the set cookie header is present now if we take a look at the application both of the cookies are present over here obviously the old one we no longer want to be using it we're more interested in just the my cookie cookie let's clear both of these and the next bit that we're gonna take a look at is the value coming back to the home controller where I said that the value is essentially the payload of the identity if we duplicate this line of code and we just start putting in bogus claims into the cookie so let's say I'm increasing the amount of data I'm jamming into the cookie and it starts looking something like this if I come back around here we come back to the login page and again we log in if we take a look at the response headers the cookie section is going to start to be quite big we take a look at the application session essentially the maximum size of the cookie is 4008. asp.net core internally is going to make sure that your cookie is of optimal size and it's going to chunk it into multiple cookies to then once they're reattached with the request are going to be brought in back together to essentially extract the value from it if we come back around to the hello world example over here the change is not reflected immediately but if I refresh we can see that the chunked cookies are in here as well if I take a look at the network Tab and the latest request that was made when you're making the request so pardon for scrolling the response does not set set cookie because this is the bit which forces the set cookie header the bottom bit the cookie that's being attached on automatically it will be attaching all chunks you don't want to be storing all the values in your cookie you want to be storing an identifier and then retrieving additional data on your back end because otherwise you're making your requests bigger than they need to be now that we have a look at generating a cookie this way let's take a look at generating a cookie through a JavaScript example for this we're gonna come back to program CS we're going to use minimal apis and by the way if you're using MVC you may use form data to post to the back end minimal apis don't allow form data you will need to be using JavaScript so that's what we're going to be doing let's Implement a login endpoint we're going to go to the home controller take this statement where we're signing in bring it back to our program Cs and replace the hello world with the sign in function I'm going to remove all of these claims that we were attaching and keep the name identifier to keep the cookie small and throughout the rest of the video we are going to be using this endpoint I'm just going to return an OK payload I need the HTTP context for my ID to recognize so by default a minimal API is capable of injecting HTTP context into the method over here and now I can import sign in async extension function and make the method asynchronous now I can log in through this method using some JavaScript again I can copy MVC say that this is jshtml replace this with a script tag and put my JavaScript over here to sign it here's the script tag I have three functions on here one for login one to fetch the root and one to fetch a test page that we don't have yet but it's for us scenario that we're going to cover in a little bit coming back to program CS I'm just going to make sure that this is map post to match the method that I'm specifying over here coming back to the browser I'm going to close this page and here I'm going to navigate to js.html I'm going to clear the cookie I'm gonna come back to the console and here I'm going to fire a login function again I can inspect what happened with this login function if I go to the network Tab and I take a look at the login call here I can see I hit the login endpoint because I erased the cookies before I made this request I can expect that there isn't going to be a cookie header attached to the request or because I'm signing in on the other endpoint I have the cookie in my response now if I go to the console and I make my JavaScript requests and not test sorry it's going to be the hello world request every single subsequent JavaScript request that I'm going to be making so here is one to the root that is also going to include the cookies same as regular HTTP requests so if I'm going to be reloading the page so gs.html is going to load again on that initial request that is when the cookie is going to be attached if you're building Spas at this point and you don't have server side rendering because.net core as c-sharp doesn't run node.js JavaScript you cannot server side render your JavaScript application so if you want user information you cannot unencrypt the cookie on your JavaScript site you need to make an additional request to your backend extract information from HTTP context.user map it to some kind of custom user object and then return the value and then you can actually store it in some kind of centralized storage so we have our cookie let's come back to it and let's take a look at a couple of more values here we have the domain and I already have a video out where I show how to Leverage The Domain to implement single sign-on on or your spa applications or if you have not only Spa applications but multiple applications as long as they're on the same root domain that cookie is going to work for all of them you sign in on one domain and then you're gonna be signed in on all of the other ones the next value is the path that is not necessarily security related however you can have multiple applications and I have used this feature as well where you can restrict the cookie to be valid on specific paths so you can host many applications and user reverse proxy to route a requests to different applications based on the path so you can say raw coding dot Dev slash app one slash app2 slash app 3 and scope these to those specific paths so you don't even need multiple domains or utilize the domain to do single signal let's take a look at setting the domain and the path if we take a look at where we're configuring the cooking we have oh okay and we can set the domain so here you configure the domain generally for development and production you will read the domain from some kind of configuration and if you set the domain to something like nothing browser will automatically pick it up and set it as the domain that which you're currently on or the path let's say cookie F and we're going to set it to slash test again if you're wondering why path is important you can essentially Implement single sign-on using path okay assuming all of your applications are internal let's come back to console here we will say login come back to network and we'll take a look at login and we will see the cookie or the path test however if we come back to application and I will refresh we will still see the old my cookie and I will actually remove it what we don't see is the test my cookie for this I am going to add the directory test and I'm going to copy js.html into there so we can visit the same page but on the test route flash test and here is the cookie so we can request the cookie on a lower path and then be able to get that cookie once we actually visit that path and that cookie can only be used when we're on that path so if we go to network and I will actually clear it Let me refresh the page because this page is located on slash test.js.html we're gonna see the cooking being attached to the request if we go back to js.html we're gonna see that the cookie is no longer attached and this is how you can authenticate multiple applications based on a path let's remove the path so we can keep working with the cooking in the console let's re-log in the network tab again in the login response header we have the cookie application the cookie is now set we've taken a look at the Domain and path the session takes a little bit more to configure and we will take a look at it size is not that interesting HTTP only secure and same site the next three flags that we will look at HTTP only means that the cookie is only capable of being transferred over HTTP if the cookie is not being transferred over HTTP what else is it good for well if you go into console you type in document and document is reachable through JavaScript and you type in cookie you will notice that nothing is in here let's come back same as other things in the cookie we will look for HTTP only flag and we will set it to false let's come back we'll call login I'll skip the network Tab and we'll go straight to the application now HTTP only flag is set to false that means that the cookie is not intended to only go over HTTP if we bring in document.cookie now we can access this secure cookie through JavaScript the problem with this is if your front-end application is vulnerable to cross-site scripting attacks that means let's say you're redirecting to some kind of page and in the URL query you're putting something like successfully added record to database or something like that somebody will put Javascript in there and that JavaScript can essentially extract the cookie from other users signed in session and then either post it to another domain or send it as a message to an another user that is using your application so it's essentially a cross-site scripting vulnerability something that you don't want to happen so never really want to set that flag to True unless it's some kind of miscellaneous information that you want to give your front-end application the next flag that we wanted to look at is secure and the secure flag is really simple which I'm not actually going to demonstrate so secure policy you can have none always or same as site secure policy just basically means is it allowed to go over HTTP as a rule of thumb you always want this to be secure if you set this To None the secure flag will be off meaning that you can send cookie over HTTP which is insecure traffic which leaves you open to a man in the middle attacks okay so you never want to set that To None either the next option is same site policing oh Cookie same site you have lacks non-strict unspecified lacks traded as default if you set it to unspecified browsers will basically say you want Lacks none lacks and strict is the order in which it goes the same site flag is important for cross-site request forgery that means a site evil.com has a link that redirects to your site you've already seen how if there is a cookie in the browser on a domain it automatically attaches it to every request well if you have an external website that forges some kind of malicious request on your website and the user that is using the evil website is already signed in on your website the Evo website can redirect the user to your website and execute a post or a delete action delete some kind of record or send money or something like that none essentially enables this attack lacks only allows get requests so most of the time lags is okay to have because you're gonna have a redirect between websites especially when you're enabling things like auth or open ID connect when you need to travel between websites and if you want somebody to redirect from an external website to your website and that request to still be authenticated and not error you actually want lacks however if evil.com tries to make an HTTP post or HTTP delete lacks is going to stop that request finally if you have strict any request that essentially forces the user to go onto your domain will be blocked strict will restrict requests to only come from the same site lags will allow only get requests from external sites otherwise it's the same as strict none is not secure I would not recommend to use none unless the cookies are very temporal temporal meaning temporary they are short-lived and are used as intermediary objects to store some data about your user so here by default you will have Lex and this is generally the option that you you want to keep if you actually want to see an example of how the same site flag behaves I recommend you go watch my cross side request forgery video lastly we have the expires and max age currently set to session if you close the browser and open it your cookie will be gone in order to actually persist the quickie that means for the cookie to remain in the browser persist over browser closure you want to be able to mark it as persistent currently you have options like cookie expiration doesn't work you don't want to be setting none of that you have expired time span which is what you want to set to specify how long the cookie can exist for however in order to First say that the cookie should be persisted you need to specify authentication properties as you are signing in besides the claim principle so that's where it ends you want to specify the authentication properties and by the way please open it please take a look at the properties that are contained here and I'm gonna show you how you can see all these properties are being used by the cookie authentication Handler here you want to say is persistent and Market to true let's come back to console log in come back to Network login we'll take a look at the cookie expires is now set to be on 22nd of October if we take a look at the application here is the time that it expires coming back to the application let's configure the expired time span to be from or time span from seconds let's put 10 seconds here coming back to the browser console let's re-log in and here I can call hello world if I remember so that should be good and actually we don't have an authenticated endpoint so that should always be good however when the age expires the browser is actually going to automatically eject the cookie so let's do that again and once the expiration actually sets in the cookie should be ejected I don't know if this UI is reactive I guess I just got to keep mumbling but if I refresh it that is now gone back to the app let's introduce a endpoint that is going to be authenticated I will add slash test this can still have hello world and however it is going to require authorization to do authorization I will need to say Services add authorization this is going to add underlying Services which are going to pick up the cookie see what kind of user has been loaded in there and check watch my authorization video if you want more information and then we want the actual use authorization middleware which is going to utilize these Services because by default I'm not specifying any authentication authorization mechanisms aren't gonna know which cookie to test for this I need to take my authentication schema which represents my cookie and set it as the default authentication schema so I don't have to be creating any policies coming back to the browser let's reissue this cookie so here we have login hello world let's call this a couple of times and because the cookie is going to be ejected at some point uh like a silly bastard and I'm calling hello world but I want to be calling test and that is going to give me a HTTP error no middleware that supports authorization I have added use authentication so use authorization just double checking that I haven't misspelled that let's come back and this time I'm not gonna be calling hello world I'm gonna be calling test properly okay so this will succeed succeed succeed and after waiting a little bit something weird is going on here we're not being unauthenticated let's go to the network tab let's go to test and before I this actually we can actually go to application okay here we have a cookie that resides at slash test however if I refresh nothing is there right so if I call test again this cookie suddenly appears here so my understanding is the test cookie is the thing that's being attached so there is the my cookie we never changed the name so it's a little bit confusing why this cookie is being attached okay but let me go ahead and clear that cookie let me double check that test is giving us a 403 which is forbidden but really it's redirecting us to this path I really log in actually called the function now we can call test a couple of times the cookie is ejected at some point and we stop hitting the test endpoint now if you don't want to be in a situation where your user is using the application and suddenly gets timed out you can use a sliding expiration set to true if we come back around and wait for a refresh call log in and start calling test if I call test wait five seconds call test again wait five seconds again finally call test let's take a look at the network tab the first test we attach the cookie nothing gets returned in the response in the next test we can see that the set cookie header is present so it's not an authentication endpoint which is giving us this cookie it is a regular endpoint again this is the authentication Service that you're registering that is at work here the next test call that we're making no cookie in the response header the cookie is being attached and every single time it's about to expire or at a good time until expiration this cookie is gonna get reattached and restored in the application obviously now that I've been talking it is no longer there but that is what the sliding expiration is doing those are mainly the configuration that you can do for the cookie let's take a look a little bit closer at the internals of the cookie I'm going to close the rest of the tabs and we're going to take a look at points of interest perhaps here you want to follow along if you have resharper or get writer from the description let's open up at cookie here we're gonna find a couple of extension functions generally with these extensions functions what you're looking for is right at the bottom the call to add schema first thing you have the options the second thing generally it's always the Handler let's open up the Handler and I'm going to pin it pen tab now I'm going to look for three things forbidden Challenge and authenticate let's look for authenticate that might be a little bit of a lost cause because everything is going to have authenticate on here essentially let's just find it by looking through so handle authenticate I'm gonna put a breakpoint over here and handle authenticate is responsible for loading your authentication session out of the cookie scrolling down and looking for the challenge here we have sandal sign in if you want place a breakpoint over here call the login function see it reach here and have a look through the variables closer to the bottom is where we find the other two points of interest which will be handle forbidden and handle challenge you can see here in handle challenge handle forbidden we have the authentication properties so when we initialize these flows and we can we can supply authentication properties which you can then inspect here and take a look at how they work the big difference between Challenge and forbidden challenge is 401 we don't know who you are go and challenge you I don't know what the terminology is here who came up with that but that's what challenge is for forbidden is 403 you're not a loud buddy which is more of an authorization concern if I look for actions and attach debugger to my application come back to the browser and call test the first thing that we're gonna see is handle authenticate triggered the reason handle authenticate is being triggered first because first we need to know who are you is there a cookie present we're gonna try to read something the result at this point is not successful so I'm just gonna press play here and we're gonna go to the next stage which is handle challenge async we try to look at who you are we try to load the cookie Wiki was not found too bad you need to go and authenticate the redirect URI here is not specified and we can also see why that happens the redirect URI that is being constructed is for slash test so the current URL that we're trying to reach we then from the options lift the login path which is set to account slash login which is really a big dependency on the identity framework and Microsoft pushing that identity framework but really you want a path to your login screen here right which is is then concatenated with the redirect URI or return URL and then the additional authentication request is for the 404 page that we try to hit but it's not there so that's the challenge being hit there when we're not authenticated and we're trying to reach an endpoint if we come back to program Cs and we have some kind endpoint I'm gonna call it test 22 the situation you might be in is you may have multiple identities and when a person enters a certain flow of this endpoint and you want to be able to say okay you have been authenticated but you haven't been through this flow and you can represent these flows using cookies rather than some entities in the database so if you haven't been through this flow go through this flow let's replace the Lambda with HTTP context and we can say look you haven't been authenticated with this authentication session therefore I'm gonna say challenge async I want to challenge you and I want to challenge you with this schema as some kind of business flow X we are not providing a claims principle however here we can supply an authentication properties it's persistent doesn't really make sense here we're not dealing out cookies however now redirect URI makes sense why it makes sense because we know that underneath the hood if we look or handle challenge async we can see how it's being used if redirect URI is said that that is what is going to be appended on the end of the login path when we redirect there coming back to program CS we can set this to anything that that we want and when we come back around and we call test 22 we're gonna get the regular redirect because this is still requires authorization so let's remove authorization and let's try test 22 again this time we're gonna get redirected to anything that we want the reason is persisted makes sense over here is when we go into sign in async this will extract an eye authentication Service interface and call assign an async functional this interface has an implementation of a regular authentication Service and I can reach it through going this way or I can close these Services come back to program Cs and when we register add authentication as part of AD authentication when we register authentication core this is where the authentication Service has been registered if I open authentication Service here I can find authenticate async this is the thing that is going to trigger the loading of the authentication session from the cookie the actual sign in that is being performed can be found over here we are passing authentication properties over here if again we take a look at the properties how they're going to be passed down all the way into the signing Handler so we find the authentication Handler and put the properties back into it so if we go back around to the cookie authentication Handler we look for a sign in async and we find handle sign and async we can see these authentication properties and we can take a look at how they look like we highlight them scroll down a little bit without making things unnecessarily complicated and not going too deep once we have the sign in context on the properties we will have the is persisted options set so from properties through the cookie sign in context the is persistent option on the sign in context is going to be set and that is when it is going to actually apply the expired time span from your options okay so things make sense once you actually take a look at the Eternal internals and you see how your options are being used once you apply them here this is why I encourage you go ahead open up that code and take a look at how things tie in from both ends now if we go to cookie authenticate Handler and we want it to trigger requirements sorry not requirements the forbidden Clause we have to enter a authorization failure so we have to fail some kind of authorization for this we will need to build a policy which we have to fail add policy um my policy and this is going to be a bogus policy Builder where I will require a claim that doesn't exist with a nonsense value and just to be sure I am going to require an authenticated user I can now take this policy and place it on the test endpoint I will not forget to attach a debugger so we can actually see the debugging breakpoint being hit and furthermore we're gonna understand that that Handler is being executed from the authorization middleware let's open up authorization let's open up authorization middleware scroll down a little bit and by a little bit I mean all the way to the bottom at the very bottom here we have the handle function where after performing a bunch of logic of loading the cookie it doesn't match the correct rules does it have the claim that we have asked for if we go inside this is going to be the authorization middleware result Handler which is the implementation for the eye authorization middleware result Handler interface it's going to see what the result is it's going to be challenged if the cookie is not present and it's going to be forbidden if the cookie is present but we do not meet the policy requirements so let's see both of these with that running we have no cookie let's go to the test endpoint here we're gonna load up the session first and here we enter the challenged Clause okay which after we enter the challenge async of the authentication Service which is an intermediate point so same as we call sign in async on an HTTP context authentication middleware result Handler will call Challenge async on the HTTP context as well which is kind of what we've did in our endpoint as well so this will then propagate the call into the cookie authentication Handler and that will finally redirect you to your destination and this is the authentication attempt from the 404 over here now let's go to jshtml here we will log in I don't want to touch that so again I think I have like 10 seconds to call test uh real quick boom so again we load up the session and now because we're not meeting the claim requirements We're Going Down The Forbidden path again this is going to call forbid async and HTTP context extension under the hood if you travel down it will surface the eye authentication Service and then call forbid async which will then finally propagate into handle forbid of the cookie authentication Handler if you take a look at that method you can see which parameters it's using where it's going to redirect you and which options you should be using and that is going to land us on error boarded and by the way same as cookies are just request headers the way that you get redirected from place to place is if we take a look at the test request you get a 302 status code which stands for redirect and then you have a location header which says go over there browser automatically picks it up and actually sends you there but that page is not found the last and final bits that you should know about cookies is how to sign out and how sign out happens now we left it out towards the end but let's implement it we'll copy this endpoint place it over here sign out instead of signing a sync we sign out async we specify the schema authentication properties can be present we can actually verify this come into the quick authentication Handler sign out async if we specify authentication properties they are how are they being used we can take a look at the cookie sign out context or same as before we can take the context take a look at it and see if properties are being utilized in any manner right so if we are concerned if we want to somehow try to configure this flow when we may see how properties or which properties on the authentication properties are being used coming back to program CS this is how the sign out is going to happen I will call this map get save redirect let's go to sign out all this requests and we're are going to get okay so on the sign out all we'll see is that set cookie is being set to nothing that is going to force the removal of the cookie and for this I'm going to remove my expiration I'll duplicate the tab and I'll go to jshtml let's open up the console and let's log in so I actually have a long-standing cookie that expires on my 22nd of October now on this network tab let me clear everything if I go to the application the cookie is still there if I refresh it's no longer going to be there and that's because in the network tab I am calling the sign out page which wipes my cookie through the set cookie header same as you can only set cookies on your domain you can only delete cookies on your domain as well so if you are signed in to multiple applications and you sign out from one application and you want to propagate the sign out to all the other applications you need to either redirect the user or have some kind of State on the back end which is going to fail authorization or assign the user out if if some kind of global sign out has been triggered you now know how to trigger individual sign out mechanisms through these functions which are present on the HTTP context so if you were in that scenario you'd know that you want to call the sign out async at which point do you want to call the sign out async well at the point of loading the authentication session at which point is the authentication session being loaded in the cookie authentication Handler in the authenticate function if I can reach it right over here you can override the handle authenticate async function where if it does indeed lift a cookie you can take that value check against the database and if that database marks this user as being invalid you go ahead and call the sign out function from this very Handler itself and then also call The Challenge so you'd sign out and either a redirect to the sign out page or you'd sign out and redirect to the login page and this will be it for this video thank you very much for watching if you enjoyed it don't forget to leave a like subscribe Bell notification I think this is the first time I'm asking for the Bell notification but if you have any questions make sure to leave them in the comments if you want to say thank you make sure to leave it in the comments as well come support me and get the source code on my patreon link is in the description big thank you to all of my patrons that are already supporting me hope everyone is staying healthy out there and have a good day

Channel: Raw Coding

Views: 16,022

Keywords: asp.net core authentication, asp.net core cookie authentication, cookies explained, asp.net core cookie tutorial, cookie authentication, .net 7 cookie authentication, cookie, auth, in depth, deep dive, AddCookie, CookieAuthenticationHandler, cookie authentication schema, minimal api

Id: hw2B6SZj8y8

Length: 46min 18sec (2778 seconds)

Published: Tue Oct 11 2022