This one is tough to explain LI5. Most physical analogies fall down. I attempted several already and threw them away. And things that are like JWT (like the chip in credit cards) have to be explained too. Hopefully somebody has a good analogy handy.
Edit: Actually I thought of one.
For background, in the US the legal age to consume alcohol is 21 years. Restaurants are required to verify your age is at least 21 before serving alcohol. They normally do this by checking your driver's license.
Scenario 1: (Not JWT)
I'm at a restaurant and I order a beer. This particular restaurant takes age verification very seriously. So the waiter asks to see my license. I provide it, but then he goes and gets a phone. He calls the DMV, waits on hold for a bit, and asks them to verify the license details. Once he talks to the licensing authority and they confirm my date of birth, then he goes and gets my beer.
This is the old style of authentication, where you present your session cookie. When the server receives the session ID from the cookie, it turns around and calls the session service (or queries a database or memory) to find out if your ID is still good, and additional information that might be stored in that session.
As you can see, this can become a bottleneck to service. And the restaurant probably won't stay in business long.
Scenario 2: (JWT)
I'm at a restaurant and I order a beer. This particular restaurant also takes age verification very seriously. The waiter asks to see my license, and I provide it. The waiter pulls out a UV light and inspects the watermark on my license. It checks out ok, so he hands the license back and gets my beer.
In this case, the issuing authority of the license placed a special "seal" into the license that can be used to identify valid licenses. This means that verification can be performed without calling back to the DMV. The waiter has to know exactly what seal to look for. That might mean he has to go look up the state's seal sometimes. Once the waiter determines that the license is valid, they can trust the Date of Birth information on it.
This is the JWT variety of authentication. Once the DMV believes you are who you say (JWT version: autheticated, probably with password), it collects various data about you (JWT version: claims) and puts it on the license (JWT itself). When the license is issued, it is also watermarked with a seal (JWT version: digital signature) so that it can be examined for validity by people who know what to look for (JWT version: your API validates the JWT signature with a shared key). After that, the license (JWT) is trusted and the Date of Birth (claim) is assumed to be true.
crisp and concise explanation. Thank you :-)
I agree with Kaesy - this is tough, and I'm not sure I'd want 5-year-olds managing my application security. :) That being said, here's my not-perfect-but-maybe-adequate take...
Traditional web security has you collecting a lot of stuff about a person, and then, when the person says that it's them asking for the information, you either have to make sure the person is real yourself, or trust that the person isn't pretending to be someone else. Also, when you and that person agree to start talking, you come up with a card that they can show you, and you remember that person.
With JWTs, the other person hands you a card with stuff that you can quickly verify. If it's fake, you can tell them you can't talk to them. Each card is signed, and if it isn't signed by the right person, you can't talk to them. Since you can check all this quickly, you don't have to agree to start talking and remember who all you're talking to - you just make sure you're OK with talking to that person, then go ahead. You can sign these cards, or you can trust other people to sign these cards, but it's easy to spot when someone gives you a fake card.
I am sure you have seen old Pre-Material Design YouTube homepage layout where t...
We’re a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.