►
Description
Don't miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from 18 - 21 April, 2023. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Handling JWTs: Understanding Common Pitfalls - Bruce MacDonald, InfraHQ
If you use JSON web tokens (JWTs) for authentication, handling them securely is your first and last line of defense. However properly using JWTs can be confusing. Even if you follow the specification you may still be vulnerable to some attacks. In this talk Bruce will give a friendly introduction to JWTs and how to work with them in your application. We will cover what is in a JWT, and how to make sure you can trust it. Once we understand the basics Bruce will demonstrate some common pitfalls in signature algorithm confusion and secret brute forcing. Finally, Bruce will cover JWT verification and security that will ensure you can trust your JWTs.
A
Welcome
to
Json
web
tokens
understanding
common
pitfalls.
My
name
is
Bruce.
You
may
recognize
me
from
the
show
floor
as
the
guy
that's
overly
enthusiastically
handing
out
info
stickers
I'm.
Actually
a
software
developer.
My
background
is
in
web
development,
application
security
and
access
management,
so,
in
those
roles,
I've
spent
a
lot
of
time.
Reading
specifications
for
the
web,
such
as
the
Json
web
token
RFC
and
today
I
hope
to
distill
some
of
that
knowledge
and
bring
it
to
you.
A
So
this
is
a
101
track
lecture,
which
means
I'd
like
to
start
from
a
base
foundational
knowledge
to
get
us
all
on
the
same
page
first.
But
if
you've
worked
with
Json
web
tokens
before
then
this
might
be
a
good
review.
Once
you
have
them
implemented,
you
generally
just
start
relying
on
them
and
trusting
that
they're
working
as
expected.
A
So
this
might
also
give
you
a
way
to
go
back
and
make
sure
that
you're
actually
using
Json
web
tokens
securely,
starting
from
the
base
we're
going
to
be
going
over
a
Json
web
token
format,
so
what
they
actually
look
like
and
what's
inside
of
them,
along
with
how
they're
actually
used,
then
we're
going
to
move
on
to
signing
Json
web
tokens.
This
is
the
key
infinitive
information
that
I
want
to
make
sure
everybody
can
get
on
the
same
page
for
because
the
signature
is
the
key
to
security
for
the
Json
web
token.
A
A
I
like
to
start
things
off
with
some
real
world
analogies
before
we
actually
dig
down
into
the
technical
details.
Anybody
here
actually
go
to
the
bar
last
night.
After
the
conference
I
know,
I
did
and
the
first
thing
that
happened
when
I
went
to
the
bar
I
guess
I
have
a
youthful
glow.
Is
they
asked
for
my
ID,
so
I
produced
this
government
ID
and
gave
it
to
the
bartender?
A
The
first
thing
the
bartender
did
was
look
to
see
that
the
ID
was
valid
issued
by
somebody
they
trusted,
which
was
the
Canadian
government.
If
it
looked
like
it
had
all
the
anti-forgery
features
that
an
ID
has
and
finally
once
they
trusted
it,
they
read
the
information
on
the
ID
to
make
sure
that
I
was
actually
who
I
say:
I
am
and
I
can
buy
alcohol.
Finally,
once
they
validated
that
information
was
correct,
then
they
served
me.
This
is
actually
pretty
similar
to
the
process
of
validating
a
Json
web
token,
with
an
application.
A
A
I
need
some
kind
of
virtual
piece
of
ID,
that's
issued
by
a
trusted
Authority,
but
maybe
in
this
case
not
the
governments
that
also
wouldn't
scale
very
well.
So
who
do
we
trust
online?
We
trust
the
big
tech
companies
like
Google
or
Microsoft,
so
maybe
we
can
use
them
to
sign
in
or
maybe
even
on
a
smaller
scale.
If
we
have
our
own
micro
Services
we're
using.
Maybe
we
have
an
authentication
Service
that
we
trust
that
our
other
micro
Services
can
rely
on.
A
So
what
is
in
a
Json
web
token
or
JWT?
Well,
it's
an
acronym
and
you
can
break
it
down
to
its
three
parts
pretty
straightforwardly.
The
first
part
is
Json
or
JavaScript
object,
notation
if
you've
done
web
developments.
I'm
sure
this
looks
familiar,
it's
a
pretty
standard
way
to
send
information
about
an
object
between
a
server
and
a
client
in
a
way
that's
easily
readable,
the
next
part
W
for
web.
A
This
is
the
expected
place
that
Json
web
tokens
are
to
be
used
normally
between
microservices
or
any
other
application
running
on
the
web,
and
finally,
there's
t
for
token-
and
this
isn't
a
token
in
the
sense
like
a
Bitcoin
or
any
other
kind
of
cryptocurrency.
This
is
just
token
in
the
form
of
a
piece
of
information
that
asserts
something
about
the
person
that
holds
that
token.
A
So
this
is
what
a
Json
web
token
actually
looks
like
it's
pretty
esoteric
and
intimidating
to
humans.
Pretty
clearly
not
meant
to
be
read
by
us
and
if
you
look
closer,
even
though
it's
intimidating
with
a
bunch
of
numbers
and
letters,
you'll
see,
there's
actually
three
dots
separating
distinct
parts
of
this
Json
web
token.
A
One
important
thing
to
note
is
that,
although
this
looks
very
obscured
and
potentially
secure,
it's
actually
just
base64
encoded
base64
encoding
is
just
a
standard
way
to
encode
information
to
send
it
over
the
wire.
So
a
common
misconception,
I
guess
I've
seen
when
people
are
working
with
Json
web
tokens
is
that
they
think
they
can
store
secret
information
in
them
and
in
the
case
of
a
standard
Json
web
token.
That
is
not
the
case.
It's
just
base64
encoded.
So
whoever
receives
this
token
can
decode
it
and
read
whatever's
inside
of
it.
A
There
is
something
called
an
encrypted
Json
web
token,
which
I'm
not
going
to
talk
about
here,
but
if
you're
looking
to
send
encrypted
secret
information
to
somebody,
that's
what
you'll
want
to
use
instead,
so
let's
go
through
the
components.
The
first
component
of
the
Json
web
token
is
the
header.
So
this
is
information
about
how
the
token
should
actually
be
validated
by
the
party
that
receives
the
token.
In
this
case,
you
can
see
that
it's
specifying
the
hs-256
algorithm
was
used
to
create
the
signature
and
in
the
case
of
all
Json
web
tokens.
A
A
The
next
part
of
the
token
is
the
payload.
This
is
the
midi
bit.
That's
your
clients
will
actually
be
looking
at.
This
contains
all
the
information
about
the
party
that
is
presenting
the
token,
so
this
could
be
a
token
presented
by
a
user,
or
it
could
also
be
a
token
presented
by
say,
a
machine
like
another
micro
service,
calling
it
to
a
different
micro
service.
A
A
There
is
IAT
which
stands
for
issued
at
this
is
the
time
the
token
was
created
and
if
you
receive
a
token
with
an
issued
ad
in
the
future,
it's
not
valid
and
the
Third
Field,
which
is
also
an
extremely
important
one,
is
exp
the
expiry
of
the
token.
These
are
both
Unix
timestamps.
The
expiry
is
important
because
if
you
receive
a
token,
that's
after
the
expiry,
the
information
in
it
may
no
longer
be
valid
so
kind
of
going
back
to
the
ID
analogy
from
earlier.
A
A
And
finally,
there's
this
signature
there.
This
part
is
kind
of
a
little
bit
more
difficult
to
demonstrate
because
it
doesn't
decode
into
Json.
It's
just
an
Integrity
check
value
for
that
header
and
payload,
like
I
said
this
is
actually
the
most
important
component
because
it
lets
us
know
that
the
information
in
those
first
two
sections
has
not
been
tampered
with,
and
we
can
trust
it.
A
A
So
when
the
party
is
creating
a
Json
web
token,
they'll
take
that
header
and
payload.
So
the
information
about
how
the
token
was
signed
and
the
information
about
who
the
token
was
for
and
they'll
generate
a
hashed
based
message,
authentication
code,
which
is
in
both
full
using
the
header
and
payload,
along
with
a
shared
secret
key.
A
One
important
thing
to
note
here
is
that
you
don't
really
have
to
worry
about
how
hash
based
message.
Authentication
codes
are
working.
Just
know
that
when
you
pass
in
this
shared
secret
key,
which
is
like
a
password,
it's
going
to
Output
some
unique
value
and
if
anything
in
the
payload
of
the
token
changes
like
say
somebody
decodes
the
token
and
changes
their
email
to
admin
example.com,
then
this
signature
will
no
longer
be
valid
and
the
signing
party
will
reject
the
token.
A
So
how
sorry
the
receiving
party
will
reject
the
token.
So
what
does
that
actually
look
like,
so
the
party
receiving
the
token
will
follow
a
similar
process.
They'll
take
the
header
and
payload
values
and
they'll
also
use
this
shared
secret
key,
which
they've
established
somehow
beforehand
to
exchanged
with
the
other
party
and
then
they'll
find
the
unique
value
and
compare
it
to
this
signature
sent
in
since
these
signatures
match.
They'll
know
the
token
is
valid
and
they
can
proceed
safely.
A
Kind
of
the
downside
of
this
symmetric
signing
approach
here
is
that,
although
it
is
pretty
straightforward
using
the
shared
secret
key
establishing
that
shared
secret
key
is
a
little
bit
less
secure.
You
don't
know
who
all
has
access
to
it.
So,
since
the
person
validating
the
key
has
that
same
password
secret
key,
they
could
also
generate
tokens
that
would
be
seen
as
valid
and
if
there's
other
people
that
are
validating
those
those
tokens,
then
you
can't
actually
tell
who
it
came
from
since
the
key
is
distributed
due
to
this
I've
used
asymmetric
signing
more.
A
This
is
a
good
approach.
If
you've
got
a
bunch
of
micro
services
and
you've
got
one
service,
that's
only
focused
on
authentication.
You
don't
want
the
other
services
to
be
able
to
create
their
own
tokens
at
all.
So
asymmetric
signing
is
like
how
cryptocurrency,
while
it
works,
you've
got
a
private
key
and
a
public
key,
and
the
private
key
is
only
held
by
the
authentication
Service.
Meanwhile,
the
public
key
is
available
on
some
endpoint
for
anybody
to
access
it's
public
intentionally
and
can
be
used
to
validate
signatures
created
with
this
private
key.
A
So
here's
what
it
looks
like
to
actually
create
a
signature
for
a
Json
web
token
using
asymmetric
signing
once
again
we
take
the
header
and
payload
and
we
hash
them,
which
creates
a
unique
value.
Then,
since
we're
the
party,
that's
creating
this
token,
we
can
use
our
private
key
to
encrypt
that
unique
value
and
add
it
as
the
signature
when
somebody
receives
the
token
and
they
need
to
validate
it,
they
will
use
the
public
key
of
whoever
signs
that
token
to
decrypt.
That
third
section
of
the
token
the
signature.
A
This
will
reveal
what
the
person
that
created
the
token
says
the
unique
value
was,
and
then
they
can
compute
the
hash
of
the
header
and
payload
and
compare
them
to
make
sure
that
nothing
has
changed
due
to
the
nature
of
asymmetric
Keys.
Only
the
person
that
holds
that
private
key
would
be
able
to
generate
that
signature.
So
you
know
that
it's
valid.
A
So
what
does
this
look
like
in
practice?
This
is
a
super
simple
diagram
of
what
a
microservice
architecture
might
look
like.
You
can
see
on
the
left
here:
we've
got
the
authentication
Service
and
on
the
right
is
some
other
service.
Let's
say
it
sends
emails
or
something
it
could
really
do
anything
so
step
one.
The
clients,
the
laptop
down
there
will
log
into
the
authentication
Service
stay
with
the
username
and
password
the
authentication
Service
will
validate
that
username
and
password
and
then
create
the
token
for
that
client's
and
sign
it
with
their
private
key.
A
The
token
is,
then
sent
back
to
the
client
and
they
can
make
requests
to
the
email
service
for
whatever
feature
they
want
say
they
call
an
endpoint
to
send
an
email
they'll
send
along
that
token,
in
the
header
of
the
request
and
the
other
service
can
then
take
that
token
out
of
the
header.
Look
at
the
public
key
for
the
authentication
Service,
which
is
public
and
everybody
knows,
validate
the
signature
and
that
the
contents
of
the
token
haven't
changed,
validate
the
tokens
not
expired
and
then
finally
proceed
to
do
whatever
it
wants,
send
the
email.
A
So,
let's
break
that
down
into
an
algorithm.
So
what
we
did
there
was:
we've
separated
the
Json
web
token
into
its
three
segments,
header,
payload
and
signature,
we've
decoded
the
header
and
payload
and
checked
from
the
header
which
signature
algorithm
algorithm.
We
should
use
to
verify
the
token
then,
based
on
that
algorithm,
we've
verified
that
the
signed
hash
matches,
the
header
and
payload
the
hash
of
the
header
and
payload
of
the
token
that
we
received.
A
A
Well,
there's
one
fatal
flaw
in
here:
that's
actually
enabled
by
the
Json
web
token
specification
and
that's
step
three.
So
when
you're
validating
the
header
segments
of
the
Json
web
token,
the
RFC
actually
says
a
none
algorithm
is
valid
to
use.
So
what
this
means
is
whoever's
receiving
the
token
will
check
the
header
to
see
which
algorithm
they
should
use
to
validate
the
signature
and
in
the
case
of
none
that
means
don't
validate
this
token,
just
take
it
as
valid.
A
A
I'm
running
commands
in
the
terminal
here,
I'm
just
creating
a
header
here
with
the
none
algorithm
for
signing
the
token
and
base64
encoding.
It
then
I'm
creating
the
body
of
the
Json
web
token
setting
the
email
to
whatever
I
want,
in
this
case
admin
example.com
and
since
it's
not
being
validated
at
all.
The
service
accepts
that
as
correct
and
allows
me
to
proceed
as
admin
example.com,
so
yeah.
We
can
protect
against
this
by
going
off
the
spec
and
only
allowing
specific
signature.
Algorithms
that
we
accept
is
valid.
A
A
A
So
in
my
example,
here
I've
got
a
token
that
was
signed
using
a
symmetric
key.
It
was
a
really
short
one.
Sn1F
I
found
a
random
two
along
GitHub
called
shotcrack,
which
just
brute
forces
the
secret
key
used
to
sign
a
symmetric
key
signed.
Token
and
I
ran
it
here.
Against
this
token,
and
my
MacBook
was
able
to
crack
it
in
10
seconds.
A
So
once
a
party
has
access
to
your
secret
key,
they
can
use
any
legitimate
tool
like
job.io.
This
is
just
for
decoding
tokens
and
modifying
them
and
plug
in
that
secret
key
and
enter
whatever
whatever
information
they
want.
So
you
can
see
here
it
might
be
a
little
bit.
Small
I
set
my
name
to
admin,
example.com
and
I
plugged
in
that
secret
key,
and
it
was
valid.
So
anybody
that
passed
that
token
into
our
service
would
be
able
to
make
whatever
calls
they
wanted
as
an
admin.
A
The
protection
against
this
is
pretty
straightforward,
you're
just
going
to
want
to
use
a
sufficiently
long
secret
key
the
length
of
that
secret
key
varies
depending
on
what
signing
algorithm
you're,
using
kind
of
building
on
that
a
Less
Direct,
but
increasingly
common
attack.
That
I've
personally
seen
growing
in
the
wild
is
that
attackers
are
now
going
directly
after
tokens
rather
than
usernames
and
passwords.
A
If
you
have
a
username
and
password,
then
you
still
need
access
to
whatever
the
second
form
of
authentication
is
so
maybe
you
have
to
like
Sim
Jack
them
and
get
access
to
their
actual
phone
number
to
do
like
a
text,
verification
or
something
but
as
an
attacker.
If
you
can
get
access
to
the
tokens,
then
you
can
bypass
the
whole
initial
authentication
flow
and
just
make
requests
until
that
token
expires.
A
So,
if
you're
storing
the
Json
web
token
in
a
cookie
you're
going
to
want
to
make
sure
that
cookie
is
secure,
that
means
using
an
HTTP
only
cookie,
which
can
only
be
sent
or
sorry
HTT,
yeah
HTTP,
only
cookie,
which
can
only
be
accessed
when
sending
requests
it
can't
be
accessed
by
JavaScript,
which
means
no
malicious
scripts
in
the
browser
can
actually
access
that
cookie.
You're
also
going
to
want
to
make
sure
the
cookie
is
set
to
secure.
So
it's
only
sent
over
https.
A
The
other
option
is
to
actually
not
store
cookies
at
all.
This
means
just
keeping
the
Json
web
token
in
memory
while
running
your
application,
but
that's
a
little
bit
of
a
trade-off
for
user
experience,
because
if
they
refresh
the
page
they'll
log
back
in,
as
you
saw
in
both
the
signature,
algorithm
confusion
and
a
secret
brute
forcing
attacks,
the
most
important
thing
is
definitely
storing
your
keys
securely
that
you're
using
to
sign
these
tokens.
A
The
best
thing
to
do
is
to
store
the
key
in
a
place
that
it
can't
be
accessed
at
all,
like
an
Hardware,
signed,
Hardware
certificate
manager
or
something
like
that.
Like
AWS
HSM
I'd
recommend
something
like
AWS
Key
Management,
so
only
the
parties
that
are
expected
to
be
able
to
access
the
key
can
access
it
or
something
like
vaults.
So
that's
more
auditable.
A
Anybody
calling
in
to
access
your
keys.
You
can
see
who's
using
them
and
in
the
unfortunate
case
that
your
secret
key
actually
is
compromised,
it's
much
easier
to
roll
it.
It's
contained
only
in
one
place.
You
can
go
change
it
there,
rather
than
finding
everywhere.
The
secret
key
is
just
stored
in
the
environments
and
going
and
change
them
individually.
A
So
we've
gone
through
the
main
security
pitfalls,
but
I
think
another
common
Pitfall
that
I
wanted
to
point
out
was
making
sure
you're
actually
using
Json
web
tokens
in
a
way
that
makes
sense
so
Json
web
tokens
really
shine
in
a
distributed
environment.
They're
stateless,
which
means
you
don't
have
to
call
into
some
Central
authentication
Service
to
make
sure
they're
valid,
and
this
is
good
for.
If
you're
making
calls
to
many
like
distributed
systems,
they
don't
have
to
call
back
always
to
validate
the
token
they
know
the
public
key,
so
they
can
validate.
A
What
it
says
is
true.
This
will
reduce
their
Network
calls
reduce
latency,
and
it's
also
nice
just
to
be
able
to
assert
some
information
about
whoever's,
calling
your
service
by
checking
the
token
they
used,
but
you
might
not
even
need
a
Json
web
token.
So,
if
you're,
using
just
like
a
monolithic
or
simple
service,
then
session
tokens
might
still
be
enough
and
you
don't
need
to
worry
about
any
of
this
complicated
stuff
at
all.
A
So
that's
it.
We
have
the
base
knowledge
to
create,
verify
and
securely
work
with
Json
web
tokens.
You
can
go
forth
now
and
check
that
make
your
make
sure
that
your
libraries
are
actually
validating
Json
web
tokens
correctly
and
that
you're
creating
them
correctly.
Thanks
for
coming
out,
if
you'd
like
to
talk
with
me
about
tokens
at
all,
I'll
be
at
the
infra
booth.
At
the
conference
floor,
I'd
love
to
hear
from
you.
Thank
you.