ASP.Net Core: 05 - Client Login Token Authentication

[Music] so in this video we're gonna talk about how to integrate the client so in this case our Fassett a wood desktop application and WPF application get signing in to our server so a lot of this video probably 60 70 % this video is just gonna be me talking so it'd be a slight change but really you have to understand the concepts more so than the code the code is very small but you need to understand what's going on and the reason for you know the requirements in the first place so what we'll do is I'll bring up the code on screen or and off to you know not getting your way as such as we are talking through a topic so you can focus on on what I'm saying so we built in the effectively the web server the asp.net core web server in the last few videos and we've set all that up and I've explained it in great detail but there's still more details to go into so all these notes are made with you know to give you information but until we come to use them they won't exactly be of any major meaning so when we go to add this ability for clients to sign in we are going to add the ability to do that via tokens not via cookies so you really need to understand what a cookie is what I didn't where it's coming from why it's not viable for a desktop application all that kind of information so we're gonna talk through this so I'm gonna start at the top where we have this add identity call and you need to also understand the difference between an identity an authorization and an authentication the two different things and you need to understand the clear difference because we are basically separating those two concerns in this video so you will have to understand that the big difference between authenticating some information and authorizing some information so we'll start at this odd identity and basically identity is built into asp.net core and it's call well it's basically an authentication method so it's gonna authenticate a user so it allows you to create a manage users login logout to remove users and ultimately it sets the HTTP context user to you know the authenticated user so the bottom line is identity is an authentication method or not authentication provider so authentication is basically the process of validating some information and by that I mean we have an identity of a user and we're saying the users name is Luke and his email is contact to angel six com now it's alright the client telling us that piece of information which it does through a cookie it says that I'm Luke cannot this is my user name and this is my email but we need a way to authenticate that just like you authenticate things in real life so somebody brings you you know a twenty dollar note to twenty pound bill you're not going to accept it if it looks like a piece of paper or the inks running you need some way to authenticate that that's a real note so you have you know things like pens the test if a notes authentic so that the point of authentication is not to allow a user into your website and into private areas it's purely to authenticate the piece of information they tell you about the self so when you go into a website and you log in and then you're effectively telling that website you're now I'm Luke and this is me and this is my account and it tells you that every single web call through a cookie but the server has to authenticate that cookie every single request to make sure it has valid so authentication the process of validating that information and in the webtoons it's like the name the email the ID and that is correct and now our servers validated that to be true so that we can be assured that when the cookie and the server ends up setting HTTP context our user which is what we ultimately then use in our website to do something with the user then we can be assured that our information is true you know and can be trusted basically authorization on the other hand is the process to determine you know what that user is able to do so it's the opposite of saying you know you now believe that this user is called Luke and he potentially got a role so he's a developer or is a page user or is an administrator on-site you can now trust that that information that the user is telling you through an authentication token like a cookie or a-- an actual token you're now happy that that's authenticated so you listen and now it's up to the website to decide should this use that's got this level of access if you will be allowed at certain parts of your website so authorization is the process of determining what that user is able to do and the standard authorization that we have on our little test private page here that's authorized the standard authorized is nothing more than a statement and it's an authentication policy and it states that it will allow any user access so long as the authentication scheme that was used so in this case because you don't add identity it will be a cookie scheme as long as the cookies been authenticated it will allow it pass because the only requirement of this default authorized is that they have the get I think it's required require authenticated user which we can add manually you know later to show that but the this authorize doesn't necessarily say the user has for instance an account in our database or in our user management obviously through using identity and using the identity manager in say like the login that we're using sign-in manager this is hard tied to an application user which all as hard tied to this kind of identity asp.net core identity so because these are all hard linked so identity in itself includes the Kuki authentication which also includes all of the the sign-in managers and the roles and things which we saw in the source code because they're heavily linked the authorize in this case will actually work and you would have to have a user on you know in your account in your database for that to work because by default when it adds here we see the add off and occasion we have the cooky authentication and then we add all these user managers lookup managers roles claims and then here's the sign-in manager so these are all hard tied in one big happy family if you will so the reason right now that authorized works on our website and means that yes this instance right now you won't get to this private area unless you have a user with the identity of name which will match your databases user that is not necessarily the case that is not always gonna be the case and will actually break that very soon and you'll realize and that's why you need to understand what what really happens with authorize and the separation of authorizing a user based on a cookie and a name raffia is not necessarily hard tied to the authentication side of things being so the authorization side of things here and you need to understand that difference so the other identity adds a coupie authentication so it's going to pass when you log in using the identity if we go to show you it's easier to show when you login with this password sign in and because we're using part of the identity manager the sign-in manager this will write a cookie and then set the cookie for the client and that now contains the information like the username and whatever else information is required so because of that we will have the cookie being passed for every request and we can then authorize that piece of information so when we now add another way to do this which I'll get onto in a minute you'll see that that becomes no longer the only way to authorize into one of these calls so this authorize now would we be able to circumvent the requirement to actually have any user which is not what we want to do we always expect to have a user so it's just something to bear in mind there so that's the main difference between authenticating and authorizing and the authorization providers if you will which again right now the authorization provide by default as part of the or rather the authentication stage when we authenticate a piece of information typically always sets the HTTP context a user so the kooky authentication will set the HTTP context to a user this and again most if not all of authentication stages are expected to set this that's principle so if you hover over it's a claimed principle and that's what our user is based on the Howey user as a bunch of claims and it's this is typically what we get set by every authentication provider so once we authorize we we typically can presume that this is a piece of information we can rely on that husband's set and use that an hour you know authorization policies which will come to so hopefully that's a clear enough separation without going into any more code or detail that you understand the difference between an authentication and an authorization so the authentication validates the pieces of information about the user and the authorized right now simply has one requirement which is that it is it has been authenticated that's it that's the only requirement so along with some authentication provider has said the piece of information disregarding even what that piece of information is simply the piece of information that's been given has been authorized and you'll see why I'm making the statement shortly that this will pass through so in no way says this authorized that we expect it to be a user in our database in our actual user system so authorized does not protect your site from an authentication method simply validating some piece of information it's simply that it's validated a piece of information so we'll have to do more work to ensure the authorized it really does have in our case a we expect to authorize to have a valid user that that's what we do and so that's that so after the basic authentication we can then start locking down parts of the server with claims and roles and this is why I'm mentioning the authorized right now it doesn't do this so a user that could have a role as I mentioned say I could be an administrator on this website so my usual account could have a claim or rather a role of administrator and then we could lock down an authorised that expects the role of the the claim the role of the user to actually be in the administrator role otherwise we'd lock it down so we opened authorise they are built in things like that way you can expect roles here you know we expect them to have a certain role and you also notice we can have authentication schemes because we'll have more than one so all this all come but in essence we will lock down our site further afterwards and so a quick recap on that again just to be super clear because this is really important you do understand it the ad identity adds authentication methods the tapes so that makes full use of all the built-in login managers we pull it up takes use of all of these to the built-in login manager role manager and so on so we can create login logout authenticate and all that inside our code and that's what we're doing right now with where we login we we use these things on the log out is an exception which we'll talk about after book we log in here we create an account and we'll use the same thing the user manager so it's all happily tied together and ultimately then once you do that all these built-in managers for you know creating will write to the database and the sign-in will create a cookie and pass it back so they all work together and ultimately give us a HTTP context our user that matches a user in our database and always would it stores that information that it needs to validate so the authentication part in cookies as I mentioned so at the the claim about the user being this username is stored in a cookie so once the user logs in and authenticated through the use of this call then the identity like the you know this silent manager passes an encrypted cookie so it's opposite exes information but then encrypts it using a secret and passes it on to the the browser then the browser for every single request going for would will then send that cookie back and it will pass through the authentication the cookie authentication that was added through again this call so these are cookies these are authentications the cookie will come in and be passed in and get authenticated and that that information is valid and then that's what ultimately allows the authorized to pass through because now our cookie authentication has validated that cookie it's that's how it's all working so we can actually see this and we can go in try and and effectively clone this cookie and pass it through a separate one and show you that it's still authorizes that's the thievery so let's do you know we can get to do that so right now we have a and the one issue well not the one issue but the one thing we'll have to bear in mind is that our login so our private page redirects to the login page the login page automatically logs in so the only way we can kind of show this easily here is to show you that the the login won't get hit again so we'll start off as normal go to the private page and this will cause obviously a redirect to login logging will now log goes in and we will end up on our private page so if we were to inspect this and reload that page you see now we haven't hit the login page again it's not requested the login page and if we look at this and go to cookies you can see we have a cookie here so we've got the cookie this is the one we passed in there so this is the request for passed in and the responses come back more information about the cookie basically so if we can take this cookie and pass that in I will get something like postman so you go to get postman calm you can download this little helper tool it's just making web requests so we will say we have a get and we want to get the localhost forward colon 5,000 forward slash private and if we hit this up first it's gonna log as in and send us back a cookie so if we were to send that we're now hitting here so it redirects us to login and it's gonna give us a cookie back so now if we look at the response we've had here it's give us a cookie back again and you can see all the values so if we were to hit it again this hasn't passed in a cookie so every time we send this request we're gonna hit the same response because pokeman doesn't store the cookie and doesn't resend it back so we're constantly you know being asked to log in which is you know what we want so right now this is a you know a private area and we're again automatically logged in and this is the cookie this is the thing that would get sent back on every request the browser does it so every single town where we're sending this request we're sending the how so this is timed out as well because we have a really low expiration date on our cookie on our login so let's just fix that just so we can prove this easier so we have in here somewhere there from seconds let's just set it to a long time for now so that we can actually show you this so the point of what I'm gonna try and do here is to show you that we can get a cookie from this browser say and then we can now effectively clone and login to the site so we get the cookie first and like say hunt done this there might be some protection built into asp.net to prevent this this is literally an idea just thought of at least trying to show you to to make you understand so here's the cookie so we are in a cup copy this cookie let's pretend some malware was nicked our cookies off our server now or off our clients machine and then they're gonna decide that they want to now try and read our private information so what I'm going to try to here is to spoof the cookie so we will go to this private call that as we refresh every time it is sending this cookie so let's presume our or rather your computer's infected with some malware let's Nick the cookies and in postman or just a quick google where to add them we are over here I couldn't see this icon so if we send this request via postman as we've seen every single request will hit and request a new one because it does not pass cookies in the first place you know it doesn't keep reading them it's simply a fresh request every time so by default this is a different browser if you will this is an unlocked in user every time so every single time we hit this it's requesting in fact that should have requested oh this is already out of the cookie so if we delete that cookie I didn't think it added cookies automatically and we sent then we get a request for a new cookie so making sure that we have no cookies here we delete and we can see them here you can see that it's basically that with the value of the cookie and then the path and expires and pieces of information domain localhost but in short if we were to pass it with nothing if we were to add a cookie manually and we went to here and we copied this and put in the value why does this never caught the Empire box paste nope really there we go finally so we were to paste the cookie this is the stolen cookie this is the cookie from our logged in browser here and we were to set the name to the threat name just dot asp net tor dot identity after application now I know we haven't passed in like HTTP and expires and all that but I don't think we need to so we saved that cookie now and we've got this cookie to request if we now hit Send we shouldn't see this call being hit here and we shouldn't fight to get up at wishbones back so there you go that has actually worked so now we've got the cookie built in which is our cookie that matches it ends in new H it matches this one we've stolen that cookie and now every request we make is they were getting the actual reply back work we're hitting the successful thing so what we've just done there is effectively stolen the cookie so now we're logged in as the user through you know a completely different browser didn't even need be in the same area this could be across the the other side of the world that you will so that's kind of the importance of you know protecting you why cookies are actually important why you know anyone that steals your cookies can potentially log into your accounts so that is the cookie being authenticated and that piece of information is you know about your account so that's that so that was just really a sidetrack something interesting for you to see and understand that the authentication was coming from the cookie that you pass in that goes into the cookie authentication then it says okay that's an authenticated cookie with some information and now the private area you know gets that information that we passed enix quite happy to accept that the authentication information was valid and so it bypasses that's authorized so hopefully that made sense and no clue it was you know a bit interesting as well to see how to do that so this brings us on to basically the requirement why why we can't use cookies so cookies are obviously I mean we caught but we certainly we don't want to when it's not the typical way or what to expect but cookies are a browser-based thing you pass cookies inside of a browser you know a browser session or generally just browsers it's not usually you can't actually can get to work but it's not the typical expected thing I'll say embedded devices or mobile applications or desktop applications that are simply making a HTTP call like we do in our code where we DIF make a web client then we make a call and we add some headers we don't typically add cookies so they are you know renowned for being a browser based authentication method a browser based storage of some information so with them being only good for browsers our client application at the WPF word application that doesn't use cookies needs another way to authenticate and there's also the other reason that cookies typically expire so you login to your online banking say on your browser and then you come back two days later you don't expect your online bank to still be signed in so cookies are built that kind of environment they were expected to be used on websites that are people login to them then they close the browser than the Roth and some cookies instantly wipe off or get invalidated the minute the user closes the browser tab therefore like been a really secure site Samuel as what banks should do so cookies just aren't designed around the mobile off your mobile after you log into facetted awkward or you log into your facebook or google account you expected that that stays in when was the last time you had to enter your account password once you're logged in you expect to be logged in because your phone in itself is a secured device it's your device and you expected you know you don't have to keep logging in so that's the point of of why we need this other authentication method we need some more authentication method that's going to stay logged in so that when we come to our computer or phone we open up our chat application it's already logged in so for that we could do the simplest way and what we could do is make our own authentication provider so we could override the authentication provider and make a class on top and when a user requests to log in so they wouldn't log in now through this login because this is a cookie based login we'd have another call here that's or typically what you'd have as an API controller that stores the the way that people are then log in through api's and the ad you'd have an API login call and in there you'd have to be passed in your username and password for the first login attempt and we'd first validate you can validate through them the identity help us that that is a valid user you can either try and sign them in what you don't want to or you can use all the methods to simply validate the user and the password which is what we'll do once we validated that that attempt to login of UL through the API is a valid user on the account then we need to generate some tokens some unique piece of information like the cookie dose that will be a key that the user will then pass back in the header of every call so every single call going forward after that you'd pass back this special unique token that validates that that user is is who they say they are similar principle to the cookie so the most basic way of doing that would be to implement an authentication method that simply looks in a database table for a unique ID so when the user logs in and they request the username and password to log in and we validate that we'd at that point them right to the database a list of table say user logged in tokens or something we call it whatever we want and once the users logged in we'd write an entry to that database table that says he's a unique ID we just use a gooood and this is a username simple as that and then when they pass that ID that gooood in a header on every call our authentication method was simply check of the header exists and if it's a key we do a lookup in that database table for that key and see which user it matches if it matches a user then we call the users information set the HTTP context user to that users information and pass back that they've been authenticated and at that stage it would act just like a cookie you know and authenticate the user so then the earth authorized would pass through the issue with that is then every single call because better man this has to happen on every single call so the user requests some messages or sends a message or browses a page or even worse if it starts uploading a file every single chunk of that file which is thousands and thousands of chunks typically for say a picture every call is gonna have to hit the database off to check if the key that we passed in the the unique ID really is you know it's a logged in token so the downside with just making a really simple ID key if you will to authenticate the user is the point of authentication methods is you shouldn't have to keep hitting up the database so this is the server that's running on CPU and inside of you know an app domain but the data stored in an entity framework is stored in SQL server and that's where all our users information is so we don't want to have to every single call hit up an SQL statement back and forward every time because that makes the site slow so what we need to do is instead of just having a unique ID we need to do something similar to cookies we need to use a token that's encrypted with a private key so that the information we pass back to the user actually contains their username their claims who they are as well as a signature so when it comes back into our call every single call we can simply do something in memories in code to decrypt that piece of information and validate it and that's what the cookies do so that's what we're gonna do we simply need to almost mimic what the cookies do in terms of storing some private information passing it back to the user to store on their application and then that's passed along with every call and a header that we validate or in memory without having to hit up the database so that's all the talk for now and I'm sure you're glad of that and now we'll get into implementing this and then we'll see you'll see how it comes together and it'll make more sense as we go so we will start and and what we're gonna use by the way in this is a Java Script or rather a JSON web token I believe they're called JWT and it's it's basically what we've explained it's it's a piece of information that is containing the users claims or just claims in general and then it's signed with a private key and that private key is only known to the surface so we can validate messages it's kind of a standard way of doing things so we're going to start by one thing we'll need to do is move this configuration out of here into IOC just so we have we can access it in the home controller and we need to get stuff so let's go to IOC let's come this in here and start getting some code done so the configuration manager for application and what are you complaining about now oh yeah it needs to be static so just run there for now this will merge your my DNA framework shortly but for now we don't need to bother in this video for that so the other configuration and now we want to IO C container dock configuration equals there so setting up the container instead oops that needs to be a gas for now and again like I said this is just a temporary solution until we move to DNA framework for doing that gets the job done now we have where we make use of this ioc container put your things only in a few places I think it's only that place that's that moved out the way the next thing we want to do is the JWT the JSON web tokens are actually built into dotnet core because they're a really common way of you know of doing this approach so in here you know where we are encoded here now we want to we've added the authentication for cookies so now we want to add the authentication so add JWT authentication for API clients and to do that we just do the services as normal da-ad authentication which have to do each time you want to add an authentication said like say this does it internally and now from the authentication we get an authentication builder and then there's a helper method called add JWT bearer if you don't get that control dot to add the namespace and then open this and there's normally got options so we will get the options and in here we now pass in or rather we want to set the only real thing we need to set is the token validation parameters so this is the thing that will be expected to be validated so authenticated with the tokens so it's new token validation parameters but a blur control darling through that namespace so here we have now we've added a way to authenticate JWT bearer tokens and I'm going to just put in the standard stuff so by standard run of our date the issuer and we'll talk about all this after you don't really need to know too much about literacy yet we'll get this up and running and then we'll go backwards and explain what they are and show you what they are so we'll validate all of these pieces of information like so these are all the key kind of boilerplate standard things you want to validate and so now the issue where an audience and you can read up on JWT tokens so the issuer well in fact I wouldn't even bother going into these pieces of information just just Google for JWT tokens and these are well-defined explanations but what we typically put on is the valid issuer I'd be say for setup word it could be a domain name you can be whatever you eats we assign this key piece of information anyway so you'd want it to be specific to to you if you will and the audience again we're not gonna make yourself so we'll do four set about word so these two things are you can think of a lot as you know who the issuer is who created the tow Kamala sees our website so we'll just call it the set up word and the audience the anok's expected audience of this token as again our website so that's typically what you do also is as two pieces of strings that you can use as you know as you desire they are expected to be certain pieces of information but completely up to you what you type in here and then we say we want to validate against those two so when we generate our token monthly user signs in that we need to make sure we pass these exact same strings in we then have validate issue assigning key which is the most critical part you need to validate that you know that the whole point of this token being secure is validate that when we signed on the server in a secure way that it's actually been signed by us so if you don't validate that you might as well not bother so the signing key now issue a signing key and this is the bit when we encrypt the data will use a symmetric security key there we go and in here we want to encode so we'll do and codeine utf-8 you get by it so what we're doing is turning a string into some bytes because that's how the symmetric key works and we'll this is gonna be your secrets as well by this is the secret key you need to keep secure so you can just type it in here you know a secret key the same is like this we can move this off so let's go to app settings doc JSON and let's in here just add a JWT and I think well let's just do JW I think it just : but let's just use JWT secret key but now just keep them as top-level items and then we'll do JWT issue where j do with JW t audience and then we'll do cassette Oh got word set Oh doc we got word in fact we can put them in that and dry JWT bearer or just JW t because I can just read these out bear with me a minute sir come on you just trying to be too intelligent it's putting things that's the secret key we'll go there the East will go here so such as Jason secret key because we are using which I haven't stated yet so let's just get to that point I'll come back to this well in fact that's it that's ready what we're using oh well what we will be using on will generate the token we're going to use sha-256 so for that the key in order to for that algorithm to work it needs at least 128 bits of information so 128 bits divided by 8 turns into 16 bytes and each string implementation here is 16 is a byte so we need at least 16 characters if you will so this is my super secret key so if you're less than 16 characters here it's gonna fail so this is just the information we store in the app the app settings are Jason and this is secured on your server this is never so you can treat this file as your secret store because when you publish to a server no one can access as it's you know heavily protective you else right we've got like the database string on here so now to rip out this information and I can test by commenting all this out for a minute and doing bar test equals ioc container dot get the configuration and I don't really have to get section to get a section key and then maybe then get piece of information like that I think you do but I think maybe you can also pancake Nate it in here to JWT : secret key so I think that will shortcut to getting us you know inside the object you could get a section then do the keys but I think this is a shortcut so let's see if it worked yeah so that works so you can do a shortcut like that so we know now that will access our secret key so we will undo that and comment that and now we'll pass in that secret key to our signing key so this is now saying whenever we add a token and whenever a token gets passed in we will validate it through this the secret key basically and the reason we don't tell it the way it's been encoded is because part of the key tells it which way it's been encoded it's flexible it will change these two obviously much the same issuer and audience so those are in so that's really all we need to do on this side of things it's pretty simple like I say and so now we'll go to the home controller and we now need a way for an API to log in so we can create an API controller so let's just make a new controller and we call this API controller I think it's actually going to add an API controller which we don't turn in they want ah yeah we did not want to do is just make a code class really this is gonna add so much crap the project that was a mistake no way to cancel thank you and delete all this it's just added to my project so do not click a P I controller I don't know what whether it's added some other stuff it's added code generation design I don't think that was in there I can check with the check with my get repository see what's changed and Bach I'll fix that later but yeah don't don't up that way let's hope it doesn't gone and changed anything else in here and instead let's just go back add plus let's keep it simple and add a why is it not giving me a normal class there we go so API controller I was a lot of work just to write a file and that's a control controlled doctor out there required namespace controller G to remove the others and then what forgot for the comments on home controller we don't have one yet that's bad man if you use the standard web server pages as well money gives the web api calls so we have a controller just like the home controller now and the constructor we get information there we don't care about anything in this one so we don't have a constructor for now and then we'll just have a basic I do probably and we can return I action result and to you know we turn any piece of information then that wouldn't change this after but that's fine for now and we'll call this log in and I'm gonna call it log in or log in technically that is the correct way so we'll do that for now I'm not going to bother with the pieces of information passed and I couldn't really care and for that this is a you know pointed test you want to say API login and this is where we said we will log in and request a token so we'd expect this to be a like you know a login model that's a model and that will be passed in through Jason as we mentioned before when we were doing some tests here from body to get the you know the information so ugly from body say and this would be a model and then this it contain the username and the password and that's the you know the first point where and the only point where they passed the username and password to us but for now we're not gonna bother because that's not part of this video that you know what to do here to do get users login information and check it is correct so we'll we add this in another video but for now that's just there's no need we you know we don't care so we've done the validation we expect the user so far username or often this would be the valid username you just hold in so we validated and this is the user we've apparently you know they've sent the arm with accepted that's correct so now at this point we'd want to generate a 421 generate the token basically and to create this token all now just doing new well we'll do our planes equals new and then we'll pass on a bunch of claims and we'll have a new claim and the claim is gonna be because using a JWT token jadibooti registered claim news and the JT i if you read upon JWT tokens the JT i is basically expected all the time and it is just a unique idea of this token so for that will do a gooood don't new gear we've got to string and we can pass in a into the n i like to do to point in a nice format it's there's one claim that's the ID bear in mind that these flames are just going to be part of the token so we want to also include some information about the user you know what who the user is what the name is so you can do because we're in control of of this you know piece of information once it comes back in when we authenticate this and it comes back in as a HTTP user it's a claim as principle so we're going to have all these planes coming in as the user so we can add what we like here you can add this is just a key value pair so you get out you know my key my value that perfectly fine and I'll still come through so I'll leave that in to show you so all these are is hard-coded predefined strings in the JWT expected tokens so you can read up on where we should really store say the user's username so the emails obvious as an email if you wanted to pass any specifics they're all here so you can really read up on where you feel the name should go so we could you say the name ID which I'd say is probably one of the most fitting and some people use sub others might use unique name again really doesn't matter so much as long as you interpret that information yourself later down the line and pull it in so I'm gonna use I'd say name ID as the username and email is the email and that's all the information we really need right now so and then this is the point where I'm mentioning if we were to pass we were to generate a token here that contains no name or the wrong name then we would pass authentication because we could say unknown user and we'll do this to show you know the point that it doesn't necessarily mean when you're authenticated that you are a specific user the key thing is that your journey when you generate this token you're heavily responsible here to make sure your tokens information is about the user that you know requesting it because this once it's signed and once it can be decrypted using the key it's classed as authenticated so you expecting this information to really be about the person that wanted that token so this would be the you know the email of the user we're validated and that's if you want to pass the email you might not even need that I'm gonna pass the email to show you this so he's the information that we've passed that's good enough for me so that's that's the core of our token so set our tokens claims and now after that we need to keep which same as what we just made because it's a symmetric security key contacted a symmetric security key yep didn't spoil our idea semantic security Gig do the same thing it's expecting that secret key so it's encoded in utf-8 don't get bites and the bites are IOC container this is wiring to middle configuration to there and from that we can get the JWT : secret key so what we're doing here is making sure we we sign with the exact same key so that it can be decrypted got credentials equals new signing credentials with the key and now the only difference here is to be honest we can remove that and just do in line there so we'll make a signing credential something to sign this message with and the one extra piece of information we have to choose is what we want to sign it with so we're gonna sign it with H mark sha-256 and that's I believe JWT is only expecting to be signed by H mark or RSA I believe RSA 2 5 6 I probably wrong on that but I'm going to use sha-256 anyway because it's a nice and strong encryption so create the credentials used to sign the key or rather to generate the token say so this is doing nothing more than creating awesome signing credentials with the same secrets and the specific algorithm we want to use so the last step now or well yeah second to last step I guess is generate the JWT token and this is the secret piece of information that we're going to give the client that is going to pass back in every call so well our bar token equals new goody beauty security token and we have a lot of info in here so let's just do that well I'm an issuer because remember we need to validate validate an issuer and an audience and that the key match you surround are the key matches we need the issue of the audience and the lifetime is obviously the the duration you know if the token have when it expires so the issue where we want to make sure matches so we'll use this piece of information here and that would be issuer then we have the audience which also wants to match then we have the claims which is the you know the key thing we want to extract backwards afterwards they are the claims then we have the signing credentials that we just made so credentials make sure we pass them in and we also have when it expires so typically think of it on your phone like say when you log into one of your apps on your phone when you expect it to then we request your password and you can probably never remember when you've had two so when your password changes maybe and things like that but in general you don't have to you know re sign-in so these are commonly very long-lived tokens so I would say a date/time table now and dot add say months and I'd probably add like a but over three months tokens so if the user doesn't use the app for three months maybe then will expire that token this is also a rolling expiration so if they sign in after two months now the tokens got front further three months if we set this to five seconds if they refresh the page constantly every second it never expire so it's the role in expiration just like the cookie so this is the token we want to give to the client which means when we pull it back and validate it this is the information we can be assured is correct so if the users just logged in here and we validated their username as is that and the password is right we can now pass the username in which was passing the wrong one here for show you something in a minute and we pass the valid email so what it means is when we decrypt this token using the secret key we can be assured that that token is to the user that was logged in with this email and past a female in username so we don't have to do anything but decrypt in memory that's token and then we're assured that this is now a valid claim for this user so this is the key that we're getting back you know the piece of information so what we need to do now is return and this is typically gonna be a JSON call so we'll return okay which is States code 200 and then we'll pass it back an object and was of simply passing token equals and that can be any name you want it's gonna be adjacent objectively requests Jason so passing new JWT security token handler which is what we need to use to them right that's open out and we pass the token in so basically that call generates our token so if we wanted to see that which you shouldn't really keep in memory either by the way that's why you can't do it in line like this you shouldn't keep the token in string memory that's wrong with that end return token to user and by doing this we'll have also broke but we would have broke but purposely added it already in advance to the home controller but you'll see in a member of our deed now originally we had one authentication provider and that was cookies but now we've added a second authentication provider in our home controller where we don't use the identity specific calls like here Haiti to be TxDOT so now we're using a generic context to sign out so the way the sign-out works as it looked for all authentication providers and tries to sign them out so in your code of yet you know before this video you won't have this in there same for the login will have this gone so we were to build this and I think it will build at the minute yeah it build successful control alternis that's just enable all of you haven't already common language exceptions if we now run this site and we haven't actually done anything specific we just added another authentication provider at the minute this will work so this'll load but if we try to access private it will be directed to login and of course that works I'm sure that would normally have failed because the point I was trying to show you is when we add identity we add authentication and the identity constant oh that's why yes sorry so when you use identity identity the it adds the the cookie authentication as the ID the application schema that in identity constants application scheme so I was suspecting that it was gonna add it as the cookie Constance application theme so there's an issue there that you won't see because it's not an issue so that was me being overcautious it didn't won't forget about this and then it crash from wonder why so this sign out jason will find all authentication providers or rather in this case it says their extension method for sign out using the authentication options our default sign out scheme so if you get a crush here though because I'm sure it should have crashed really then you can also pass in to the signup method a specific authentication scheme here and for that you could say then identity conference for application scheme which would be the cookies as it mentions there so that's you can leave them in as kind of a foolproof definitely won't crash when we have other other identities other authentication schemes so let's first just check the whole site does work still as normal that we can in fact know it will crash when we well I don't know let's see let's leave it out and see we just crash but you can go to private you can it will login now you can go to logout maybe yeah you go to login so site all seems good it's working it's logging as M so now what we want to do is try and authenticate through our for set our word application so to do that I'm just gonna use postman for now just to simulate what we're going to be doing an our actual web client so for that let's call web or rather as we mentioned here now if this was private and let's just remove or not necessarily remove but go to the automatic login part here he wouldn't necessarily hit this page off so it doesn't really matter but just to show you what happens if we just return content no login for you just so just automatically login basically and we want to authenticate with that method will see afterwards so before we do that let's just first go API and token I think it was what did we call it login API login so this is how we will now log in an Elfa set a word application we'd send a message here it would typically be a post message and it will contain as you mentioned the JSON for the use of the details the username and password that we'd verify we'll do that in the very next video but for now I'm ignoring that so we come into here we'd hit this up let's forget into here we'd say I passed in my valid username and password we've authenticated and this is my user details so then I'd make these claims of made the credentials that the token and I'll return now the token information so if we then go back to postman here you can see we have the token and this token now is the JWT token this is now what our clients application so in this case our application would need to now store in memory this is our secret key of ul this piece of information that we now want to use to authenticate with the server so all we need to do now to pass in a valid authentication and to access er a section or you know only authorized is that we should just be able to make a new request localhost private say you can see right now we do private we just get no login for you what we should be able to do is add headers so you add a header you click authorization and Bera token and you can paste your token into here and all that's doing if you preview the request is exactly adding a header with the name authorization and the value is bearer and then a space and then token and that's er a standard way you'd typically authorize this so all's we've done in our four set a word application has gone you know client add header and then the headers name is authorization the value is bear at space and then this token we just got returned when we logged in so if we now pass this method back with this token and we request private in theory that should authenticators and you can see it hasn't it's gone to no login for you so what's going on here is by default the authorize and this didn't used to be true in asp.net one but it says now into the thoth arise is picking the default authentication schema can only have one well no it cannot more than one but by default it's only having one so we can do a few things here so the first and let's show you the simplest one is to say that the authentication authentication scheme authentication schemes are and now when we've added the authentication here and we've added jadibooti bearer by default this is a deed like doing here JWT bear defaults i believe it is this is a lead getting better defaults dot authentication scheme and that's just the value of a string bearer so we can use either this so I cut that out we could use get that emit we can use that scheme there like so or you could explicitly just type in barrel which ones recommend like so so you can pass in that so if we know did this it's gonna force this method to authorize based on JWT tokens so now our code should work and our token will still be valid so we go to postman here we've got the same token and it's going to pass that header and we send did that work delete that had as content length no invalid token the audience isn't valid so what it's saying there is our audience is invalid so the first thing we'll do here is let's get this token and I might as well show you what's in this token so it makes sense so you know I've mentioned when we made this token here that we're expecting these claims to be in and whatever you pass in here by the way is not secret so if you do not pass in like anything like really this is why you shouldn't pass and say the email because this can be read by anyone so you probably want the username but in order to see what's in those tokens and what basically what a JWT token has made off so what a j TT token is it's made of three parts so we would paste it or rather not that one we paste this into smoke and see so say stop this a minute paste it here so what october is made up up is this first part here this is just a base for an encoded string and this is the header the header is a JSON string that contains the type of bearer that this is which is a JWT chip not multiple types so it contained the name JWT is a bearer and also contain the algorithm that we decided to use here sha-256 this piece of information will contain that the next one between the dot and the next dot here is the payload and that's basically this piece of information in a base64 encoded string in a JSON format and the final part isn't base64 encoded it's simply the signature of the private key signing so that's the thing that we we really validate against this is the only thing that this is like the public signed key if you will some what our ssh works so this is the thing that I was serving validates is that you know this message hasn't been tampered with here because they changed it it would change the output here so let's just first show you those pieces of information decoded one by one so if we just go to a browser and type in base64 decode and we go to a website that decodes to page 64 paste it in we just paste in just the first part there and decode you can see there's the output so I'll zoom in you can see this is just a JSON string and as I mentioned it's got type JWT and the algorithm HS two five six that's all that's in that anyone can read that if we then put the next part in between the dots so we delete that end and we delete the key there and decode you can see again here now it's the claims so it's the jti which was that the jti here huh string jti and then a unique GUI that we made name ID of my user email my email and then even my custom value as well as the expiration date in a presume epoch maybe there so as you can see those two pieces of information are completely public the just base64 encoded pieces of information separated with a dot and another dot and the final piece is the output of the actuals the in through the algorithm to secure it so when the server when the client sends this key back to the server the JWT authentication reads this part first to get what algorithm it was which is JWT and what method was used and then it takes that exact string and signs it with the same private key and the output should be this exact value here and every doesn't then it's an invalid token if he does it then validates the information inside of it like we have here so the reason this is failing actually is because in fact it shouldn't have failed because you've passed them in there but you can see the information is not in the token so even though we've passed in the token there we don't have the the audience yellow thing I should have worked what's like I say mentioned in that maybe the signing was using the the issuer so we'll look into that anyway but there's the info if you also wanted to see JBL b-t-dub io I think it is yeah I think that's it you can go to this site and you can paste in your string here and it just does the route sure it decodes the header in one section the payload and the other and then it also asks for your secret to verify the signature so you can even go that one step further get our signature out of here how a secret key rather and paste it in and you can see is verified so you can see that after the secret isn't base64 encoded here so this is one way to also see what's going on in the token so that's the token so now it just likes it boils down to why this is thinking our token doesn't have where did we see the oh yeah there so the authentication is complaining that the audience isn't as invalid so let's first just confirm we haven't made a typo and that this really is some info so let's just do for a equals here get that piece of info and breakpoint and when we generate a key or a equals let's just make sure we are getting the information in both instances so we know it's passed down and then maybe we just need to put it in a different section or err you or something so audience oh yeah so typo solutions that oh yeah in fact both of them and ballet that JWT and from Dobbin so that should now get the audience there we go and the funny thing is the even though we technically passed there nor for audience obviously then validate audience if you don't pass one in and even though they both the same they're both null it does come out with an issue so it has to have a value if you want to validate audience or issuer you can't just pass nothing and you've gotta then at least pass something in otherwise it's instantly invalid even though both the class does not so we'll go back we need a new token so go back to this tab and generate a new token will obviously be break pointed on here to check we have check we have that yep and we generate a token and here's how a new token so let's take a look at what's in that token as well just out of curiosity JW I what how's that go BT 2i t I or get that a minute comp number website there we go as pace don't let's see about issuer so no use oh yes see see now it's basically by passing in the values here issuer and audiences instantly appended them to our claims with the claim name of yes and odd so we could not pass them in here and add them manually to here but I guess that's a helper method to simply add them as a claim so now they're in there is a claim so that's changed our key there so with that now and with that token we shall be able to request the private page change the token and send and there we go we now have a reply this is a private area so we have the the login networking because we've told the private area to be making use of this JWT bearer scheme here but what you'll now notice by doing that let us say we go to private on here you just got a black page so if you look at what's going on you now just get in a 401 which is right as an authorized but it's no longer taking us to it's no longer following our redirect that we told it to do here where we say you know configure the application cookies and it's the cookie authentication method and that's because it's not using the cookie authentication method it's now using the JWT so if we were to also login it will log as in or rather you need to just toggle that back to actually log as in so this now logs is it and what you'll find is it's logged as in on the cookie authentication here cuz that's what this does and then we try to go to private but it's protected by a JW the JWT authentication we do log in there it's happily logged as n for the issue you'll now get as if you go to private you'll find your own author you know you're not authenticated because it's with pips that's JWT so yes you you have is you can only authenticate with one authentication scheme by default you can prepend them all together with a comma separated strings so if we're in the slight issue we are doing it this way in this attribute as we expect it to be constants so because the identity constants which is really funny because it's called identity constants but you go to it and it's not a constant so I think Microsoft need to fix that so we can't use that so we're gonna have to get that from you know actually run the code and see what it is which I'm pretty sure is application identity is the string so we were to pass in that and comment and the other one is a string just to show you what happened this now is saying we want to use both JWT and cookie authentication so if we then or rather the default authentication which is the cookie one if we run this now will have the benefit of now we should be able to use a cookie to authenticate as well as a token so both sections can access it so now we go to private will be an authentication as configured for the authentication clean scheme application the identity I'm sure that's what we were so let's just do the just get here safe of our a evil entity constants dot application might just run this and see I'm pretty sure that's what it was application to identity no identity that application all the way around so if we were to pass in that so that we authenticate with both then as I mentioned we should be able to login in queue piece and then access the private page and we should be able to also use our token to log into the private page but you'll see they'll be multiple issue so if we go to private now we should simply this is a private area so what's that's just done has taken us to our login page which automatically logged in and then we passed a cookie back which was then passed in to the request so now it's authenticated on a cookie and if we pass in our token we're authenticating both ways but the issue you'll have here is if we were to say in fact that does seem to have worked that's just double-check this if we were to go to the automatic login and return contents no say just for login for a minute and then what I should do private and this should say no oh so we're still logged in maybe logout done okay so we go to private what's going on shouldn't be logging in here okay that didn't clear the cookie so sign out didn't sign out for one it didn't delete the cookie that's interesting let's put back in this identity Constance and let's make sure see if that signs out right so sign out log out was it logout there we go so apparently it's successful we now go to private and finally there we go so that was what I must have seen before so if we tell it to sign out with default and not explicitly tell it to use the cookie one then this this falls over silently so if you're using the and really I think this is the only call when you're using the sign out because it's not part of the built in thing here it tries to sign out with I guess both like a bearer which isn't a valid way of signing out and the identity so because the only time we ever used this sign out is on the web and it's always gonna be a cookie I simply tell it to always use that that kind of fixes that long out so now in the private what you'll see is you notice it's not redirecting to the login page anymore and that's kind of the side effects that we're getting through having multiple authentication schemes because now there's multiple it's not basically it's not honoring and not listening to our application cookie specific options and I guess that's because how would it do that because it doesn't really know if you use into authentication schemes which one is failed it's because if we both fell let's say our JWT authentication fails when we want to redirect it to forward slash API /login but if you're on a you know browser you want to be directed just forward slash login how would this know from the caller which scheme it was meant to be expecting to you know call could have simply not provided any credentials so it has no way to know which scheme to follow for things like the login redirect so even though the login works and we go to login well it won't know because we say nope so we have to change it back again just for the auto log-in to show if we were to do this then we can log in and then go depravity but what you've done is effectively lost your ability for it to follow the automatic path which doesn't seem like a lot but it's enough to kind of show you that it's broke so that's just for OU ones but now if you go to login because it does login and now you can go back to private and now you can access the private area so that's how we get it to work but this kind of what I'm trying to get out here is the way to think of this as well is I wouldn't have an action that's serving two different to authentication schemes so you might initially think well say the website grows and you want to get messages for a user so what would typically happen is you'd have a web page and that would call to get get message so it'd be like you know get messages and that takes you to an actual visible page that we turn to you know a big box ready with all your messages to load in but then in the background your JavaScript will send a request in to get the messages and but now the the request to get the messages wants to be Jason so it will turn to the API controller say so the way that authenticates will get a bit complicated and you'll see this as we grow but right now for where we are I would say to basically separate these authentication authorization methods rather out so by default author we'll pick the cookie method so that stays as normal that's perfectly fine and what I'd do on the API controller there's on the controller itself so every method applies inside if you want to or specific to each call so we could have like a locked area here public I action result private and this would be turn okay and then new object and then private data pickles some secret so just returning so much secret their route and just do api's private for now and what I'd do is I'd lock this with and authorize and then the JWT bearer defaults got authentication scheme and that would also be authentication schemes so that's how it'll lock this private one so that by default now our website's private will fully function and work and loggers in and redirect and do everything we need to so we go to here go to log out first and now we go to private it would redirect like so and in the API we would hit private with the key it won't authenticate so we should be effectively redirected what's Gus keeps passing on this kook yep still got this kooky set one second remove that cookie send oh it's oh so what's happening here is what you're not seen is even though we've told it to authenticate with a token keep forgetting we have the automatic login thing going on so it's simply it's coming to private it's failed to cook your authentic ate it's redirect to just to login and then the logins worked that's writing this login here so we're to clear that delete that make sure there's no cookies goodbye cookies and we go to the private page here yep no cookies and post you can see now it's hit our login method so it's not actually logged as in so the simplest way to well that's kind of showing you that you've seen the log in automatically redirecting the call then to your API would would follow the wrong path so we'll also fix that later where we we handle of the request is coming in and it's expected to be well you can fix it or you can simply have your client know about what to call so now we don't call API private private we call API private say and this should authenticate because we have the key so there you go now we've got some secret data if we were to make this key wrong and put say a one at the start and send you'll now see the headers all tell us it's an invalid token so you can see this area now is locked by you know your API section if you will is locked by the the JWT authentication and your main area is locked by the default authentication which turns out to be the cookies so that's how we've separated the two and this is how what structure it will have an API controller that's expected to authenticate with JWT and then we'll also have the the other area that's locked by everything else the cookies so one thing we would do though is we'd have our instead of having to do this which is nasty we can do multiple things one we can look at either any request at all that comes into an API controller goes to you know a specific thing or instead of doing that we can just make and attributes ourselves so for now I'll just chuck it up here just because this is all gonna be cleaned up after so we're gonna publish class authorize and we'll say authorize token and it's an attribute and that's an authorized token or not or so north as attribute so that's the same now we can now do instead of that and we'll also cut that as we use it amend we can now say authorized token instead so it's nice and clean and we use so when were you know securing multiple sections we can use authorized token instead of authorized and also need to do in the token is in the constructor we do the authentication schemes equals the bearer and that's it so now we have you know an orphan authorized token so it's much easier to you know put this into multiple areas that are protected so that's all of the code if you will and we're now protected by you know we've got tokens in there that we can now protect and use through API and that's what all merge you know into the Fassett a word application next which I'm sure you all down to get back to so we'll we'll finally be able to make the real working full login page of the setter word to really log into the server and that's what we'll do next so the last thing I want to touch on though before we go on this video is obviously now the issue you have is oh and the the issue I also didn't show actually let me just show you the I forgot one bit so now once you've authenticating you in here you want to say get the user so now the user is obviously as I mentioned hasty to be complex like a user that's what we should have got and then we could say some secret for and say this is the user we're going to try and get some information about and in here to get the user name you'd have to go through the claims and then specifically get find first to thank as a helper no claims out show they're fine first so you'd get the claim for and then this is where you're expecting to find the JWT [Music] forget what it's called already go back to an option would move this as it gone I'm after oh so that login right above we passed in the user's name ESA so because you've got two issues one the HTTP user is not necessarily gonna have basically to be user dot anything specific you can't say dot name or anything like that didn't go to identity but then I'm pretty sure the identity won't have name so we can try can we can tweak our JWT to try and get our so let's first just look at that that's let's register a Bali token on let's see what we get back here let's see if the JWT authentication has set the identity name correctly or whether it's expecting you know maybe expecting a certain thing in it mathematically deserialize to a certain thing because the only thing we really care about is or for the most part is the identity name so you can see you don't get the identity name but you can see we do have a name claim type which is that name so if we were to set I guess that is our string for where we want the name and then I can look at where that constant is afterwards let's see if when we generate a token if we had a clean new plane for that key - let's just say Angel six and then let's get a token and see about then populate the identity name and no big doors we'll probably use that and just like say find out the identity because we are using identity before our provider if you will kind of makes sense so private we want to do API login first get a new token get that longer token now in the private area paste that in and request it and now do we have the user's name yeah so perfect so if we wanted to say pre-populate HT to be complex dot user that name instead of having to go HTTP dot user doc claims and then trying to find the name from the claim because this is such a basic piece of information we can pass in laughter as our name we can also but as a you know there but we don't want to and the other thing I didn't show you as well as I was going to show you now all that claim information has come through and this part of we click send it's part of the user and you can see now we up user claims or rather user identity claims and all those claims we posted it there and there's our own piece of information so we can pass whatever we want so that we've got this info which will come in useful you know get in future so you'll see that used shortly but now at least time we use HT to be context dot user dot identity got named to at least get the users name to then query our database if you will for you know pulling specific information we want to add this so that the user name and then email we can leave them for now so we just need to know where this claim ideas which may be claims identity dot clean I think I just found it magically yeah there we go that was a lucky guess so claims identity dart default name and we had the username there and now when we run this we will have our HTTP user context P contacts user the same in both situations so it'll be the same for an API call as well as a cookie call both of them would fill in HTTP context user dot identity name so we can make use of that now to as I say then query or whatever we wanted so then we could start creaming the the database context forgetting information about the user for getting messages there for the user because the key is then the user name you might want to pass the you know some other information in case the user changes the name but that's irrelevant to this kind of what we're showing off in this video doesn't really matter so now we couldn't log into that private area the same as when we log into this private area we use the exact same thing use context user identity name for both situations so now if we just prove that we go to the private area we see how I waned your six and now we go to our it's all the private area we can see we've got the same user so that's the two validations so back to the point I was making or about to make is the issue with this token and the issuer mentioned at the start of the video is that the authorized and including the authorized here simply authorizes when the the role of the authorized is simply that the authentication any one of the authentications is confirmed so what that means is so long as we have a valid JWT token passed in it is gonna come into this specific call so then say the user now wants to sign their account out of their mobile device or out of anything is calling the API how do you remove that token because that token is in no way stored in a database it's nowhere it's simply based on an essay an sha-256 algorithm they're saying if you sign that token with this key and it's a valid token it doesn't matter about what informations in that token whatsoever it's going to authorize and come through so you're in a situation where you can't deal with arise a token like by default now that token is just simply a signed piece of information that will always sign the same way with you know so long as your private key is the same and you wouldn't typically change this private key because then every single user across your whole website would get signed out because it no longer match so the issue you have is how do you sign out how do you invalidate them or how say user wants to log in and see where the logged in and wants to kick everybody off their own site even changing their password wouldn't invalid a this token because like I said the token has got nothing to do with actually being related to the users database you're not hitting the database what you're proving is that the time you generated this token you validated that you could sign in and from that point on you simply given them a token that will always always validate it will always pass authentication so one way around it that people try to do is set the token to expire every five minutes and then after five minutes they can do a bit of trickery that say once every five minutes then it hits off the database checks if the user still being allowed to you know if they haven't been kicked if you will but still involves database setup and it's a lot more complicated to be honest because then every time you generate the token you need to store it in the database as a user's sign-in token and then every user wants to sign out of that token you delete the token from the database and then five minutes later when he's requested the token won't exist and then it you know it's invalidated but that also means that for five minutes if this is a you know a user's account that's super important or super critical and somebody has just got hold of their data in five minutes time they could do a lot of damage so that method doesn't really give us an instantaneous login logout type experience so the other option and the optional I'm doubling with here is as part of the authentication of the JWT tokens I'll make a custom I am decided solid on this yet but I'll make a custom authentication for this JWT or I'll simply override the JWT authentication code I haven't little too much into it yet I can see I can add some don't know there's any options and here for doing anything custom but the point is I'd simply intercept the authentication stage so there might be a way in here to set a challenge is a challenge header anyway that the pointers I will intercept this authentication stage so yes it will validate that the the signature is correct and the message is correct but on top of that I will add a custom authentication step which would check if the tokens ID the jti that we added to the token if this ID isn't in memory on the server so every time we create the token and we've got the token here what I'd do is in really simple terms and this is like saying my thought is we somewhere on our server with the public static lists of it wouldn't be a string so much but you know say be ID string the string token using generic class some authenticated tokens something like that and then in this list of tokens oh yeah we've completed that doesn't matter where it goes like I said it just be a pointers this would be some static list somewhere and then whenever we give out a token we would say tokens not add the user name and token well the token dot right token did this value and you could you know in theory then you're storing your secret opens in your service memory but you know that's one way of getting around it it's and again that's the point you simply have this list of tokens and then a part of the authentication we check of that list in memory is still there and if not we we do authenticate that token as an extra step so when the user wants to instantly log out or invalidate a token so we have a log I'll call it would simply pass in the token and an invalid a tip would we move it from that static list so that's another thing we'll have to do is to figure out a way to actually invalidate these tokens because the authorization is simply that it's just that it's authorized long as the token can be signed in the same way so it's not necessarily complete right now it's that's something to think on but hopefully this is kind of covered how an in great detail I should hope how we sign in from client and thus the very next thing we'll do the next video we'll put this all together and turn it from the temporary two dudes and things into a real working sign in from the facade a word application any questions on lunch let me know if you want to support what I'm doing I do have a patreon page I'll put the link in the description any supporters greatly appreciate it and as usual any comments questions just leave them in the comments below and I'll I'll get back to you [Music]

Channel: AngelSix

Views: 23,088

Keywords: asp.net, core, jwt, json, token, authentication, authorize, login, entity framework, entity, framework, user, create, sign in, manager, sql server, sql, transact, ssms, c#, mvc, basics, tutorial, serv

Id: h5Y7GMVHptQ

Length: 93min 38sec (5618 seconds)

Published: Fri Feb 23 2018