JWT! JWT! Let it all out!

JSON Web Tokens
want to rule your world
John SJ Anderson | @genehack | Hack Salem | 14 Sep 2016

Hi, I'm John

VP, Tech
Infinity
Interactive

So, what's a JWT?

jwt.io

What
Does
That
Even
MeanHack Salem | 14 Sep 2016 | @genehack 7

Think of it as…
• A lightweight alternative to cookies
• A form of access control without authentication
• Cross-site single sign on (SSO) without cross domain pain

Made of stuff you already know
• JSON Objects
• Cryptographically signed and hashed
• Transmitted during HTTP request

JWT teardown
• dot-delimited string ('.')
• 3 parts
• header
• payload
• signature
• Example: xxx.yyyyy.zzz

JWT teardown: header
• Plain ole JSON object
• Base64Url encoded
• Typically indicates token type and hashing algorithm
{
"alg": "HS256",
"typ": "JWT"
}

JWT teardown: payload
• Also plain ole JSON object
• Contains "claims" -- really just data
• Reserved, public, private
• Also Base64Url encoded
{
"name": "Hack Salem",
"admin": false
}

JWT teardown: signature
• Encoded header, plus
• Encoded payload, plus
• A secret, plus
• Signing algorithm from header
HMACSHA256(
base64UrlEncode(header) + "." + base64UrlEncode(payload),
secret
)

Putting it all together

More advanced usage
• Encrypted payloads (JWE)
• Nested JWT
(Won't get any further into these tonight…)

Libraries for DAYS
• .NET, Python, Node, Java, Javascript, Ruby, Perl, Go, PHP
• Haskell, Rust, Lua, Scala, Clojure, ObjectiveC, Swift, Delphi
• Support for your favorite language/platform is probably not
an issue

OK,
you've
got
my
attentionHack Salem | 14 Sep 2016 | @genehack 18

How
Do
I
Use
It?Hack Salem | 14 Sep 2016 | @genehack 19

Basic auth/authz usage
(stolen from jwt.io)

Things to be aware of
• Payload/header NOT encrypted (in this setup)
• …don't send anything sensitive!
• Need to control expiration, re-issue, etc.
• Some APIs will send a fresh JWT to the client per-request
• Sites other than issuing site can receive JWT
• …if they share the secret

How is it actually transmitted?
• Up to you! Various methods:
• As part of the URL
• In the POST body
• In the Authorization header using bearer scheme:
Authorization: Bearer <token>

Authorization without authentication
• Scenario:
• You have an API
• You don't want to make anybody authenticate to use it
• You don't want it wide open to the Internet either
• a/k/a authz without authn

Solution: JWT with RSA keys
• Alternative to secret in previous scenario: RSA key-pair
• Can include the public key in the JWT header using JWK
• JSON Web Key, natch
• Allows API client to produce claims in a veriﬁable way

To set it up:
• Give authorized user a RSA key-pair
• You can even let them generate it — you just need to:
• Record the ﬁngerprint of the public key (important later!)

On their side:
• They make JWT using the private key
• They include the public key in the header
• Include iat (issued-at) and exp (expires) claims
• Send JWT in Authorization header with API request

On our side:
• Get the public key out of the JWT header
• Validate the JWT signature using the key
• Validate that public key ﬁngerprint is white-listed
• Signature produced with private key
• Public key is white-listed
• Therefore we know JWT is valid!

Things to be aware of:
• You still want to validate iat and exp and any other rules
• Your library should probably do that stuff for you, mostly
• Again, nothing is encrypted, so don't plan on sensitive stuff
in the payload or header

Let's see some code!
• May look a bit strange
• New experimental language, Nacre
• Transpiles to Javascript

Client side
my $pri_key = Crypt::PK::RSA->new('./key.pri');
my $pub_key = Crypt::PK::RSA->new('./key.pub');
my $token = encode_jwt(
alg => 'RS512',
extra_headers => {
jwk => $pub_key->export_key_jwk('public', 1),
nonce => undef ,
},
key => $pri_key ,
payload => { iat => time() },
relative_exp => 1800,
);
HTTP::Request->new(
'POST' => 'https://example.com/endpoint',
['Authorization' => "Bearer $token"],
encode_json({ request => 'body' })
);

Client side: making the token
my $token = encode_jwt(
alg => 'RS512',
extra_headers => {
nonce => undef ,
},
key => $pri_key ,
payload => { iat => time() },
relative_exp => 1800,
);

Client side: adding the public key
extra_headers => {
},
Key: ﬁnd an RSA library that supports export to JWK format!

BTW,
just
kidding
about
Nacre…Hack Salem | 14 Sep 2016 | @genehack 33

it's
Perl!
(of course)

Server side
my $auth_header = request_header 'Authorization' ;
status_401 unless ( $token ) = $auth_header =~ /^Bearer (.*)$/;
# try to decode it and confirm valid sig,
# and valid iat and exp claims
my( $header, $payload );
try {
( $header, $payload ) = decode_jwt( token => $token , decode_header => 1 ,
accepted_alg => 'RS512' ,
verify_iat => 1 , verify_exp => 1 );
};
# no catch block, just drop the error, we're out of here in that case
status_401 unless $header and $payload;
# check that expiration time is less than one hour
status_401 unless $payload->{exp} - $payload->{iat} < 3600;
# check that the included public key is on the whitelist
my $pk = Crypt::PK::RSA->new;
$pk->import_key($header->{jwk});
my $thumbprint = $pk->export_key_jwk_thumbprint;
status_401 unless config->{whitelist}{$thumbprint};
# if we get here, we're all good!
...

Server side: get the token
my $auth_header = request_header 'Authorization' ;
status_401 unless ( $token ) = $auth_header =~ /^Bearer (.*)$/;

Server side: decode the token
# try to decode it and confirm valid sig,
# and valid iat and exp claims
my( $header, $payload );
try {
( $header, $payload ) = decode_jwt( token => $token , decode_header => 1 ,
accepted_alg => 'RS512' ,
verify_iat => 1 , verify_exp => 1 );
};
# no catch block, just drop the error, we're out of here in that case
status_401 unless $header and $payload;

Server side: decode the token
• Key in header wrong? FAILS
• Not right algorithm? FAILS
• Doesn't have iat and exp? FAILS
ALL that validation is happening inside the library, so I don't
have to worry about it.
• Me? WINS

Server side: do more checks
# check that expiration time is less than one hour
status_401 unless $payload->{exp} - $payload->{iat} < 3600;
# check that the included public key is on the whitelist
my $pk = Crypt::PK::RSA->new;
$pk->import_key($header->{jwk});
my $thumbprint = $pk->export_key_jwk_thumbprint;
status_401 unless config->{whitelist}{$thumbprint};

Server side: more checks
• We specify in the API docs that tokens can only be valid for
one hour
• Have to check that ourselves
• Also need to make sure this isn't some random RSA keypair
• Need to make sure we know this public key

Server side: THAT'S ALL FOLKS
# if we get here, we're all good!
• If we know the public key in the header,
• then we know the private key was used to sign the JWT
• (or it wouldn't validate)
• and therefore the JWT is from the private key holder
• (who is, by deﬁnition, authorized!)

IMPORTANT NOTE!
This does, of course, depend on the client keeping the private
key actually private
…
But access revocation is as simple as removing a public
keyprint from the whitelist.

Conclusions
• JWTs solve some really common problems.
• JWTs solve them in a pretty elegant way.
• This is really pretty damn cool.

Conclusions
• JWTs solve some really common problems.
• JWTs solve them in a pretty elegant way.
• This is really pretty damn cool!!!
• You should think about using JWTs.

Questions?

Thanks!

JWT! JWT! Let it all out!

More Related Content

What's hot (20)

Similar to JWT! JWT! Let it all out! (20)

More from John Anderson (20)

Recently uploaded (20)

JWT! JWT! Let it all out!