JWT equals hotel key card. Brilliant, thank you! Both require upfront verification once but permit use of the token in subsequent interactions as a replacement, for a certain time period and subject to further rules and limitations. So good!
i've understood this pretty well for the most part, but the part that confuses me is what if a JWT gets "lost" like a keycard very easily could? anyone who picks it up could access otherwise restricted areas in theory. surely there must be something preventing something this from happening with JWTs?
Yes, if a JWT is intercepted it can be used before its expiry. This is why we have an expiration time and date. We rely primarily on transport layer security encrypting the headers to secure our JWTs. Keep in mind that even if you have a valid JWT that JWT will likely only be useful for interacting with some resources so you need to have the JWT and know which URLs it should go to - similar to finding a key card in the lobby of a hotel grants you access to a room, but you're not sure which one. Some systems also offer ways of invalidating JWTs known to be lost or compromised, such as when employees are let go, but this is not required.
I’ve have been watching videos and reading articles on JWT for some time now and I still find myself going back to another article to understand even the basics but after watching this I don’t think I will ever go back to watching a video on just the basic understanding of JWT again … Thank you very much
I think what is hard to understand, is that you do not need the secret key for the server side validation of the token, if I'm right. Otherwise there would be no difference to using session.
A good analogy, thanks. From what I understand a valid jwt sent by the user's browser allows access to various restricted web pages on an app. Therefore, if the jwt is stolen somehow then the thief will also have access. How likely is this and will possession allow full access without any other checks on the user?
JWTs are intended to be private and secure. In the case that a JWT is somehow compromised, it is still valid until its expiry date, unless the server does some additional checks beyond validating that a JWT was signed by itself. In an absolute emergency, the server's signing key could be changed, but this would effectively invalidate ALL issued JWTs.
thank you so much for this explantion! I searched JWT today since I keep forgeting how JWT works, after watching your video i think i will never forget it
thanks for the explanation. can you please do a video on User Impersonation using Identity/JWT with an example in .NET. I am unable to understand how this going to work when token is generated already. Sorry if question is dumb.
It's not a dumb question. It's not fully in my typical set of content I produce, but I'll add a backlog item for that. Can't predict when or if I'll get to it, though. You'd likely be best searching for creators who specialize in asp.net configuration and security.
The answer to your question is that JWT's tokens are for authorization, not for authentication, different things. It just tells you when a request is authorized on a server or application, but not who or what is doing the request. You need to combine it with another authentication form that checks the user to avoid impersonation.
thank you so much for this very smart analogy Matt! you certainly made a difference to my understanding and you got yourself (at least) one more subscriber (as I am going to share this video with my bootcamp's cohort).
@maziatr I don't understand, either I knew already or you told me just now for the first time. In either of those scenarios, I'd know, right? Also, you seem like a hostile person and I wish you well, but I'll leave you on your journey from here.
