►
From YouTube: IETF101-TUTORIAL-OAUTH-20180318-1230
Description
OAUTH TUTORIAL at IETF101
2018/03/18 1230
https://datatracker.ietf.org/meeting/101/proceedings/
A
I'd
like
to
welcome
you,
I'm
Karen,
O'donoghue
I'm,
with
the
education
team
here
at
the
IETF,
and
so
I've
got
two
purposes
here.
The
first
one
is
to
introduce
our
topic
and
speaker
today
and
the
second
one
is
to
solicit
your
input
and
comments
on
tutorials
that
you
would
find
useful
in
the
future
and
even
better
volunteers
to
provide
those
tutorials
we're
working
to
improve
our
education
program
and
we're
really
looking
for
feedback
on
that,
and
so
we'd
really
appreciate
that.
A
So
without
any
four,
oh
and
the
other
thing
is
I'm,
not
positive,
that
the
current
version
of
the
slides
that
are
uploaded
has
the
tutorial
the
survey
link
in
it,
but
there
will
be
a
version
uploaded
later
today
that
will
have
the
survey
link
in
it,
and
so
you
can
look
at
the
slides
and
then
click
on
the
survey
link
and
provide
brief
survey
feedback.
Alternatively,
you
could
also
email
to
the
edge
of
team,
and
that
will
do
it
as
well.
A
B
All
right,
thanks,
Karen,
all
right,
I'm,
a
little
bit
taller
than
Karen.
So
here
we
go
hi
everybody
and
good
afternoon.
My
name
is
Justin
richer,
I'm,
an
independent
consultant
working
out
of
Boston.
You
are
looking
at
the
entire
company
of
bespoke
engineering,
so
hello,
everybody
I've
done
a
lot
of
work
with
OAuth
over
the
last
bunch
of
years.
Here-
and
this
is
you
know,
for
IETF
101.
This
is
kind
of
an
OAuth
101
class,
there's
a
math
joke,
and
there
somewhere,
but
anyway,
I
have
done
this
course
a
bunch
of
different
times.
B
This
is
a
distilled
version
of
a
two-day
class
that
I
often
come
in
and
give
to
companies.
So
I'll
basically
sit
down
with
an
engineering
team
for
a
couple
of
days.
There's
a
lot
of
hands-on
exercises
and
stuff
like
that.
We
obviously
don't
have
that
much
time
to
get
into
a
super
ton
of
depth
here
in
the
next
hour,
because,
like
I
said
it's
a
two-day
like
a
full
2-day
class,
but
there's
a
lot
that
we
can
cover
that'll,
hopefully
give
you
guys
a
good
grounding.
B
The
code
for
all
of
the
exercises
is
open
source,
as
is
the
case
with
all
of
the
exercises
for
that
longer
version
of
today's
class
that
I
mentioned,
and
if
you
stick
around
to
the
end
of
class.
My
publisher
has
given
me
a
discount
code
on
this,
so
you
can
get
39%
off
yeah,
it's
a
weird,
arbitrary
value,
so
you
get
39%
off
if
you
go
through
the
publisher,
that's
for
both
the
e-book
and
the
the
printed
book.
So
if
you're
interested
in
that
come
grabbing
after
the
class
all
right.
B
B
B
All
right,
so
a
lot
of
people
look
at
oo,
often
they'll
say:
ok,
it's
you
know
it's
an
authentication
protocol
or
it's
an
authorization
protocol
or
it's
some
security
thing
that
lets
me
log
into
Facebook,
but
I,
don't
really
know
what
it
is.
I
just
know
that
I
see
it
all
over
the
place,
and
so
from
the
specification.
This
is
what
Oh
auth.
Is
everybody
got
that?
Well,
these
are
the
important
parts
you
know.
As
we
all
know,
this
is
the
IETF.
B
We
take
a
lot
of
words
to
say
something
very
simple,
but
do
so
very
specifically,
so
the
real
important
thing
here
is
that
it's
something
that
allows
a
third-party
application
to
get
limited
access
to
some
kind
of
service
on
behalf
of
somebody
who
we
call
the
resource
owner,
in
other
words,
Oh,
aww,
this',
fundamentally
not
really
an
authorization
or
authentication
protocol.
It
is
a
delegation.
Protocol
Oh
auth,
is
all
about
delegating
a
right
of
access
that
lets.
You
allow
a
piece
of
software,
allow
an
application
to
access
something
on
your
behalf.
B
So
fundamentally
that
is
the
design
and
goal
of
OAuth.
It's
not
about
authentication,
it's
not
about
authorization,
it's
about
delegating
a
right
of
security
Authority
and
that
fundamental
understanding
will
help
you
see
kind
of
where
our
fits
in
the
entire
sort
of
large
stack
of
security
protocols
out
there
in
in
kind
of
the
wider
world.
So
these
are
the
different
players
that
we
have
involved
and
I
realize
the
text
is
kind
of
small
on
that
slide.
Unfortunately,
it
does
get
shrink
down,
but
you've
got
access
to
the
PDFs.
B
If
you
want
to
see
these
and
I'll
point
these
out
as
well,
we've
got
a
resource
owner,
an
authorization,
server,
a
client
and
a
protected
resource.
Now,
all
of
these
words
mean
things
in
the
real
world,
but
they
mean
something
very
specific
in
the
OAuth
space,
so
the
resource
owner
is
an
entity
usually
a
person,
but
not
always
a
person.
It
could
be
sort
of
a
logical
entity,
but
usually
we're
gonna,
say
it's
a
person
that
they
have
access
to
some
resources,
a
P
I.
Now
that
could
be
a
resource.
B
That's
about
them,
and
often
it
is
so.
This
is
like
my
account
information.
My
time
line
my
photos,
whatever
kind
of
example
you
want
to
do,
or
it
could
just
be
something
that
I
just
have
access
to.
You
know
say:
I'm
working
in
HR
and
I
have
access
to
everybody's
time
card
information,
that's
a
resource
that
I
have
access
to,
even
though
it's
not
necessarily
about
me
specifically,
but
importantly,
what
makes
this
a
resource
owner
in
the
OAuth
world?
It's
not
just
that
they
have
access
to
it,
but
that
they
can
delegate
that
access.
B
So
this
is
the
entity
who
has
the
right
to
say
not
only.
This
is
something
that
I
do,
but
this
is
something
that
I
am
going
to
allow
somebody
else
to
do
as
well
and
in
general,
like
I,
said
they're
a
person
with
access
to
a
web
browser
and
for
simplification
purposes,
to
start
out
we're
going
to
assume
that
that
is
always
the
case.
We'll
go
into
the
exceptions
for
that
later
on
now,
the
protected
resource
is
an
API.
B
Now
this
can
be
any
flavor
of
API
that
you
want
really
authors
written
around
HTTP,
but
pretty
much
beyond
that.
It's
kind
of
it's
kind
of
up
to
you.
This
can
be
restful.
This
can
be
soapy.
This
can
be
any
new
kind
of
thing
that
hasn't
been
invented.
I
guess
the
kids
are
doing
Graff
api's
these
days.
It
really
doesn't
care
as
long
as
it's
an
HTTP
kind
of
resource
you
can
throw
off
at
it
and
it
works
pretty
well.
B
The
important
thing
is:
not
only
does
this
protect
things
for
the
resource
owner,
but
it
shares
things
when
the
resource
owner
says
to
do
so
now.
The
term
that
really
trips,
a
lot
of
people
up
is
client,
because,
if
you're
coming
from
any
type
of
web
programming,
you're,
probably
thinking
the
client
is
the
browser,
it's
not,
and
you
might
also
be
thinking
that
the
client
is
the
HTTP
client,
which
kind
of
is,
but
it
also
kind
of
isn't,
because
an
OAuth
HTTP
client
could
actually
be
a
sorry.
B
An
OAuth
client
could
in
fact
be
and
canonically
usually
is
an
HTTP
web
server.
So
in
the
OAuth
world,
when
we
say
client,
what
we
really
mean
is
whatever
piece
of
software
is
calling
that
API
that
protected
resource
that
we
were
just
looking
at
the
client
is
whatever
application
is
consuming.
That
API
now
that
doesn't
necessarily
mean
that
they're,
like
downloading
information,
they
could
be
purely
pushing
information
into
the
API,
but
they
are
still
the
client
of
the
API
and
for
OAuth
purposes.
B
B
This
is
fundamentally
the
problem
that
we're
trying
to
solve.
Like
I
said
it's
a
delegation
protocol
I
as
a
user
want
this
piece
of
software
to
go,
call
an
API
for
me
now.
This
is
a
really
old
problem.
We've
seen
this
a
lot
over
the
last
twenty
thirty
something
years
we've
been
trying
to
solve
this
for
a
very
long
time.
There's
a
lot
of
different
ways.
We
could
do
that.
B
One
of
the
things
that
you
see
a
lot,
especially
in
enterprise
spaces,
is
that
okay
I'm
the
client
application
so
I'm
gonna
have
you
log
in
to
me
and
then
I'm
gonna,
take
whatever
you
used
to
log
in
to
me.
Your
username
and
password
and
I'm
gonna
go
replay
those
at
some
API
and
pretend
to
be
you
to
go
talk
to
the
API.
This
works
really
great
in
enterprise
spaces.
Obviously,
there's
kind
of
a
big
problem
here
and
there's
a
couple
of
big
problems.
B
First
off
the
well
you've
got
somebody
stealing
your
keys,
so
you've
got
an
application.
That's
impersonating
you
going
off
on
the
other
side
and
when
that
request,
yeah,
that's
useless.
So
when
that
request
comes
into
the
protected
resource
in
a
case
like
this,
how
does
that
protect
a
resource?
Know
the
difference
between
me
logging
in
directly
as
a
user
or
a
piece
of
software
logging
in
to
do
something?
B
For
me,
it
doesn't
because
the
only
thing
in
this
model
that
the
protected
resource
can
tell
is
that
somebody
showed
up
with
the
username
and
password
and
that
maps
to
a
particular
account.
This
is
fully
impersonating
me
as
a
user,
which
means
that
this
client
application
can
do
anything
that
is
possible
on
that
API.
For
me,
whether
I
wanted
it
to
or
not,
there's
nothing
that
I
can
do
as
a
user
as
a
resource
owner
to
limit
that
access
and
say
I
want
to
turn
off
access
for
that.
Well,
pretty
much.
B
My
only
option
is
to
change
my
password
right.
That's
the
only
thing
I
can
do
to
stop
that
application,
and
the
thing
is
if
I'm,
in
an
enterprise
space
and
using
kind
of
single
passwords-
and
you
know,
you've-
got
a
big
active
directory
that
everything's
going
through
well
what's
gonna
happen
is
the
next
time
I
log
into
that
application.
It's
gonna
get
my
new
password
and
it
can
go
call
the
api's
for
me
again,
even
though
I
didn't
ask
it
to
so.
B
We're
really
stuck
with
a
lot
of
problems
here,
but
it's
it's
functional
and
it
works
a
lot
of
space.
One
of
the
biggest
problems
with
this,
though,
is
that
it
doesn't
work
if
that
protected
resource
and
that
client
don't
speak
to
the
same
account
so
say
I'm
logging
into
something
over
in
Google,
and
they
want
to
call
something
over
it.
Yahoo
my
passwords,
not
necessarily
gonna,
be
the
same
across
those
two
services.
You
can't
assume
that
they
will
be
so
when
you
can't
steal
the
keys,
just
ask
for
them.
We
see
this
all
the
time.
B
Don't
we
you
go
to
even
like
LinkedIn
today,
it
says,
give
me
the
username
and
password
for
your
email,
account
and
I
I'll,
be
really
good
and
only
download
your
contacts
and
not
do
all
of
the
other
wonderful
things
that
I
can
do
with
that
username
and
password.
So
this
is
really
has
a
lot
of
the
same
drawbacks
as
before,
but
it
does
have
the
benefit
of
this
now
works
across
domain.
The
biggest
drawback
to
this,
though,
is
that
it's
training
users
to
give
somebody
the
password
to
a
service.
B
Even
if
it's
not
directly
related-
and
this
can
be
a
bit
of
a
problem-
you
can
say
right.
So
what
this
means
is
that
now,
when
a
user
goes
to
an
attackers
website,
they
say
oh,
give
me
the
username
and
password
to
your
email,
account
and
I
promise.
I'll
be
really
nice
and
only
download
your
address
book,
they're
gonna
be
like
okay.
Well,
LinkedIn
did
it
and
nothing
bad
happened
and
Facebook?
B
Did
it
and
nothing
bad
happened
so
sure
I'm
gonna
go,
you
know
type
it
into
here
and
nothing
bad
will
happen
because
we're
training
users
to
do
exactly
the
wrong
behavior
in
treating
their
credentials
all
right.
So
what
if,
instead
of
using
the
users
password,
you
have
a
key,
that's
good
for
opening
any
door
that
it
comes
across
no
matter
who's
knocking,
and
this
is
a
pattern
we've
had
for
a
very
long
time.
We
call
this
an
API
key,
don't
we
so
the
user
shows
up
and
they
start
using
this
applications.
B
I
need
to
go
call
this
API
on
your
behalf,
but
instead
of
me
stealing,
your
password
I
have
a
super
powerful
password,
that's
just
gonna
show
up
and
it
doesn't
matter
which
user
I'm
asking
for
I
can
get
their
information.
Now
again,
this
is
really
functional
within
a
single
security
domain.
But
again
one
of
the
big
problems
here
is
that
it
can
go
access.
My
information,
this
application
could
go
access
information
without
any
input
for
me
without
any
even
action
for
me.
B
I
don't
even
have
to
log
into
this
application
for
it
to
be
able
to
trigger
that
it
can
just
go
pull
all
of
my
stuff
whenever
it
wants
to
whether
I
did
anything
here
or
not
and
again
this
doesn't
really
work
across
security
domains.
So
we
use
this
all
the
time
in
enterprise
spaces
even
today,
and
a
lot
of
web
api's
kind
of
use.
This
pattern
as
well,
but
there's
a
lot
of
downsides
to
it
as
well.
B
It's
also
a
bit
more
complicated
because
now
I
have
to
design
my
API
so
that
you
tell
me
what
user
you're
asking
for
and
I
need
to
be
able
to
input
that
and
I
have
to
fully
trust
you
to
always,
as
the
client
always
do
the
right
thing.
So,
let's
combine
a
couple
of
different
aspects
here
and
instead
of
a
universal
key,
that's
good
for
everything.
B
Let's,
let's
create
a
new
service,
specific
credential
call
it
a
token
and
for
my
account
as
the
resource
owner
I'm,
going
to
get
a
special
password
made
and
I'm
gonna
hand
that
to
the
client
application
so
that
it
can
call
the
protected
resource
from
my
behalf.
So
this
is
no
longer
my
regular
password
that
I
used
to
log
in
this
is
a
special
password
just
for
calling
this
API
and
we've
seen
this
all
over
the
place,
and
this
is
really
starting
to
get
closer
to
what
we
what
we
want,
but
it
has.
B
This
has
some
drawbacks
too.
So
on
the
up
side,
the
security
model
of
this
is
great,
because
that
token
maybe
I
say
this
token-
is
only
good
for
read
access.
Maybe
it's
only
good
for
an
hour,
but
it's
oh
end.
The
particular
resource
now
knows
the
difference
between
me
logging
in
and
this
client
logging
in
on
my
behalf,
because
it's
a
different
credential.
It
can
map
those
two
different
security
models.
That's
really
great
the
biggest
problem.
Here,
though,
the
usability
sucks.
It's
really
awful.
B
B
All
the
time
now,
our
developers-
this
is
people
like
us,
like
the
Nerds
of
the
Nerds-
are
still
screwing
up
the
usability
of
this,
because
it's
too
complicated
and
technical
that
should
tell
you
something
about
how
usable
this
is
would
be
for
an
average
user,
because
I
hate
to
break
it
to
you,
but
we
are
not
average
users.
We
need
to
remember
that
when
we're
designing
these
systems,
so
we're
getting
closer
here
and
really
what
I
think
the
answer
here
is
that
we
take
the
thing
with
the
good
security
practices
and
we
automate
it.
B
We
automate
it.
We
improve
the
usability
and
we
sort
of
make
that
part
better.
So
we're
gonna
do
that
with
a
little
protocol
called
OAuth
and
in
OAuth
you've
got
this
component
called
the
authorization
server
now
this
is
added
into
the
mix.
We've
still
got
the
resource
owner,
client
and
protected
resource
just
like
before,
but
we've
now
got
the
authorization
server
to
kind
of
bridge
the
gap
between
all
of
those
and
manage
this
connection.
B
This
generates
those
tokens,
those
service,
specific
credentials
that
I
talked
about
before,
like
this
is
a
special
password
for
this
piece
of
software
to
call
this
API
that's
generated
and
managed
by
the
authorization
server.
This
is
also
where
the
user
locks
in
where
they
say
yes,
this
software
can
go
do
this
thing
and
it
manages
all
of
those
authorizations
which
means
this
can
also
turn
them
off
or
say.
This
is
only
good
for
reading,
and
this
is
good
for
reading
and
writing
or
you
know,
whatever
other
things
you
need
in
your
API
design.
B
All
of
that
is
represented.
All
of
those
rights
are
represented
in
this
thing
called
the
OAuth
token,
specifically
the
OAuth
access
token.
This
is
a
representation
of
that
triangle
of
entities
so
from
the
resource
owner
to
the
client
for
the
protected
resource.
All
of
that
gets
bundled
up
into
the
token
and
it's
used
by
the
clients,
and
so
it
gets
issued
by
the
clients,
but
the
format's
actually
opaque
to
the
clients.
So
all
of
these
are
perfectly
valid.
B
Oauth
tokens
I
get
a
lot
of
questions
from
new
developers
like
what
does
it
auto
can
look
like
it's
kind
of
whatever
you
want
really
so
I
mean
the
first
one.
Here
is
just
a
hex
blob.
Second,
one
is
a
type
four
UUID,
so
that's
112
bits
of
entropy.
If
you
got
a
good
random
number
generator.
Third
one.
Does
anybody
recognize
what
that
third
one
is?
That
is
a
specific
format,
just
yell
it
out.
B
It
is
basics
before
you're
correct,
but
beyond
that
it
is
a
JWT,
a
JSON
web
token
will
get.
We
might
get
more
into
that
later
if
we've
got
time.
So
what
this
is
is
this
is
a
structured
format
that
is
basic
ste
for
URL
encoded
JSON,
with
a
signature
applied
to
it
in
a
sort
of
semi-detached
mechanism.
That's
the
hos,
a
suite
of
specifications
and
that's
another
tutorial
and
the
last
one
here
is
a
high
entropy
wordless
choice.
So
there's
four
random
words
I
think
that's
like
160,
something
bits
of
entropy.
B
Something
on
that
I'd
forget
the
funny
thing
about
this
is
that
these
are
generally
secrets
like.
This
are
generally
meant
to
be
human
memorise.
Abul
and
in
OAuth
token,
really
isn't
people
never
really
see
the
token?
So
why
would
you
ever
use
something
like
that,
because
you
can
ooofff
really
doesn't
care?
How
off
does
not
care?
What
the
token
looks
like
all
right,
so
whoops
forgot
to
check
ahead
on
my
slides
now.
B
I
have
a
question
who
here
has
used
OAuth
raised
just
raise
your
hand,
all
right
most
of
the
hands
went
up
so
who
here
has
ever
used
a
facebook
application
or
logged
into
a
site
with
Facebook
who
here's
ever
logged
into
anything
with
Google?
Who
here
has
ever
used
Spotify
yeah
Spotify
applications
who
here's
ever
used
steam
for
gaming?
Okay?
Who
here
has
a
smartphone?
B
Well
guess
what
you've
used
OAuth?
It
is
literally
everywhere
Oh
off
to
is
everywhere
on
the
web
these
days
and
like
a
good
security
protocol,
you
usually
don't
see
it
because
most
of
the
time,
it's
just
sitting
in
the
background
and
doing
its
job,
but
if
you've
ever
been
turning
on
a
new
application
or
connecting
you
know,
a
native
app
to
a
to
an
account
or
something
like
that
and
you've
seen
something
like
this.
B
This
type
of
approval
screen
that
says:
hey,
there's
the
thing
that
to
go
do
stuff
chances
are
you're
using
OAuth
and
if
you're,
not
using
OAuth,
you're,
probably
using
something
that
should
be
running
OAuth
but
thinks
they're
cleverer
than
the
ITF,
and
probably
has
some
big
security
holes,
which
has
an
independent
consultant.
If
you
find
one
of
those
call
me
because
that's
fun
work
all
right
now,
a
brief
history
of
OAuth
2.
Now
back
in
2006,
everybody
was
using
passwords
to
get
to
API
HTTP
basic
right.
B
If
anybody
hears
from
the
HTTP,
auth,
I'm,
sorry
I'm,
gonna
say
how
bad
eh
to
be
basic
is,
though,
you
probably
already
know
that
so
the
whole
idea
behind
h-2b
basic
was
that
you
know:
hey.
We've
got
this
great
web
protocol.
We
need
some
way
to
authenticate
it.
Let's
use
usernames
and
passwords,
because
we
use
that
for
everything
else.
Awesome
problem
here
is
that
that
allows
for,
and
it
really
kind
of
encourages
this
kind
of
impersonation
setup
like
we
were
talking
about
before,
and
so
it
was
really
all
about
the
you
know.
B
You
give
me
your
password,
I
promise,
I'll
be
nice
and
I
will
go.
Call
that
API
for
you
and
a
couple
of
Internet
companies
came
up
with
proprietary
solutions
for
delegated
access.
We
had
dbo
thoughts
of
and
a
handful
of
others,
and
and
also
remember
back
2006
was
12
years
ago,
but
remember
what
the
internet
looked
like
back
then
myspace
was
the
top
site,
the
iPhone
wasn't
out
yet
or
it
sort
of
came
out,
but
the
App
Store
wasn't
there
yet
so
imagine
a
smartphone
with
no
apps.
It's
really
weird
to
think
of
that
right.
B
Android
was
still
a
couple
years
off.
It
was.
The
internet
was
a
really
kind
of
different
place
12
years
ago,
and
so
back
then
we
had
a
couple
of
small
sites.
One
was
Magnolia,
a
start-up
which
has
since
evaporated
the
other.
Was
this
little
social
messaging
platform
called
Twitter
or
something
like
that
I
think
they're
still
around
they
got
together
and
they're
like
hey,
we've
got
a
cool
thing.
You've
got
a
cool
thing.
We
want
to
plug
our
cool
things
together.
Problem
is
that
they
were
both
looking
at
using
open
ID
for
login.
B
Now
open
ID
is
a
federated
identity
protocol,
not
the
topic
of
today's
conversation,
but
means
that
there
is
no
user
name/password.
So
to
get
to
the
Magnolia
API.
There
was
no
user
name
and
password
that
you
could
present
and
by
their
very
design,
federated
identity
protocols.
Don't
allow
you
to
replay
them.
That's
a
really
good
security
benefit,
so
neither
of
them
wanted
to
really
build
up
their
own
additional
proprietary
protocol.
So
they
thought
you
know
what
we're
gonna
get
together.
B
B
Conn
came
up
with
this
document,
published
it
out
on
the
web
and
said:
hey
here's
the
thing
and
that's
what
usually
happens
when
a
bunch
of
smart
nerds
get
together
in
a
back
room,
they
publish
it
and
almost
immediately
a
session
fixation
attack
was
found
in
the
baked
into
the
protocol,
and
the
inscrutably
named
Olaf.
100A
was
released
right
after
that
thing
is,
though,
this
actually
worked
pretty
well
and
pretty
soon
a
lot
of
people
started
to
use
it,
and
people
decided.
B
You
know
what
we're
going
to
kind
of
get
this
together
clean
up
the
language
a
little
bit
and
it
did
get
published
here
in
the
ITF
as
RFC
58
49.
So
people
start
using
this
thing.
It
solves
a
problem.
It
solves
a
very
real
problem
back
in
2006
2008,
this
time
frame,
the
sort
of
API
economy,
restful
design
of
API
is
all
this.
B
Other
stuff
was
really
starting
to
come
online
mobile
apps
we're
starting
to
maybe
look
like
they
might
be
a
thing,
and
so
this
solved
a
very
real
problem
that
people
had
in
a
way
that
was,
you,
know,
elegant
and
fairly
usable
for
most
cases,
so
much
so
that
in
something
that
usually
doesn't
happen
and
as
I'm
now
I'm
speaking
to
a
standards
group,
you
guys
know
this.
The
big
players
who
already
had
their
proprietary
solutions
said
you
know
what
we
don't
want
to
invest
in
our
proprietary
solution
anymore.
B
We're
just
going
to
use
this
standard
that
a
bunch
of
smart
nerds
came
up
with
instead
so
Google
and
Yahoo,
and
all
of
these
other
big
players,
and
eventually
you
know
Facebook
and
all
this
alongside
Twitter
and
others
decided.
You
know
what
we
are
going
to
use
this
ooofff
standard
instead
of
our
own
authorization
and
delegation
protocols,
and
that's
actually
a
really
cool
thing
and
it's
something
that
I
think
as
a
community
in
the
IETF.
We
need
to
study
more
how
that
happened,
because
that
doesn't
happen
nearly
often
enough.
B
Usually
the
open
standard
gets
put
on
the
shelf
right
next
to
all
of
the
proprietary
standards
that
everybody
else
needs
to
support.
So
anyway,
people
start
using
it
and
they
start
using
it
for
all
kinds
of
off-label
fun
stuff,
like
native
applications
that
started
to
become
a
thing.
It
didn't
start
out
as
a
thing
when
a
auth
was
originally
invented.
Suddenly
people
had
like
applications
on
their
phones
and
Google
came
up
with
some
really
interesting
ways
to
deal
with
this
in
the
OAuth
wanto
world.
B
Don't
have
time
to
get
into
the
details
right
now,
ping
me
after
if
you're.
If
you
want
the
details,
people
started
to
use
this
as
delegation
when
there
was
no
user
in
the
loop
which
doesn't
make
sense
because
it's
a
delegation
protocol,
but
people
realize
that
well,
I'm
I
can
delegate
rights
to
non
person,
users
and
entities
and
stuff
like
that.
So
I
want
to
use
this
to
be
able
to
replace
API
keys.
That
way,
my
user
facing
API
is
and
mine
on
user
facing
API
is
use
the
same
structure.
B
It's
a
lot
of
value
to
that
from
an
architecture
perspective,
so
they
started
to
use
OAuth
in
ways
that
it
was
never
intended
and
I
walk
made.
A
lot
of
assumptions
about
you
know
key
placement
and
wealth.
One
made
a
lot
of
assumptions
about
key
placement,
so
you
ended
up
with
people
distributing
it
in
ways
that
it
was
never
meant
to.
So
that
brings
us
to
version
2.0
and
like
with
any
second
version
of
the
system.
It's
no
longer
a
protocol.
B
It's
now
a
framework
because
that's
what
we
do
is
nerds
right,
but
in
all
honesty
it
was
chopped
up
in
a
very
deliberate
way.
So
Olaf
1.0
tried
to
solve
all
problems
for
all
use
cases.
All
in
one
go
o
auth
2.0
said
you
know
what
we're
gonna
look
at,
how
people
are
really
using
it
and
focus
on
those
specific
problems
and
we're
gonna
come
up
with
patterns
that
you
reuse.
B
All
of
these
components
in
this,
in
you
know
slightly
different
ways
so
that
we
can
actually
pull
this
stuff
together,
removed
a
lot
of
the
pain
points
like
a
proprietary
signing
mechanism
whatnot
and
that
got
standardized
in
RFC,
67,
49
and
67
50.
Already
it's
two
documents.
Instead
of
one,
you
can
see
it's
starting
to
be
modularized
more.
So
what
this
means
is
that
ooofff
two
is
not
really
a
single
protocol.
B
Although
the
Khitan
working
group
came
up
with
a
gssapi
extension
that
allows
you
to
do
it
over
lots
of
non
HTTP
protocols,
the
ACE
working
group
is
working
on
a
way
to
do
OAuth
over
co-op
it
coop.
Rather
it
is
not
both.
It
is
Oscar
they
renamed
it.
Do
you
guys,
remember:
okay,
I
left
a
bug
Francesco
about
this,
but
there's
a
version
of
OAuth
that
runs
over
co-op
for
co-op
and
core
for
sort
of
embedded
devices
kind
of
stuff
and
to
the
previous
point
about
what
Oh
auth
is,
it
is
not
an
authentication
protocol.
B
It
is
very
definitively
not
an
authentication
protocol,
it
relies
on
authentication,
so
the
user
has
to
authenticate
so
that
that
authorization
server
knows
who
everybody
is
and
whatnot
the
client
authenticates.
So
there's
authentication
all
through
it,
but
authentication
is
all
about
communicating
who
the
user
is
and
why
they're
there
and
how
sure
are
you
of
all
of
this
kind
of
stuff?
Well,
it
doesn't
do
any
of
that.
It
doesn't
communicate
any
of
that.
It
very
explicitly
stays
out
of
that.
B
However,
ooofff
gets
used
to
build
authentication
protocols
such
as
open
ID
connect,
which
is
built
on
top
of
OAuth,
and
so
people
using
Open,
ID
Connect
think
they're
just
using
OAuth,
where
in
fact,
they're
using
OAuth
plus
a
couple
of
key
components
that
makes
it
into
an
authentication
protocol.
Excuse
me,
our
authors,
about
user
software
delegation,
not
user
to
user
delegation.
B
If
you
want
that,
you
need
to
add
a
few
more
components:
the
there's
one
standard
out
there
user
manage
to
access
or
uma
that
allows
you
to
do
that
again,
built
on
top
of
OAuth
or
auth,
doesn't
give
you
authorization
processing.
This
really
isn't
like
sam'l.
Sorry,
not
sandals.
A
camel
it's
also
not
like
sam'l
in
that
there's
not
a
way
to
describe.
Oh
when
you
get
this,
here's
how
you
process
it
and
here's
these
rules
to
apply
and
stuff
like
that.
B
No
authors
really
just
about
carrying
that
handle
from
one
end
to
the
other
and
what
you
do
with
that
handle
ooofff,
doesn't
care
what
you
do
with
that
token.
In
order
to
interpret
it,
ooofff
really
doesn't
care.
There
are
lots
of
standard
methods
defined
and
how
you
do
that,
but
those
really
aren't
a
lot.
B
They're
added
on
to
oauth,
like
you
said
before,
o
auth
doesn't
have
a
token
format,
but
it
needs
to
have
a
format
that
both
the
authorization,
server
and
protected
resources
can
make
sense
of,
even
if
it's
opaque
to
the
client,
it's
not
necessarily
opaque
to
everybody
in
the
system.
So
there
are
token
formats
JSON
web
token
or
John
is
one
of
the
most
popular
ones
out
there
and
it's
a
useful
common
format
and
OAuth
doesn't
define
its
own
cryptographic
methods.
B
So,
in
order
to
avoid
all
of
that
o
auth,
you
said
you
know
what
we're
not
getting
into
the
signature
game,
at
least
in
the
base
protocol,
so
use
TLS
for
everything
and
go
from
there
and,
like
we
said
before,
it's
not
a
single
protocol.
I'm
not
gonna,
reiterate
that
all
right
deep
breath
we're
halfway
through
how's
everybody
doing
good
all
right.
Everybody
checking
your
email
awesome
now,
I've
been
to
these
tutorials
I
know
how
it
works,
and
so
we
are
now
going
to
dive
deep
into
the
canonical
flow
of
OAuth
2.0.
B
This
is
the
authorization
code
flow.
These
are
all
the
pieces
and
this
is
what
it
looks
like.
Alright,
everybody
got
that
awesome
before
we
get
into
the
details
of
what
that
diagram
looks
like
you
need
to
understand.
That
makes
use
of
two
different
kinds
of
communication.
It
is
an
HTTP
based
protocol,
so
first
off
we
have
the
back-channel.
This
is
just
straight
up.
Http
calls
you
make
an
HTTP
request,
getting
HTTP
response.
That
means
that
we've
got
headers.
We've
got
the
body
content,
we've
got.
B
You
know
different
URI
parameters
and
stuff,
like
that
different
HTTP
verbs
that
we
can
use
really
really
rich
messaging
system
and
it's
directly
between
two
components
so
between
the
client
and
the
auth
server,
the
client
and
the
protected
resource.
This
is
where
we're
gonna
stuff
sort
of
like
the
really
secret
things
that
we
care
about,
like
those
tokens
that
we
were
talking
about
before
this
is
where
they
like
to
live
in
the
back
channel
talking
directly
between
components.
B
The
client
is
gonna
say
like
oh
I'm.
Here,
on
behalf
of
this
user
and
the
authorization
server
well,
how
does
it
know
that
the
user
is
even
involved
in
that
process
used
to
be?
We
knew
because
the
user
gave
their
password
to
the
client
or
presumably
gave
their
password
to
the
call
to
the
client.
Those
were
scare
quotes
anybody
only
listening
to
the
audio
audio
stream,
and
in
that
case
the
clients
really
just
impersonating
the
user.
So
you
know
off
what
we
do
is
we
use
the
front
channel.
B
B
What
it
means
is
that,
in
order
for
the
client
to
send
a
message
to
the
authorization
server
through
the
front
channel,
it
sends
a
redirect
to
the
users
browser
to
a
very
specific
URL,
that
URL
is
hosted
at
the
authorization
server
and
it's
got
a
bunch
of
query
parameters
on
it
that
are
set
by
the
client.
Now
that
redirect
goes
to
the
browser
and
then
the
browser,
not
the
client,
makes
the
HTTP
request
back
to
the
authorization
server.
That
means
we
now
have
an
HTTP
channel
between
the
resource
owner
and
the
authorization
server.
B
The
client
is
not
part
of
that
which
means
that
the
resource
owner
they
can
now
authenticate.
We
can
do
you,
know
all
sorts
of
session
mapping
and
heuristic
evaluation
of
security,
and
all
of
that
other
good
stuff
that
we
like
to
do
on
interactive
HTTP
sessions
without
involving
the
client
directly.
So
none
of
that
leads
to
the
client.
That's
all
really
great.
It
also
means
that,
now
that
we
are
between
the
browser
and
the
authorization
server,
we
can
do
multiple
requests.
B
You
know
we
can
redirect
internally,
we
can
go
to
off
to
other
sites
and
then
come
back
and
all
this
other
stuff.
Now,
how
does
the
authorization
server
get
any
messages
from
the
client
in
this?
If
they're
coming
from
the
browser?
Well,
that
URL,
that
the
client
redirected
us
to
has
a
bunch
of
query
parameters
on
it
that
have
values
on
those
query,
parameters
that
are
then
received
and
interpreted
by
the
authorization
server,
so
you're
not
just
going
to
a
fixed
URL
you're,
going
to
a
URL
with
a
bunch
of
parameters.
B
B
What
that
you
redirect
looks
like
varies
depending
on
the
kind
of
client
in
the
canonical
case,
where
we're
talking
about
we've
got
two
websites
that
are
talking
to
each
other.
Well,
that's
going
to
be
just
an
HTTP
URL
that
has
a
bunch
of
query
parameters
on
it
that
are
act
as
the
response
to
that
front.
Channel
request
all
right.
We
do
this
in
order
to
separate
the
information
we
use
the
front
channel
when
the
users
involved
in
the
back
channel
as
much
as
possible
wherever
the
users
not
directly
involved.
B
The
front
channel
is
going
through
a
third
component.
It's
going
through
the
browser.
We
can't
always
trust
it
to
do
to
make
sure
that
messages
always
get
through
exactly
how
we
want
to
because
they
can
be
sort
of.
You
know
snooped
and
modified,
that
is
assumed
in
the
OAuth
protocol,
and
there
are
protections
in
the
OAuth
protocol
to
mitigate
that
type
of
stuff,
but
we
use
the
back
channel
for
all
the
secret
things
as
much
as
we
can
so
now.
We're
gonna
go
step
by
step
through
that
crazy
diagram.
B
Alright,
first
off
user
shows
up
the
client
and
says
I
want
you
to
use
that
protected
resource,
and
the
client
says
I
can't
do
that.
I!
Need
you
to
go.
Get
me
permission
before.
I
can
go.
Do
that
right,
whereas
in
the
past
the
client
would
just
say
great.
Give
me
your
password
and
I
promise.
I'll
be
nice.
Now
the
client
says
all
right
go
talk
to
this
other
server
and
they'll
come
up
with
something
that
can
that
I
can
use,
so
just
just
go
over.
B
There
do
what
they
say
and
come
back,
so
we
send
an
HTTP
front
channel
responds
we
send
a
redirect
to
the
browser,
and
then
the
user
goes
and
talks
to
the
auth
server.
Now,
at
this
point,
the
user
can
authenticate
to
the
auth
server,
whereas
previously
we
were
stuck
with
credentials
that
had
to
be
copyable
like
passwords,
we
can
now
do
multi-factor
authentication.
We
can
do
you
know
massive
risk
based
engines
like
most
of
the
large
internet
providers.
Do
today.
B
You
know
you
can
do
pretty
much
whatever
you
want
between
the
user
and
the
off
server
and
it's
a
very
rich
channel
of
communication,
because
it's
the
web
right,
so
the
user
authenticates.
So
the
all
server
now
knows
who
the
user
is,
and
they
all
server
knows
who
the
client
claims
to
be
because
of
those
query
parameters
that
were
in
that
redirect.
So
we
can
now
say
like
ok,
so
it
looks
like
this
client
is
asking
to
do.
B
These
things
is
that,
ok
with
you
now
back
when
we
were
just
asking
for
for
somebody's
password
or
just
stealing
their
password
on
the
way
through,
we
didn't
have
any
way
to
ask
the
user.
If
this
is
what
they
are
trying
to
do,
we
now
have
a
place
where
we
can
ask
the
user
the
resource
owner.
Is
this
your
intent?
Are
you
actually
trying
to
get
this
client
to
go
talk
to
this
resource
server?
You
know.
Do
you
really
want
to
log
into
farmville,
with
your
Facebook
account?
B
Is
that
what
you
meant
to
do
today,
and
it
seems
funny
to
give
that
kind
of
control
to
an
end
user,
especially
to
a
lot
of
security,
architects,
but
think
about
it
in
terms
of
KU,
is
in
the
best
position
to
know
what
they
are
trying
to
do?
It's
the
user.
They
know
what
they're
trying
to
accomplish.
They
may
not
know
what
they're
really
doing,
but
they
know
what
they're
trying
to
accomplish.
B
So
this
is
an
area
of
active
research
of
how
to
best,
communicate
this
decision
and
gather
this
consent
and
a
lot
of
work
that
I
do
is
kind
of
in
this
space.
I
could
rant
about
that
for
several
hours.
I
won't,
but
ping
me
after.
If,
if
you
want
that
point
here
is
that
we
can
ask
the
user,
did
you
mean
to
do
this?
B
Do
you
approve,
if
you
do
approve
you
send
back
this
thing
called
the
authorization
code
now
that
authorization
code
is
a
temporary
retention
drawn
here's
a
little
paper
carnival
ticket
that
gets
sent
back
to
the
client?
How
does
it
get
sent
back
through
a
redirect
through
the
front
channel
just
like
we
were
talking
about
before
it's
query
parameter
through
the
browser?
The
browser
makes
a
request
to
the
client
and
that
gets
sent
back
there.
B
So
now
the
client
has
everything
that
it
needs
to
go
talk
to
the
authorization
server
and
get
the
real
credential
that
paper
ticket
really
isn't
good
for
accessing
the
protected
resource.
It's
not
meant
for
that.
What
it's
meant
for
is
the
client
to
then
turn
around
and
then
talk
directly
to
the
authorization
server
in
the
back
channel.
At
this
point,
though,
the
client
can
now
authenticate
itself.
It
can
now
prove
that
yes,
I
am
the
piece
of
software
that
was
making
that
original
request,
and
there
are
a
few
different
ways
to
pull
this
off.
B
B
Yes,
this
is
OK
we're
good
with
them.
In
a
nutshell,
that's
how
OAuth
works
it's
about
delegating
that
access
and
going
through
this,
so
that
you
get
that
token
to
the
client
so
that
it
can
call
the
protected
resource.
Now
there
are
a
bunch
of
things
that
have
been
added
to
OAuth
or
sort
of
built
into
OAuth
that
allow
this
to
work
in
less
than
idealized
situations
that
we
call
the
real
world,
and
one
of
those
is
this
concept
called
a
refresh
token.
B
So
far,
we've
been
talking
about
a
thing
called
an
access
token
access
tokens.
Once
the
users
said:
ok,
they
keep
working,
the
user
can
log
off
of
the
client
they
can
wander
away,
they
can
get
eaten
by
an
alligator.
Doesn't
matter,
ooofff
doesn't
care.
What
our
cares
about
is
that
that
access
token
is
still
good,
so
the
clients
going
to
keep
using
that
access
token.
B
As
long
as
it's
good-
and
this
is
a
key
design
point
so
auth
is
designed
to
work
when
the
user
isn't
there,
and
it's
also
designed
to
deal
with
the
situation
like
well.
When
does
that
access
tokens
tokens
stop
working?
Maybe
it
expires,
maybe
the
user
wasn't
eaten
by
an
alligator,
but
they
logged
into
the
authorization
server
and
said
you
know
what
I
don't
like
that
app
accessing
my
stuff
anymore.
I
want
to
revoke
access
to
that,
so
that
access
tokens
gonna
stop
working.
So
what
does
the
client
do
then?
A
B
One
of
the
best
ways
to
do
this
is
to
not
have
complex
if-then-else
code
paths
for
error
handling.
If
you
get
into
this
place,
like
you
always
assume
that
your
token
might
not
work
and
if
your
token
doesn't
work,
ok,
maybe
go
try
to
get
a
new
token,
which
is
great
if
your
users
still
there.
But
if
you
use
your
has
in
fact
wandered
off,
you
can't
ask
them
right
away,
and
you
can't
call
that
API
again.
B
What
do
you
do
then?
Well,
there's
a
construct
called
a
refresh
token,
and
what
that
means
is
that
the
Refresh
token
is
something
that
you
get
alongside
the
access
token:
it's
not
good
for
calling
api's,
it's
not
good
for
getting.
You
know
getting
the
data
to
the
client.
What
it
is
good
for
is
saying
that
I
have
proof
that
the
user
said
that
it
was
ok
to
use
this
API,
but
my
access
token
isn't
good
anymore.
So
give
me
a
new
access
token,
so
that
I
can
keep
calling
the
API
without
bugging
the
user.
B
This
way,
your
access
token
can
live
for
maybe
a
couple
minutes.
So
it's
just
kind
of
sitting
out
on
the
wire
for
a
few
minutes
app
goes
to
sleep
whatever.
It's
not
calling
the
API
anymore
access
token
times
out
app
wakes
up.
You
know
couple
days
later
and
says:
I
need
to
go
refresh
that
API
access,
token
isn't
good
anymore,
but
I
have
a
refresh
token.
I
have
a
refresh
token
that
allows
me
to
go
and
get
a
new
access
token,
and
that
refresh
token
basically
says
hey.
B
You
know
the
user
said
this
was
okay,
unlike
the
access
token,
which
is
a
bearer
credential,
at
least
in
its
most
basic
format.
Refresh
token
is
not
refresh
token
has
to
be
presented
alongside
the
clients
credentials.
Just
like
that
authorization
code
we
saw
before,
and
it's
only
presented
in
the
back-channel.
It
only
ever
lives
between
the
client
and
the
authorization
server,
so
protected
resources
never
see.
B
All
right,
another
concept,
that's
built
into
OAuth,
is
what
I'm
calling
the
safety
I.
Maybe
I
don't
want
my
API
to
be
all
or
nothing
so
back
in
the
day
when
it
was
just
username
and
password.
If
I
had
the
username
and
password
I
could
do
anything
I
wanted
to
on
the
API,
because
it
was
the
whole
API
it
was
on
or
off,
but
now
that
I've
got
this
delegated
token.
I
can
probably
do
a
better
job
at
splitting
that
up,
so
we
use
the
concept
in
OAuth
of
a
scope
of
that
token.
B
Now
the
scope
of
the
token
is
used
to
represent
a
lot
of
different
concepts,
most
commonly
it's.
The
type
of
thing
you're
allowed
to
do
am
I
allowed
to
read
this
API
am
I
allowed
to
write
to
this
API.
You
know
what
kinds
of
things
also
you
often
see
the
kind
of
thing
that
you're
allowed
to
make
actions
on
so
am
I
allowed
to
get
your
timeline,
your
profile
information,
the
metadata
of
your
attributes
versus
the
attribute
values
themselves.
B
What
am
I
allowed
to
do,
and
occasionally
it
also
means,
when
you
can
do
this,
you
know,
can
I
do
this
when
the
users
not
logged
into
that
main
service
anymore,
can
I
do
this
only
when
they're
online
can
I
do
this
only
on
Tuesdays
at
2:00
p.m.
right.
What
are
my
different
options?
Oh,
mideco
I
think
our
camera
fell
asleep.
Just
FYI.
B
B
B
Yeah
I
think
me.
That
goes
still
down
all
right
all
right.
So
far
we
have
looked
at
the
authorization
code
flow
and
kind
of
the
basics
of
how
it
works.
Fundamentally,
it's
the
delegation
protocol.
It's
all
about
a
user
saying
this.
Software
can
do
it
in
the
world
that
oweth
was
originally
designed
for
I.
Think
we're
waking
up
yay,
thank
you
me,
deco
and
in
the
world
that
Olaf
was
originally
designed
for
it
was
all
about.
B
B
It
would
be
really
nice
to
use
this
security
layer
that
we
invented
across
all
of
those
things
and
in
fact
that's
what
happened
with
OAuth
1,
which
was
never
intended
to
solve
all
of
those
cases,
but
it
was
kind
of
used
for
that
anyway,
because
it
almost
solved
people's
problems
and
they
just
kind
of
hammered
it
into.
You
know
the
square
peg
into
the
round
hole
to
make
it
fit
with
OAuth
2.
B
Instead
of
giving
everybody
a
square
peg,
we
gave
you
a
way
to
make
your
own
custom
shaped
pegs
with
a
couple
of
patterns
that
are
fairly
common.
I'm
way.
Stretching
this
metaphor,
so
this
canonical
use
is
all
about
server
talking
to
another
server,
a
web
server
talking
to
an
API.
Those
types
of
systems
have
particular
aspects.
For
example,
a
web
server
can
keep
secrets
from
the
users.
That's
not
true,
with
an
in-browser
application,
because
anything
that's
running
in
your
browser,
you
can
inspect
it.
It's
not.
B
I
will
say,
though,
that
if
you're
learning,
if
you're,
just
learning
OAuth
to
start
with
the
authorization
code
flow
for
two
reasons,
one,
it
really
is
the
most
robust
and
the
most
widely
used
version
of
OAuth
2.
It
solves
the
widest
set
of
different
use
cases
and
two-
and
you
know-
and
it
really
should
be
your
default
based
on
that
and
to
everything
else.
B
That
I'm
about
to
talk
about
here
is
an
optimization
of
the
authorization
code
flow
for
different
specific
purposes,
and
every
time
you
have
an
optimization,
you
have
to
make
assumptions
about
what
you're
optimizing
for
all
right
means:
you're,
making
assumptions
about
the
environment
that
you're
in
you're,
making
assumptions
about
the
clients
and
the
users
in
the
api's.
Everything
that
I'm
gonna
talk
about
in
the
next
few
slides
here
is
gonna,
really
be
for
specific
environments
and
circumstances.
B
The
implicit
flow
is
what
happens
when
you
shove
the
client
up
inside
the
browser.
Now
the
authorization
code
flow
goes
through
a
lot
of
different
steps
to
make
sure
that
things
like
the
client's
credentials
and
the
clients
like
identity
and
authorization,
never
leaks
to
the
end-user
that
the
access
tokens
aren't
exposed
to
the
browser
and
all
of
this
other
stuff.
But
what
if
your
application
is
running
literally
inside
your
browser?
It's
a
JavaScript
application
that
is
executing
inside
the
browser
at
runtime.
B
All
of
that
stuff
that
you've
done
all
of
those
hoops
that
you've
just
jumped
through
to
make
sure
all
of
that
stuff
is
secret
from
the
browser
really
doesn't
apply
anymore,
because
it's
all
in
the
browser,
it's
all
in
there,
and
so
the
implicit
flow
in
order
to
get
the
access.
Token
is
really
a
front
channel
only
flow.
B
So
what
you
can
do
is
you
send
the
user
over
and
instead
of
coming
back
with
an
authorization
code
that
you
then
go
and
repost
and
then
get
the
token
you
send
the
user
over
and
they
come
back
directly
with
an
access.
Token
and
herein
lies
the
trouble
because
that's
great
for
an
in-browser
web
application,
because
now
now
you're
bound
by
same
origin
policies,
and
it
comes
back
as
the
HTTP
URL
fragment.
So
you
know
it
doesn't
depending
on
your
browser.
Thank
you,
google.
B
It
usually
doesn't
get
sent
across
redirects
or
posted
back
to
servers,
or
things
like
that.
So
it
supposed
to
stay
nice
and
inside
the
browser
doesn't
always
these
days,
which
is
fun,
but
if
you're
using
this,
the
implicit
flow
in
any
other
kind
of
application,
you're
breaking
all
of
the
assumptions
that
that
went
into
it.
So
this
is
the
biggest
problem
I
have
with
the
implicit
flow,
not
that
not
its
design
in
and
of
itself,
because
for
an
in-browser
app,
it
works
pretty.
Well,
we
didn't
have
HTTP
POST
message
when
this
came
out
these
days.
B
We'd
probably
use
that
instead
right,
but
a
lot
of
people
see
this
and
they
say
you
know
what
this
is
simpler.
This
is
easier
and
I.
Don't
know
why
I'm
doing
all
these
redirects
and
HTTP
calls
on
this
off
code,
and
all
this
other
stuff,
like
that,
I'm
just
gonna,
do
the
implicit
flow
until
something
breaks
and
then
then
I'll
go
figure
out.
B
What
this
whole
thing
is
I
see
this
time
and
time
again,
and
this
mistake
has
been
at
the
core
of
a
number
of
very
large-scale
attacks,
including
one
that
that
did
a
lot
of
damage
to
espn.com
again
more
details
on
that.
After
the
talk,
if
anybody
wants
to
ping
me
about
it,
the
problem
is
that
that's
the
simplicity
of
the
implicit
flow
comes
at
the
cost
of
assuming
that
everything
is
going
to
stay
right
inside
this
little
box.
B
Those
assumptions
go
completely
out
the
door
when
you're
using
a
native
application
when
you're
using
a
web
server
based
application
or
really
anything
else
other
than
something
living
directly
and
completely
inside
the
browser,
and
in
order
to
encourage
people
to
use
this
correctly,
when
we
wrote
alt,
we
made
sure
that
you
can't
get
a
refresh
token
here.
Well,
why
not?
B
Because
well,
if
the
users
there
in
the
browser,
you
can
just
send
the
back
and
go
get
a
new
access
token,
because
they're
still
there,
but
you
know
a
lot
of
people
we're
using,
will
start
using
the
implicit
flow
in
other
types
of
client,
apps
and
say:
well:
okay,
my
user
went
away,
and
now
I
need
a
refresh
token.
How
do
I
get
that?
So,
even
though
we
tried
to
design
that
into
the
protocol,
people
it
didn't
quite
sink
in
and
so
I
really
can't
recommend
the
implicit
flow.
B
Unless
you
are
very
much
in
this
very
tight
constraint
right
now,
the
client
credentials
flow
is
another
fun
one,
because
you
take
the
four
parties
of
the
author
of
the
authorization
code
flow,
except
that
you
kind
of
take
the
resource
owner
and
conceptually
squish
them
down
into
the
client.
The
whole
idea
between
that
for
this
is
that
well
I'm
really
kind
of
solving
the
API
key
use
case.
Now,
at
the
beginning
of
the
talk,
we
talked
about
how
people
use
API
keys,
to
say,
like
I,
am
here
on
behalf
of
this
one
specific
user.
B
B
B
The
client
credentials
flowing
ooofff
simplifies
that,
because
now
the
client
takes
its
credential.
That
represents
itself
and
it
goes
and
talks
to
the
authorization
server
and
gets
back
a
plain
old
access.
Token.
Then
he
uses
that
access
token
to
call
the
protected
resource.
Now
that
client
is
not
going
to
get
again,
it's
not
going
to
get
a
refresh
token
because
it
can
just
go
get
a
new
token
anytime.
It
needs
to
because
it
has
its
own
credentials.
B
It's
not
on
behalf
of
a
user,
so
there's
no
user
to
go
bother
and
that
access
token
can
then
be
used
for
all
of
these
different
protected
resources.
But
the
protected
resource
never
needs
to
know
the
clients
credentials
right.
I've
only
got
like
five
minutes
left,
so
I'm
gonna
burn
through
this
next
up,
one
of
my
personal
favorites,
the
resource
owner
password
flow.
This
is
all
about
stealing
the
password.
This
is
the
client
saying
give
me
your
password
and
I'll
go
call
an
API
and
I
promise.
I'll,
be
nice
now
hold
on
a
sec.
B
We
said
that
this
was
really
bad
and
it
is
so
don't
use
this
one,
but
I'm
still
gonna
tell
you
how
to
do
it,
so
you
know
not
to
use
it.
That
makes
sense,
which
is
why
we
specified
it.
Basically,
when
you
get
the
users
password
instead
of
calling
all
of
the
api's,
you
call
the
authorization
server
and
get
an
access
token
and
then
call
the
protected
resources.
Now
your
protected
resources
don't
need
to
know
the
users
password.
They
just
need
to
be
able
to
understand
Oh
auth
access
tokens.
B
B
So
that's
a
really
bad
thing.
The
assertion
flows,
if
you're
talking
to
Microsoft
you
care
about
this.
Otherwise
the
device
flow
is
all
about
a
limited
access.
Client
we're
seeing
a
lot
more
of
these
days.
So
this
is
not
in
the
core
ooofff
specifications.
This
is,
in
an
extension,
that's
working
its
way
through
the
working
group
right
now.
B
The
whole
idea
here
is
that
your
device
starts
an
OAuth
process
and
then
it
gives
you
a
random,
a
random
code
from
the
authorization
server
that
you
then
go
and
plug
in
using
another
device
if
you've
ever
used
a
set-top
box
to
like
connect
to
Yahoo
or
something
like
that,
this
is
what
you're
doing
you're
actually
participating
in
an
OAuth
dance
with
multiple
devices.
So
what
happens?
Is
you
type
in
that
code
to
the
authorization
server
or
you?
You
know,
scan
a
generated
barcode
or
anything
like
that.
B
The
authorization
server
says:
hey
I've
got
a
request
that
was
waiting
for
this
I'm.
Now
gonna
bind
it
to
your
account
and
I'm
gonna.
Send
you
across
and
give
you
an
access
token.
At
the
end
of
all
of
those,
you
get
an
access
token,
and
all
of
your
protected
resources
speak.
Those
now
native
clients
very
quickly
are
things
that
are
running
on
your
devices.
Stuff,
that's
running
on
your
phone
on
your
laptop
stuff,
like
that
they
functionally
live
outside
the
browser,
so
this
is
a
different
world.
B
So,
instead
of
accessing
the
content
through
your
system
browser
you're
working
directly
with
an
application.
Alright,
that
means
really
two
things:
one.
You
got
to
deal
with
secrets
and
two
you
got
to
be
able
to
get
information
back
in
the
front
Channel
now
dealing
with
Secrets
is
really
kind
of
a
problem,
because
a
native
application
isn't
very
good
at
keeping
a
secret
from
the
user.
His
user
can
always
poke
in
any
buddy
in
this
room
could
go
and
poke
in
and
figure
out.
What
secrets
are
there?
B
Which
means
that
if
you
have
the
same
application
installed
on
a
thousand
different
devices
and
you've
got
the
same
secret?
It's
not
really
a
secret
anymore,
o
auth,
one
assumed
that
it
always
would
be,
which
was
a
mistake
in
OAuth
2.
We
said
you
know
what
don't
pretend
anymore,
that
that's
a
secret,
so
you
can
either
use
dynamic,
client
registration
to
give
every
instance
a
new
secret,
which
is
an
extension
OAuth
or
you
can
use
a
public
client
which
doesn't
have
a
secret.
B
Now,
how
do
we
protect
those
oops
I
put
these
in
a
weird
order.
Sorry,
when
I
trim
down
the
slides
it's
a
lot
of
my
transitions
are
what
got
cut
now
to
deal
with
that
secret
and
said
we
can
use
this
thing
called
pixie
now
pixie,
oh
I,
remember
why
I
did
this
in
this
order
right
so
plot,
some
Pixies
in
a
moment.
How
do
you
get
information
back
to
the
client
in
the
first
place?
Well,
you
need
a
redirect
URI
if
you're
running
a
web
server.
That's
awesome!
It's
just
HTTP!
B
B
These
days,
you
can
have
some
sort
of
locally
hosted
random
web
server,
Google's
starting
to
do
this
more
on
their
apps,
and
you
can
have
a
remote
host
with
either
push
notification
or
remote
URL
capture
on
native
device,
not
going
to
go
into
detail
how
these
work
they're
all
platforms,
specific
the
TLDR
version-
is
that
there
are
ways
to
get
information
back
to
a
non
HTTP
server
using
using
OAuth
today.
Now
the
problem
with
those
custom
schemes
is
that
on
today's
platforms,
anybody
can
register
for
any
scheme.
It's
just
you
pop
up.
B
You
say:
hi
I'm,
an
app
I
want
this.
One
and
system
says
okay,
so
combine
those
two
aspects:
the
fact
that
anybody
can
get
any
scheme
and
the
and
the
client
no
longer
has
a
secret
to
authenticate
the
instance.
You
come
up
with
the
world
where
pixie
starts
to
make
sense,
now,
pixie
proof
key
for
code
exchange
very
shortly.
The
client
generates
a
secret
hashes.
It
sends
the
hash
to
the
authorization
server
in
the
front.
Channel
authorization
channel
does
its
notarization
server.
B
Does
this
normal
dance
sends
you
back
the
authorization
code,
then,
when
you
send
back
the
authorization
code,
you
send
the
non
hash
secret
along
side
of
it
to
prove
that
you
were
the
one
that
made
that
initial
request.
This
allows
you
to
tie
in
to
that
transaction
without
having
a
unique
identity
for
the
client.
In
other
words,
you
don't
need
the
client
credentials
to
get
a
similar
level,
not
quite
the
same,
but
a
similar
level
of
security.
B
Here
you
can
verify
the
challenge
here,
because
you
now
have
the
native
you've
saved
the
hash
from
before
you
regenerate
the
hash
and
you're
good
to
go
all
right.
There
are
lots
of
different
use
cases
for
all
of
these
different
grant
types.
This
is
really
how
you
should
go
about
choosing
them.
The
first
question
that
you
ask
is
not
do
I
have
a
native
application.
Am
I
running
in
a
browser?
Am
I
doing
its?
Who
am
I
delegating
for
OAuth
is
fundamentally
a
delegation
protocol.
B
If
the
first
question
you
should
be
asking
is,
who
am
I
delegating
for?
Is
it
an
end
user?
Is
it
some
third
party
entity,
that's
issuing
assertions,
or
is
it
just
me
once
you
know
who
you're
delegating
for
then
you
can
start
to
determine
which
kind
of
clients
that
you're
going
to
be
using
and
therefore
which
flows
you're
going
to
be
using
Open
ID
Connect
is
identity.
On
top
of
this,
we
don't
have
time
to
get
into
it.
Dynamic
registration
lets
you
get
clients,
blah
blah,
blah
token
introspection.
B
We
don't
have
time
for
all
this
there's
a
lot
of
stuff
with
OAuth.
This
is
why
token
binding
is
a
bad
idea
more
on
that
on
Wednesday
all
right
wrapping
up.
There
is
a
survey.
If
anybody
wants,
you
can
write
that
down
say
how
good
this
tutorial
was
or
how
terrible
it
was.
Let
eyestalk
know
either
way
and
that
link
should
be
getting
passed
around
as
well,
and
that's
it
unfortunately
we're
out
of
time.
I
can't
go
into
detail.
On
the
other
stuff,
like
I
said,
there
was
a
lot
of
content
here
to
cover.