►
From YouTube: OAuth WG Virtual Interim Meeting, 2020-04-06
Description
OAuth WG Virtual Interim Meeting, 2020-04-06
B
A
Last
call
on
version
30,
that
was
a
few
weeks
ago.
We
got
a
lot
of
feedback
on
that
several
comments,
ranging
from
it
will
changes
to
also
some
normative
changes
that
were
proposed,
but
yeah.
Overall,
no
big
changes
after
the
working
group
last
call.
We
imparticular
change
to
following
things
so
regarding
the
editorial
changes,
the
attacker
model
and
the
recommendation
sections
switched
places.
So
recommendations
is
now
section
2
after
the
introduction,
so
that
in
particular
developers
who
just
want
to
read
how
to
implement
OAuth
securely
can
just
go
to
the
first
section
after
the
introduction.
A
A
A
For
some
reason,
okay,
interesting
yeah,
so
I-
take
on
one
of
the
recommendations
switch
places
so
that
the
recommendations
come
first.
There
are
various
small
improvements,
mainly
clarifications
better
definitions,
in
particular
regarding
cross-site,
request,
forgery
in
the
context
of
the
law
and
what
an
open
redirect
is.
We
expand
on
some
of
the
attack,
details
and
examples
to
remove
some
ambiguities
that
were
still
in
there
and
I
restructured
the
Saarinen.
A
Last
section
we
had
a
lot
of
discussions
on
how
to
prevent
some
attacks,
and
some
of
these
discussions
were
rather
outdated
and
I
also
restructured,
some
of
them
to
make
them
easier
to
read,
and
we
got
about
dozen
or
so
emails
about
that.
Reference
is
wrong
and
we
fix
that
as
well.
Hopefully,
all
the
normative
changes,
the
interesting
stuff
before
this
version
we
had
clients
should
not
serve
it.
This
ship
tree
should
avoid
forwarding.
A
A
The
implicit
ground
we
didn't
change
too
much
actually,
but
we
changed
how
we
were
did
it
before
we
wrote.
Clients
should
not
use
the
implicit
grant
and
this
access
token
time.
This
is
a
short
version.
I
would
have
flung
version
on
the
slide.
I
should
not
use
implicit
ground
unless
access
tokens
are
send
a
friend
and
its
historical
action
is
prevented.
A
A
B
C
F
A
F
I
mean
there's,
there's
been
a
lot
of
conversation.
You
know
in
past
meetings
and
and
on
the
list
about
the
you
know
the
the
fact
that
that
mutual
TLS
is
not
applicable
or
not
feasible,
in
all
deployments,
so
making
it
recommended
here
seems
pretty
strong
I,
yeah,
I'm,
I'm
I'm,
not
terribly
comfortable
with
with
us,
telling
people
that
you
should
all
everyone
should
go
out
and
implement
mutual
TLS
like
that's.
That's
a
complicated
thing
to
deploy
for
a
lot
of
cases
like.
F
If
we,
if
we
really
think
center
constraining,
is,
is
necessary,
I
think
the
working
group
needs
to
invest
more
time
in
making
sure
that
we
have
viable
sender,
constraining
mechanisms.
You
know
it
in
deep.
Op
is
a
good
step
towards
that
for,
for
certain
environments
as
well.
But
again
it
doesn't
doesn't
cover
the
the
general
case,
so
I
would
I
would
like
to
see
the
working
group
do
some
do
more
work
here.
G
G
So
yeah
I'm,
I,
understand
and
I'm
sympathetic
to
what
Annabelle
is
just
saying
in
terms
of
this
being
a
normative
recommended
here.
I
think
what
we're
really
saying
is
that
the
recommendation
is
to
use
things
that
prevent
token
replay
and
an
instance
of
that
that
we
actually
have
an
RFC
and
implementations
and
deployments
for
is
mutual
TLS,
so,
instead
of
a
normative
recommended
here,
perhaps
this
language
could
be
instead
worded
towards
an
example
at
like
it
was
previously
I.
F
Mean
even
the
the
should
on
sender
constrained
access
tokens,
considering
we
don't
have
solid
general
case
solutions,
for
that
makes
makes
me
me
nervous
that
people
are
going
to
go
off
and
and
try
and
build
their
own
custom
things
that
are
going
to
be
interoperable
and
and
may
not
even
work,
because
you
know
people
are
trying
to
roll
things
themselves.
So
I.
G
Just
to
follow
that
super
quick
while
I
well
I,
think
that
people
will
read
this
requirement
and
go
build
their
own
thing.
I
think
they're
gonna!
Do
that
regardless
and
I
personally
see
this
as
a
bit
of
a
wake
up
for
motivation
for
the
working
group
to
get
better
jet
and
purpose
interoperable
solutions
in
place.
D
Toaster
speaking
IIFA
Leah,
grieveth
Justin
I
mean
you
need
to
consider
how
we
can,
how
we
came
they
very
are.
This
should
send
the
constraining
is
a
result
of
nearly
one
year
of
analysis,
how
we
could
cope
with
our
leakage
and
replay
of
access
tokens,
and
we
discussed
audience
restriction
and
additional
meta
data
and
heck
of
other
methods
and
in
the
end
of
working
group.
I
think
it's
two
years
ago
came
to
the
conclusion.
Center
constraining
seems
to
be
the
most
viable
option,
even
though
we
didn't
have
mechanisms
at
that
time.
Now.
D
Luckily,
we
have
entailed
s,
but
basically
I
think
that's
the
direction
we
are
talking
about,
and
it's
not
a
it's,
not
a
normative.
Must
right,
it's
a
recommendation
to
consider
sender,
constraining
and
yes,
we
don't
have
mechanisms
in
trouble
mechanisms
for
all
the
use
cases
yet,
but
I
hope
we
will
be
working
on
that
to.
F
Be
clear,
I'm,
not
I'm,
not
against
the
direction
of
sender,
constraining,
I,
absolutely
agree,
that's
something
we
need
to
be
pushing.
My
concern
is:
is
us
making
effectively
a
normative
I?
It's
it's
a
should,
but
I
mean
shoulds.
Are
you
know,
do
this
unless
you've
got
a
really
good
reason?
You
know,
usually
you
know,
I
don't
see.
I
should
expect
that
to
be,
if
you're
not
doing
it.
It's
because
you're
doing
some
edge
case
kind
of
scenario.
F
F
D
D
Just
wanted
to
come
way,
that's
you
you're,
making
a
really
viable
arguments
and
I
think
there
are
use
cases
where
III
also
go
that
use
under
constraining
what
we
have
learned.
A
walk
is
used
in
sin.
It
was
much
more
than
every
scenarios
that
in
the
in
the
past
so
and
I'm
also
not
quite
sure
what
the
right
working
here
is.
But
that's
that's
a
result
of
three
years
work,
so
I
I
think
the
shoot
is
okay.
It's
a
message.
F
C
F
Off
the
top
of
my
head,
I'll
only
I'll
think
about
it
somewhere
and
if
I
come
up
with
something
in
the
next,
you
know
today
or
so
I'll
post
it
on
the
list.
I
think
we
did
talk
a
little
bit
about
loosening
or
relaxing
the
texture
on
mutual
TLS.
I.
Think
Jim
I
want
to
say:
Justin
had
a
suggestion
there,
but.
A
F
A
C
C
And
so
do
you
Daniel?
Do
you
see
any
kind
of
major
issues
with
those
comments
so
far
or
can
we
are
we
like
you?
Will
you
be
able
to
address
those
comments
quickly,
so
we
could
kind
of
start
the
process
of
pushing
this
to
the
iesg
I.
Think
him
I
believe
the
team
proud
order.
The
group
is
probably
ready
to
push
that
forward.
This
is
that-
and
anybody
has
a
comment
about
that
after
we
addressed
those
comments
that
we
discussed
today
and
on
the
mailing
list.
I
think
there
is
anything
major
at
this.
A
C
C
F
Think
it
would
be
good
to
give
the
working
group-
at
least
you
know
like
a
couple
days
to
just
digest
the
changes,
since
we've
seen
a
lot
of
kind
of
nuanced
edits
on
this
like
on
this
document,
and
you
know
be
good
to
make
sure
that
we're
landing
in
the
right
right
place
and
some
of
these
issues.
This.
I
C
H
This
is
a
draft
that
includes
recommendations
for
people,
building,
browser-based
apps
using
OAuth,
2,
specifically
applicant,
that
are
executing
in
a
browser
also
known
as
single
page
apps.
The
idea
is:
this
complements
the
OAuth
for
native
apps
recommendations
for
the
specific
things
that
are
unique
to
a
browser-based
environment.
H
Most
of
this
is
done
by
actually
just
referencing
the
security
PCP
in
the
document
itself.
So
this
is
sort
of
the
current
state
of
things.
Changes
since
the
last
time
we
met
at
ITF,
106
Mike
Jones
sent
a
large
chunk
of
feedback
which
a
lot
of
good
good
good
points
in
it.
So
all
the
editorial
changes
and
most
of
the
substantive
changes
from
Mike
has
now
been
incorporated
into
this.
B
H
Allows
the
password
grant
even
for
first
party
applications
which
matches
the
security,
bgp
and
refresh
tokens
are
now
allowed
as
long
as
they
conform
to
the
security
bgp.
Previously
in
the
previous
draft,
they
were
not
allowed.
There's
also
a
handful
of
other
editorial
clarifications
that
I've
made
since
then
as
well.
So
that's
sort
of
the
current
state
of
things
there's
several
now
open
questions
based
on
the
changes
to
the
security
BCP.
Since
this
has
been
changed,
so
the
security
BCP
has
been
updated
to
actually
relax
the
requirement
of
pixie.
It's
now
no
longer
required.
H
It
is
only
recommended,
and
that
now
brings
up
the
point
of
well.
This
should
probably
match
it
and
the
conditions
under
which
pixie
is
not
actually
required
are
kind
of
complex.
So
I
am
thinking
that
we
should
sort
of
delegate
that
to
the
security
BCP
rather
than
try
to
reference
them
here
and
then
in
Mike.
H
It
might
seem
that
a
lot
of
this
is
actually
coming
from
Mike
Jones
review,
which
was
based
on
the
changes
after
the
security
BCP
has
been
updated.
So
some
of
the
open
questions
that
I
have
not
incorporated
from
Mike's
email
because
they
require
for
the
discussion
here-
are
things
like
this
right
now
there
are.
There
are
very
few
references
to
openly
connect
in
this
document
at
all.
H
Well,
any
situation
where
the
authorization
server
doesn't
actually
camp
actually
be
sure
that
the
access
token
was
received
by
the
right
application,
which
is
what
pixie
solves,
but
any
form
of
issuing
access
tokens
in
the
authorization
response
does
not
actually
solve
that
problem.
So
I'm
struggling
with
how
to
reconcile
that
against
allowing
something
like
an
opening
connect
response
mode
that
issues
access
tokens
in
the
authorization
response,
even
if
it
prevents
things
like
access
token
injection.
So
these
are
some
things
to
talk
about,
there's
also
a
handful
of
things.
H
So,
first
one
there
is
very
little
guidance
in
general
about
how
to
how
applications
can
vary
a
redirect
URL
without
relying
on
storing
things
in
cookies,
which
can
often
get
too
large
to
be
useful
in
browsers.
So
things
like
how?
How
do
you
actually
use
the
state
parameter
safely
in
this
situation
to
vary
the
redirect
URL?
That's
probably
something
that
should
go
into
this
document
as
well,
and
then
there
was
another
point
of
can
a
signed
request.
H
Uri
be
used
as
an
alternative
to
exact,
redirect
URI
matching,
which
I
think
that
would
also
affect
the
security
BCP
as
well,
if
that,
if
that
was
something
we
were
interested
in
exploring
and
then
there's
this
third
point
about
refresh
tokens
in
browser-based
apps
now
that
they
are
allowed
here
and
or
almost
in
fact,
recommended
in
a
browser
environment.
There's
very
little
reason
for
a
browser
app
to
have
offline
access
and
refresh
tokens
are
often
used
for
offline
access.
H
H
There
is
a
this
demo.
App
was
brought
to
my
attention
where
it's
someone
who
actually
implemented
a
Roth
client
in
a
serviceworker
in
a
browser
which
is
a
specific
API,
that's
very
sort
of
isolated
from
the
main
part
of
the
browser
environment,
the
JavaScript
moment
in
the
browser
and
what
this
effectively
does
is.
H
It
means
that
a
browser
can
actually
protect
access,
tokens
and
refresh
tokens
from
being
accessed
by
anything
else
on
the
page,
which
is
turns
out
very
useful
for
browser-based
apps,
especially
because
they
are
not
able
to
use
client
secrets
effectively
and
essentially
what
this
does
is
it
routes.
It
turns
the
little
serviceworker
into
an
OAuth
client,
where
every
API
request
has
to
run
through
it.
So
it
means
that
tokens
can't
be
extracted
by
random
JavaScript
on
the
page.
So
I
saw
this
and
this
seems
like
a
valid
pattern.
H
That
is,
has
a
lot
of
benefits
in
this
environment
and
I'm
wondering
if
we
should
add
this
now
as
a
additional
architectural
pattern
to
the
document.
So
that
was
a
lot
of
stuff.
That's
the
current
say
two
things
I'm
happy
to
go
back
on
into
these
slides
and
would
like
to
yeah
open
this
up
for
discussion.
J
This
is
Mike
Jones
and
thank
you
for
addressing
most
of
the
review
comments
from
me
and
the
Microsoft
developers
as
I
think.
You've
already
partly
alluded
to
the
one
substantive
comment,
which
is
really
important.
In
my
view,
that
is
not
an
addressed
and
that
makes
it
unaligned
with
the
security.
Bcp
is
you're
requiring
pixi
across
the
board
in
your
current
text.
Whereas
if
you
read
the
security
BCP
in
four
five,
three
there's
to
countermeasures
code
injection,
you
can
either
use
pixie
or
open
ID
connect
nonce,
and
even
if
you
know,
we
decided.
H
So
this
was
one
of
the
things
where
I
am
I
feel
like
saying,
like
I
feel,
like
the
text
needs
to
be
more
explicit,
because
just
saying
use
open,
reconnect,
nonce
does
not
actually
make
it
clear
how
that
solves.
How
that
solves
the
attack,
because
it
requires
a
few
more
steps
on
top
of
that.
So
if
we
do
add
that
I
will
want
to
make
it
explicit
about
all
of
the
steps
required
in
order
to
actually
use
that
instead
of
pixie
sure.
J
That's
fine.
So,
for
instance,
you
could
describe
using
the
C
hash
value
in
the
ID
token
to
confirm
that
the
code
hasn't
been
injected
and
you
know
other
similar
things
where
you're
just
repeating
the
steps
that
are
already
required
when
you're
using
the
nonce
correctly
and
I'd
be
happy
to
work
with
you
on
that.
But
you
know
I
think
you
said
you
were
gonna,
send
another
message
about
the
rest
of
the
stuff
and
I.
D
Speaking
year
either
just
talking
about
none
swears
as
pixie.
You
know
we
are
bringing
out
the
sea,
that's
from
my
perspective,
the
third
option.
So
so,
what's
your
intention?
I
mean
the
security
PCP
intentionally
only
mentions
nuns
and
pixie,
since
they
both
go
very
relative
code.
See
has
another
response
mode.
So
what's
the
scope
of
the
change
that
you're
proposing
for
the
obesity
well.
J
D
So
the
option
would
be
to
to
instead
refer
to
the
the
text
in
the
insecurity
piece.
I
mean
it's,
it's
a
separate
section.
J
And
refer
to
it,
I
mean
I,
get
wanting
to
refer
and
repeat
stuff,
but
there's
also
attention
that
developers
tend
not
to
follow
references.
They
want
a
package
solution
in
one
place.
So
if
the
browser-based
apps
can
at
least
summarize
things
in
a
way
that's
actionable
by
developers
but
is
aligned
and
not
different
than
the
security
BCP
I
think
that's
fine.
F
F
About
Backman,
Amazon
I
definitely
think
we
want
to
bring
these
into
alignment.
I
agree
with
Mike's
concern
that
developers
don't
necessarily
want
to
follow.
References
I
think
there's
room
for
us
to
say
that
this
this
we
mitigate
and
two
ways
that
you
can
do
that
our
pixie
or
if
open,
ID,
connect
nonce
as
described
in
the
BCP
and
point
at
point
developers
there
for
further
details.
I
don't
think
we
want
to
try
and
replicate
all
of
the
the
explanation
that
the
BCP
has
I.
F
B
J
A
D
Discussion,
I,
don't
think
that
all
SBA's
will
be
public
clients,
as
you
all
may
have
noticed.
I
mean
I'm
a
huge
fan
of
using
SPS
in
conjunction
with
a
back-end,
especially
for
use
cases
where
you
really
really
need
to
have
a
real,
confident,
rich
client
that
you
can
identify
his
business
partner.
So
what
I
would
like
to
get
across
it
and
that's,
for
example,
for
us
very
so
what
I
would
like
to
get
across
us,
so
SPS
can
be
for
confidential
clients
as
well.
So
we
shouldn't
restrict
a
discussion
of
fbas
there.
G
Are
public
lines
but
person
I
would
argue
that
in
that
case
the
SBA
is
not
actually
the
client
at
all.
It's
the
back
end,
that
is
the
OAuth
client
the
OAuth
perspective,
and
that
is
a
pattern
that
is
covered
by
this
ECP,
because
telling
people
not
to
do
oh
author
directly
in
their
app
is
just
as
valuable
as
telling
them
how
to
do
off.
G
D
The
initial
discussion
around
the
scope
of
that
of
the
PCP
and
from
our
perspective
in
SBA
is
one
that
uses
the
front
end
that
has
code
that
lives
in
the
user
agent
without
any
any
further
assumptions
regarding
the
rest
of
the
architecture,
I
mean
we
can't
go
back
to
that
discussion,
but
it
seems
I've
got
a
different
picture
on
that.
I.
F
Would
ask
what's
the
if
we're
not
focusing
this
document
on
a
single
page
apps
where
we're
actually
doing
the
OAuth
flow
from
the
browser?
You
know
user
agent
side
code
doesn't
doesn't
that
just
mean
we're
talking
about
all
web
clients,
then
that
doesn't
really
seem
like
the
right
scope
for
this
document.
I.
F
For
the
purposes
of
the
delineation
is
really:
where
is
the
OAuth
flow
happening?
Is
it
happening
through
user
agent
side
code,
or
is
it
happening
through
server-side
code?
That's
a
meaningful
distinction
to
make
the
document
itself
actually
notes
that
I
I
think
that's
that's
the
right
delineation
for
us
to
be
using
here
that
what
what
we're
considering
is
browser
based
apps
for
the
purposes
of
this
doc
or
really-
and
maybe
the
name-
isn't
quite
descriptive
and
out
there.
H
Does
much
the
intent
here
and
the
document
calls
out
the
case
of
JavaScript
code
talking
to
a
back-end
so
that
that
architecture
is
pointed
out
and
sort
of
the
goal
there
is
that
in
that
case,
that
is
that
javascript
code
is
not
an
OAuth
client
and
the
rest
of
this
document
does
not
apply
to
that.
Organize.
H
H
F
H
A
H
B
This
particular
case
in
which
there
is
a
back-end.
Currently
the
document
says
something
that
is
a
bit
odd.
The
fact
that
you
can
use
the
access
token
in
the
browser
as
identifier
of
Osetra
and
to
me
that
looks
a
bit
odd,
let's
say
vector.
If
we
use
the
cookie,
then
we
just
fall
back
on
the
regular
web
app
with
a
back-end,
but
as
soon
as
you
say
that
you
want
to
use
a
an
artifact
which
is
not
the
data
by
the
browser
directly,
but
you
have
to
be
an
encode.
B
It
looks
like
there
is
a
large
deal
of
the
security
recommendations
that
we
should
have
in
there
in
another
point
is
vector
if
you
sing
the
wide.
A
lot
of
people
are
recommending.
Also
this
scenario
in
which
the
back-end
obtains
tokens
and
then
forwards
them
to
the
JavaScript
and
the
JavaScript
uses
them
directly
for
calling
api's,
which
I
find
the
dangerous
without
any
further
guidance.
Because
now,
at
this
point,
you're
a
back-end
will
actually
effectively
behave
like
an
authorization
server,
but
without
having
the
all
the
guidance
that
normally
we
would
give
in
there.
B
So
I'm
wondering
if
we
could
be
on
one
side,
I
just
summarized
sorry
for
the
long
intervention
on
one
side
there
summarized
back
there
what
we
mean
by
using
the
access
token
as
a
pointer
to
the
session
and
the
other.
Is
there
perhaps
explicit
to
the
address
the
scenario
in
which
the
back
end
is
used
as
a
facade
and
even
just
saying
it's
out
of
scope,
but
at
least
said
just
acknowledging
its
existence.
I.
H
Think
that's
a
great
point,
and
there
probably
is
worth
writing
something
about
in
here,
because
that
is
something
people
are
doing,
so
we
should
either
tell
people
how
to
do
it
safely
or
not
to
do
it
for
whatever
reason
so
I
mean
I
like
that
idea.
We
can
talk
about
that
further.
Let's
try
to
bring
it
up
on
the
list
Oh
to
save
time
here,
because
I
think
that's
a
pretty
big
topic,
but
I
do
like
the
idea
of
mentioning
that.
H
Still
want
to
spell
out
the
exact
scenarios
where
it's
okay
to
do
it,
even
if
we
just
sort
of
say
you
go,
read
open,
D
connected
to
actually
figure
out.
How
just
to
be
clear.
Are
we
still
talking
about
using
just
the
authorization
code
flow,
or
does
this
also?
So,
if
Mike
are
we
talking
about
using
the
nonce
parameter
and
getting
an
ID
token
using
the
authorization
code
flow
or
also
using
the
response
type
token
to
get
the
ID
token
type.
D
H
D
F
You
know
where,
rather
than
trying
to
enumerate
the
possible
combinations
of
code
with
something
else,
you
know
the
the
the
purpose
here
is
that
we
need
to
make
sure
the
Refresh
token
axe
is
still
going
to
being
sent
over
the
token
the
token
endpoint
and
you
do
that
by
making
sure
code
a
server
response
type,
there
might
be
other
response
types
and
they
might
be
fine.
But
you
know
we
just
don't
include
token
and
must
include
code.
J
G
This
is
Justin,
but
it's
not
just
a
matter
of
which
is
good
and
bad.
They
are
good
and
bad
under
different
circumstances.
So
token
is
perfectly
fine.
If
you're
using
pixie,
it's
not
the
token
on
its
own
or
sorry
coat
own
on
its
own.
It's
perfectly
fine.
If
you're
using
pixie,
it's
not
that
it's
necessarily
good.
G
Always
it's
good
under
specific
circumstances,
so
well,
I
mean
expense
to
have
some
guidance
along
that
I'm
actually
with
with
Annabelle
in
saying
that
we
really
need
to
instead
say
why
each
of
those
bits
not
necessarily
each
of
those,
but
why
a
particular
thing
works
in
a
particular
way.
So,
for
example,
say
you
know
you
have
to
get
your
access
token.
From
the
token
end
point
you
do
that
you
know
you
must
include
authorization
code
or
protecting
it
using
an
open,
ID
connect
ID
token
as
specified
over
here.
G
It's
foolhardy
to
pretend
it
that's
why
we
have
a
registry
after
all
and
and
it's
going
to
help
developers
that
might
find
themselves
in
some
weird
combination
of
a
legacy
system
that
they
have
to
support,
to
figure
out
where
they
actually
need
to
go,
and
you
know
figure
out
like
what
bits
they
need
to
add
and
why
we
can't
assume
that
people
are
doing
things
just
based
on.
What's
in
that
list,
I.
J
F
F
F
Just
to
reiterate
something
else.
Justin
said
they're
also
gonna
be
developers
out
there
who
are
having
to
roll
some
funky
proprietary
response
type
potentially
to
accommodate
legacy
systems
that
they're
dealing
with.
That
will
really
benefit
from
a
clearer
statement
of
why
this
is
important
and
why
this
option
works
for
this
case
and
that
option
works.
For
that
case,
it
may
be
worth
looking
at
the
text
that
comes
out
of
this
discussion
and
seeing
if
it
would
be
better
served
to
move
that
to
the
BCP
that
the
security
PCP.
E
H
What
I'm
hearing
is,
we
should
add
text
that
says
these.
These
applications
must
get
tokens
access
tokens
from
the
token
endpoint
and
to
protect
that
process
you
have
to
either
use
pixie
or
use
open,
D
connect
and
check
the
mounts
value,
and
then,
in
addition
to
that,
we
can
include
what
the
sort
of
summary
of
what
amble
was
saying,
which
is
that
the
response
type
must
not
include
token,
which
is
a
way
to
ensure
that
you're
getting
tokens
from
the
token
endpoint
and
then
lists.
H
F
Think
you
can
consolidate
those
to
be
just
like
one
thing
like
you
need
to
get
the
token
over
the
token
from
it
from
the
token
endpoint,
and
that
means
you
need
to
include
the
code
response
type
to
protect,
that
you
can
use
pixie
or
you
can
use
you.
You
may
be
able
to
use
an
alternative
such
as
nonce
if
you
are
using
a
combination,
response
type
from
open
ID
connect
like
code
ID
token.
H
C
J
C
Awesome
and
I
think:
let's
call
it
a
day
here.
That
was
great
discussion
and
thank
you
guys.
Any
last
minute
comment
here.