JWT is pronounced "jot". Yeah.
Before we get started:
We need to take a look again at the authentication/authorization landscape before we jump into JWTs...
Client
Server
1. Client sends user/password
Client
Server
1. Client sends user/password
2. Server validates user/pass and upon success creates a cookie
Client
Server
1. Client sends user/password
2. Server validates user/pass and upon success creates a signed cookie
3. Server sends cookie
Client
Server
1. Client sends user/password
2. Server validates user/pass and upon success creates a signed cookie
3. Server sends cookie
4.
All further communication
involves the signed cookie
Client
Server
1. Client sends user/password
2. Server validates user/pass and upon success creates a signed cookie
3. Server sends cookie
4.
All further requests
send the signed cookie
5.
All further requests check the cookie
Client
Server
1. Client sends user/password
2. Server validates user/pass and upon success creates a JWT (which are signed)
3. Server sends JWT
4.
All further requests
send the JWT
5.
All further requests check the JWT
It's small enough to fit inside an HTTP Header
Contains everything we need to know about the user
Your Turn!
Everyone spend 8 seconds thinking about these 2 questions, and then Matt will call on someone:
Your Turn!
Why do apps use JWTs?
Your Turn!
Why do apps use JWTs?
How are JWTs and cookies different?
Your Turn!
Why do apps use JWTs?
How are JWTs and cookies different?
Who makes the JWT and where is it stored?
Securely transmits JSON between two parties
Securely transmits JSON between two parties
Acts a lot like a cookie, but has some nice benefits over cookies
Securely transmits JSON between two parties
Acts a lot like a cookie, but has some nice benefits over cookies
Tastes less good than cookies
A deeper look:
It's a JSON Object that has been encrypted & stored in a particular way to allow cross-origin Auth.
Most servers use it to check the authorization of routes after a user has been authenticated.
It can also be used to share encrypted information between 2 parties.
xxxxx.
yyyyy.
zzzzz
Header
Payload
Signature
{
"alg": "HS256",
"typ": "JWT"
}
"alg" : Short for "Algorithm"
"typ" : is always "JWT"
The header is 2-way encrypted and stored as the first part of the JWT.
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
Like the header, the payload is 2-way encrypted and stored as the second part of the JWT.
The Payload is any JSON info you want to store on the client
var signature = jwt.sign(
{sub: 1234567890, name: "John Doe", admin: true},
"Super secret secret secret 1234abcd",
{algorithm: "HS256", expiresIn: "2 days"}
);
Unlike the header and payload, the signature is 1-way encrypted and stored as the last part of the JWT.
The signature is a hash of the first 2 parts of the JWT, and the secret
Kind of like how bcrypt hashes a salt together with the secret, the 2 first pieces become a unique key which certify that the JWT has not been altered in any way.
Your Turn!
Everyone turn to your neighbor and explain JWTs in your own words.
JWT: How?
var jwt = require("jsonwebtoken");
var token = jwt.sign({name:"Liz"},"super-top-secret-string-of-secrets");
var t = jwt.decode(token,"super-top-secret-string-of-secrets");
console.log(t);
To generate:
To decode:
Set the header:
res.setHeader("Authorization","Bearer "+ token);
function checkToken(req,res,next){
try {
var decoded = jwt.verify(req.headers.authorization.split(" ")[1], secret);
if(req.params.id && decoded.id === req.params.id){
req.decoded_id = decoded.id;
next();
}
else {
res.status(401).send("Not Authorized");
}
} catch(err) {
res.status(500).send(err.message);
}
}
router.use(checkHeaders);
JWT: How?
An excellent additional resource: