JWT - Explain it to me like I'm 5
The following is a rough transcript of the talk I gave recently at the Newcastle JS meetup. With the title JWT for 5 year olds.
This was one of the most fun talks I've put together and one that I hope everyone enjoyed.
Lets start with a story.
This is Millie. Millie has been baking cookies.
Millie has baked too many cookies and decides to take them to class. So she puts them in a box.
She takes the box to the teacher and says "Miss! Miss! Miss! I baked some cookies, can I hand them out to the class?"
The teacher looks at the cookies and says, "No! No you may not. If you want to hand out these cookies you need a note from you parent"
Millie runs out to the car and gets her father to write a note.
Millie takes the cookies and the note back to the teacher and asks "Miss! Miss! Miss! Here's my note, can I hand cookies out to the class?"
The teacher looks at the note and the cookies and says, "Yes! yes you can. This note says you can hand out cookies go ahead."
Millie is pretty happy about this. She's got some lollies at home she can give away. At lunch she runs home at lunch to grab them.
She brings the lollies and her note to the teacher and says. "Miss! Miss! Miss! Here's my note, can I hand lollies out to the class?"
The teacher looks at the note and the lollies and says "No! no you cant. This note says you can hand out cookies, these are lollies you cant hand them out to the class.
Millie is sad. She goes home after class and bakes more cookies. She boxes them up and takes them to school the next day with her cookies.
She talks to the teacher and says "Miss! Miss! Miss! I baked more cookies. Here's my note, can I hand cookies out to the class?"
The teachers says "No! No you cant. This note is for yesterday its not valid today."
This is what a JSON Web Token or JWT is. It's like a not from you parent. But for your web requests.
In this story:
Millie is your web page.
The note is your token.
The cookies are your request.
The teacher is your server.
A token, like any good note has a structure. In this case a header, body and signature which are base 64 encoded and joined with a . character.
The head tells you about the token and how to read it.
The body is all the information that the token contains.
The signature confirms that the token has not been tampered with. It is a hash of the body and head. Optionally this can be encrypted so that tokens can only be created by someone with the private key but verified by anyone with the public key.
JWT has a bunch of good reasons to use it:
It's based on an open standard so you can implement it in what ever language you want.
It's extensible, you can add what you want into the body so the token has what your applications need.
It's stateless so your clients aren't tied to a single server or machine.
It's hard to tamper with, if the body or head are changed the signature will no longer match.
And they can be invalidated based on age.
Which is good because like anything they come with their own downsides.
There is no inherent way to revoke a token should it be lost.
Which is an issue with a
In closing a JWT is:
This was one of the most fun talks I've put together and one that I hope everyone enjoyed.
Lets start with a story.
This is Millie. Millie has been baking cookies.
Millie has baked too many cookies and decides to take them to class. So she puts them in a box.
She takes the box to the teacher and says "Miss! Miss! Miss! I baked some cookies, can I hand them out to the class?"
The teacher looks at the cookies and says, "No! No you may not. If you want to hand out these cookies you need a note from you parent"
Millie runs out to the car and gets her father to write a note.
Millie takes the cookies and the note back to the teacher and asks "Miss! Miss! Miss! Here's my note, can I hand cookies out to the class?"
The teacher looks at the note and the cookies and says, "Yes! yes you can. This note says you can hand out cookies go ahead."
Millie is pretty happy about this. She's got some lollies at home she can give away. At lunch she runs home at lunch to grab them.
She brings the lollies and her note to the teacher and says. "Miss! Miss! Miss! Here's my note, can I hand lollies out to the class?"
The teacher looks at the note and the lollies and says "No! no you cant. This note says you can hand out cookies, these are lollies you cant hand them out to the class.
Millie is sad. She goes home after class and bakes more cookies. She boxes them up and takes them to school the next day with her cookies.
She talks to the teacher and says "Miss! Miss! Miss! I baked more cookies. Here's my note, can I hand cookies out to the class?"
The teachers says "No! No you cant. This note is for yesterday its not valid today."
This is what a JSON Web Token or JWT is. It's like a not from you parent. But for your web requests.
In this story:
Millie is your web page.
The note is your token.
The cookies are your request.
The teacher is your server.
A token, like any good note has a structure. In this case a header, body and signature which are base 64 encoded and joined with a . character.
The head tells you about the token and how to read it.
The body is all the information that the token contains.
The signature confirms that the token has not been tampered with. It is a hash of the body and head. Optionally this can be encrypted so that tokens can only be created by someone with the private key but verified by anyone with the public key.
JWT has a bunch of good reasons to use it:
It's based on an open standard so you can implement it in what ever language you want.
It's extensible, you can add what you want into the body so the token has what your applications need.
It's stateless so your clients aren't tied to a single server or machine.
It's hard to tamper with, if the body or head are changed the signature will no longer match.
And they can be invalidated based on age.
Which is good because like anything they come with their own downsides.
There is no inherent way to revoke a token should it be lost.
Which is an issue with a
In closing a JWT is:
A note from your parent - that is - A token from a known provider
To authorise your children - that is - To authorise your web apps
To hand out cookies - that is - To make request
To the class - that is - To your server.
Comments
Post a Comment