Great video! We are using keycloak in out project so I was pretty familiar with the concepts used here. Even no one should implement this stuff themselves its still good to know the basics of it.
Just an FYI, I had just spent a good chuck of time at work moving our sessions to cookies... only to have to trash it all.. since part of our application is served up inside an on various client sites. You're kinda hosed if you need a persistent a session from within an and you're using cookies. Chromes gonna kill 3rd party cookies and safari already did. There are "fixes" (CHIPS etc)... but none of their fixes will allow you to create an actual persistent session for your d domain.
One thing I would like to add in case someone is confused, the "withCredentials" option wont allow angular (or any other JS) to read httpOnly cookies, it only instructs the browser to send the cookie values in the request.
And what If I need to send to the API a header called Authorization and the value of this header is the content of an HttpOnly cookie? Thanks in advance!
@@al3vs If the value is in a cookie there is no need to attach it to any header. The server can already read it from the Cookie header which is populated with the cookies associated with it.
@@al3vs The thing is you auth cookie is httpOnly, so the only way the browser will send the cookie to the server is by using withCredentials. If the server currently is unable to identify you when you use withCredentials, then the burden is on it, the client cant do nothing about it.
Great video, and having worked in tech risk in a regulated corporate setting, I can say that not many vendors know about this. Will be great if you can expand on design principles to mitigate other OWASP vulnerabilities , this of course being one of them.
Definitely in the pipeline because I need to improve my SSR skills, I'm sure I'll be reading your articles in more detail (also I've been lurking on your convos with Brandon 👀)
Thanks for the great video! I'm also looking into cookie/session-based auth for an Angular app. I know the point of this video was how auth should work outside of a route guard, but how *do* we create an effective route guard for cookie/session-based auth? Simply checking for the existence of a session cookie isn't 100% sufficient because that session could be expired. It seems that the only way for the client to know if a session is valid is through trial and error. For example, if we have a session cookie, but the session is expired, our app might still assume the user is logged in, so it tries to make an API call. An HttpInterceptor could then catch the 401 response set the auth state to 'unauthenitcated' and redirect back to '/login'. Am I missing anything? Is there a simpler way to handle this other than the "trial and error" approach outlined above?
This is essentially what I would do (keep track of state locally): after a successful auth set the state in an auth service to authenticated, if at any point a request fails due to being unauthorised set the auth state to unauthenticated (which would have the side effect of booting them to the login screen). It's also going to depend on the exact implementation though, for example you might have a session expire after some length of time but allow it to be refreshed without actually requiring the user to manually log back in every time it expires
I think the idea here is to give viewers an Authentication 101, this topic being wide and complex. Let's wait future videos for more advanced concepts 😉.
@@julienwickramatunga7338 yes I'd never write my own session management code on the backend in real life (which is why I have all the warnings in the video), but I think it does help to understand the fundamental/basic behind the scenes concepts
If you need to retrieve the user information after a successful login, how would you chain the request to react to the "authenticated" status? Is it ok to put it inside the effect function?
I use the same Nx style feature/data-access/ui/utils approach for everything big or small (except typically with larger projects I'm actually using Nx)
If you specifically mean something like a JWT the concepts are very similar - user authenticates, gets sent a token, they send that token with future requests. The key difference with a JWT is that the token itself defines who the user is/what they are authorised to do (e.g. what role they have). It's even fine for a JWT to be completely viewable/editable on the client side - all the server has to do is verify that the JWT hasn't been tampered with, and then it can trust all of the information within the JWT (if any of the fields were edited, it would invalidate the signature of the JWT)
@@JoshuaMorony JWT can easily be tampered - one should continually be generating a key refresh with deep certificate chaining to make this right. We do this at the bank I work for and its locked tight, but its expensive in terms of taxonomy of the browser, memory utilization etc… in terms of your video - you should have showed the users how to use UUID, to generate the unique session id, or argon 2. you make very good explainer videos - I watch and read continually no matter how novice things may appear to learn and grow as an SE.
@@chrisburd9751 when you say that a JWT can be easily tampered with, do you mean that even if the secret key remains secret, and the signature of the JWT is properly verified on the server, there is a way this process can be easily duped?
@@JoshuaMorony no I mean the key can be intercepted and manipulated or decoded then reencoded - token forgery and token relay are common and unfortunate unless one implements security properly, it’s not a safer alternative - in many ways deep certificate chaining should be mandatory but it’s not because no one is really serious about securing our data.
@@JoshuaMorony there are many ways that it can be easily duped - from multiple attack vectors. One should always use rolling keys -(certificate chaining) - (deep certificate chaining) involves storage on the mobile device/browser and requires installation to the end point. CSRF, weak storage, JWT brute force on an intercepted token, decoding of the JWT token. Choosing the wrong algorithm, or poorly written authentication allows this. I listen to content all day long everyday in the background - including yours, it just plays and I listen - you do a very good job on your explainer videos; I could never do what you do. All I'm saying there's a widespread misprision that JWT is super secure - on its face value, it's not. If one is serious about launching an application - one should really hire a consultant and not roll it your own. At the bank I work for - we pen test apps from other LOB's the average application presented is hacked within 30 seconds - the first vector of attack for us is always JWT, the easiest entrance point. One we have a tunnel in we'll attack the interior infrastructure.
