For further actions, you may consider blocking this person and/or reporting abuse
For further actions, you may consider blocking this person and/or reporting abuse
Mark Smith -
Ramu Narasinga -
Robrecht Meersman -
Ankita -
Top comments (5)
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.
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.
Nice explanation
crisp and concise explanation. Thank you :-)
Imagine you have a super special code, let's call it "Abra-cadabra!" This code is like a magic key that helps you do fun things on your tablet. When you want to play with your toys or watch your favorite cartoons, you just say "Abra-cadabra!" (show your JWT). Your tablet hears it and knows it's you, so it lets you play and watch!
With this special code, you don't have to remember any other words or passwords. It's just like magic! Just saying "Abra-cadabra!" opens up a world of fun on your tablet, without any extra work.
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.