►
From YouTube: Increase the resilience of authentication and authorization applications you develop – June 2021
Description
This month’s in-depth topic: Increase the resilience of authentication and authorization applications you develop. Tips for adding and increasing resiliency in apps that sign-in users and apps without users. Using a Microsoft Authentication Library and best practices to follow if you use a different library. Authorization with JWT and using Microsoft Continuous Access Evaluation (CAE). Demo and tips on evaluating/adopting CAE. Resilient methods for fetching metadata and validating tokens including use of customized token validation, as needed. This session was delivered by Microsoft Program Managers Harish Suresh | @harish_suresh and Kyle Marsh | @kylemar and was recorded on June 17, 2021.
Stay connected:
• Twitter https://twitter.com/microsoft365dev and @azuread
• YouTube https://aka.ms/M365DevYouTube
• Blogs https://aka.ms/m365pnp/community/blog
• Recurrent Invite https://aka.ms/IDDevCommunityCalendar
A
B
Sure,
thanks
kyle
hi,
I'm
a
program
manager
in
the
microsoft
identity,
division
where
I
work
with
a
lot
of
developers
and
help
them
integrate
their
applications
with
our
identity
platform
and
make
sure
we
follow
the
best
practices
and
keep
the
application
secure.
So
that's
that
and
off
to
you,
kyle
thanks
for
that.
A
Thanks
so
we're
doing
a
quick
refresher
on
resiliency
and
and
building
your
application
so
that
they
can
be
more
resilient
and
for
any
any
protect
potential
issues
between
you
and
getting
your
tokens
so
we're
doing
gonna.
Do
a
quick
recap
of
some
general
guidance
that
we
have
from
our
resiliency
for
developers
white
paper,
another
quick
look
at
authorization
in
general
and
specifically
continuous
access
evaluation,
which
is
our
newest
feature,
which
does
add
a
lot
of
resiliency.
A
So,
just
to
recap
where
we
have
have
been
for
our
guidance
for
for
developers
with
respect
to
building
more
resilient
applications,
let's
first
start
with
applications
that
sign
in
users,
so
whenever
a
user
is
present
in
front
of
the
application.
Frankly,
our
easiest
advice
is
that
you
should,
wherever
possible,
build
on
top
of
the
microsoft
authentication.
Libraries
are
msol.
A
These
libraries
are
available
in
a
number
of
different
developer
environments
and
they
really
do
encapsulate
not
only
our
best
practices,
if
you
will
but
lots
of
optimizations
to
work
very
well
with
microsoft
identity.
So,
yes,
they're,
built
on
top
of
open
standards
like
open
id
connect
and
oauth
2,
but
we
do
since
we
are.
The
implementers
of
the
service
know
how
to
make
some
additional
optimizations.
A
So,
yes,
we
want
to
make
it
very
easy
for
your
applications
to
integrate.
So
we
handle
a
lot
of
the
kind
of
work
that
lots
of
protocol
level.
Libraries
need
you
to
do
so.
We
look
after
managing
the
tokens.
Caching
them
we
can
help
you
with
how
you
can
persist
them
and
all
of
that
work.
We
we
go
ahead
and
make
it
easy
for
you
to
not
have
to
worry
or
spend
any
time
implementing
that
capability
in
your
applications,
but
where
we
can
go
beyond
things
like
best
practices.
A
We
have
a
resiliency
capability
in
built
into
azure
ad
today,
where
we
have
a
decorated
backup
system
that
can
issue
tokens
with
our
primary
system
being
completely
down,
and
while
we
can
do
automatic
switchovers
from
one
to
the
other,
if
the
part
of
our
infrastructure
that
that
does
that
automatic
switch
is
down,
msol
can
fall
back
and
do
the
automatic
switch
for
you.
So
these
are
the
kinds
of
things
we
can
build
into
our
libraries
because
they're
they're
infinitely
familiar
with
our
infrastructure.
A
If
you're
not
building
on
top
of
msol,
there
are
some
general
guidance
first
off.
Caching.
Tokens
is
really
important.
It's
important
just
in
terms
of
performance,
so
that
we
don't
go
ahead
and
start
throttling
your
application,
but
really
it
reduces
your
dependency
on
getting
a
token
in
the
first
place.
A
If
I
ask
for
a
token
every
minute,
when
I
actually
have
a
token
that's
good
for
an
hour
or
a
lot
longer
than
an
hour,
I'm
simply
putting
an
unnecessary
burden
on
my
application
to
make
sure
that,
oh,
that
that
that
infrastructure
has
to
be
up,
the
network
has
to
be
up
everything
between
me
and
getting.
That
token
has
to
be
up
and
running
when
I
really
didn't
need
it,
because
a
cash
token
takes
care
of
me
having
to
make
a
lot
of
extra
calls.
A
Now,
it's
also
important
that
you
serialize
and
persist
these
tokens
now
this
has
to
be
done
very
securely,
but
we
give
you
access
tokens
today.
Generally,
they
might
be
good
for
about
an
hour
or
so
we're
looking
at
everything
we
can
to
extend
those
token
lifespans.
Continuous
access
evaluation
is
an
example
of
this.
Now
we'll
have
tokens
access
tokens
good
for
a
day.
A
We
have
refresh
tokens
that
are
good
for
many
days.
Well,
if
I
can
drive
my
authentication,
because
I
don't
need
it,
because
I
already
have
a
perfectly
good
access
token
or
I
can
drive
it
with
a
refresh
token
that
takes
out
a
whole
chunk
of
infrastructure
that
my
application
doesn't
have
to
worry
about
right
now.
So
if
I
have
to
do
a
fresh
authentication
where
the
user
has
to
type
in
their
username
and
password,
maybe
or
do
an
mfa
or
password
list,
I
take
on
a
dependency
into
all
kinds
of
subsystems
of
azure
active
directory.
A
A
Fresh
authentication
and
all
the
dependency
on
that
infrastructure
isn't
isn't
required
right
now,
and
that's
really
the
key
here
is:
we
want
to
make
sure
that
whenever
possible,
you
follow
our
prescribed
guidance
of
always
asking
for
acquiring
a
token
silently
to
begin
with,
we
want
to
avoid
these
fresh
authentication.
So,
for
example,
in
your
code,
you
should
never
be
saying
prompt,
equals
login
or
prompt
equals
consent,
because,
first
off
it's
a
bad
experience.
A
It
requires
the
user
to
make
a
gesture
now
that
they
didn't
really
need
to
do,
because
we
had
a
perfectly
good
single
sign-on
state
to
work
with,
but
on
top
of
that,
it's
also
taking
these
dependencies
on
those
subsystems
that
I
was
saying
before
now.
I
have
to
make
sure
that
the
mfa
infrastructure
is
also
running
end-to-end
and
that
might
be
simple,
as
simply,
as
you
know,
does
their
phone
still
have
battery
power
right.
So
all
of
these
things
come
into
play.
A
If,
if
I,
if
I
require
these
fresh
authentications,
then
don't
do
silent
token
authentication
with
cash
tokens
and
refresh
tokens
et
cetera
again,
msol
handles
all
of
that.
If
you
wanted
to
do
if,
if
you're
using
msol,
whenever
we
respond
with
a
with
an
error
code
response
code,
something
like
a
429,
especially
or
a
500
response
code,
you
need
to
honor
our
retry.
After
that
we
give
you
back
as
this
is
how
long
you
should
wait
before
you
ask
us
again:
it's
really
really
problematic
for
the
resiliency
overall.
A
So
we
really
do
need
developers
to
pay
attention
to
that
retry
after
we
give
you,
when
we
give
you
one
of
these
response
codes.
If
we
don't
provide
that
retry
after
code,
then
you
need
to
go
ahead
in
your
application
and
have
a
exponential
backup
back
off,
rather
as
a
backup
to
not
get
getting
the
retry
after
so
again.
The
really
important
thing
here
is
to
not
joe
go
into
a
tight
loop
trying
your
retries,
because
that
could
adversely
affect
the
overall
performance
of
the
system
altogether.
A
Now,
whenever
possible,
you
should
use
brokered
authentication.
Brokered
authentication
is
us
using
on
our
all
of
all
the
devices.
Today
we
have
on
on
mobile
devices
on
ios.
It
could
be
the
the
or
it
is
rather
the
authenticator
app
on
android.
It
could
be
the
authenticator
app
or
the
company
portal
we're
just
entering
preview
to
be
able
to
have
the
company
portal
app
on
mac
os,
handle
this
capability
and
on
windows
it's
built
in
into
the
windows
os.
It
was
something
called
the
web
account
manager.
A
The
all
of
this
does
is
it
can
work
with
something
we
refer
to
as
a
primary
refresh
token,
we
can
issue
primary
refresh
tokens
to
first
party
microsoft,
apps,
like
the
operating
system
or
these
brokers,
and
that
allows
us
to
share
more
state
across
applications
not
needing
to
do,
for
example,
an
additional
mfa
or
sharing
that
that
state
across
all
of
the
applications
that
go
through
the
broker.
So
it
can.
A
It
can
really
help
your
your
resilience
by
using
our
brokered
authentication,
and
this
now
is
our
primary
guidance
even
for
windows,
with
the
introduction
of
the
capability
of
the
msol
library.net
library,
our
desktop
one
to
use
the
web
web
account
manager
for
its
authentication.
This
is
our
primary
guidance
now
for
this.
It
also,
by
the
way,
makes
it
possible
to
know
if
the
device
is
managed
and
to
support
a
number
of
other
conditional
access
policies
that
can
really
help
secure
your
enterprise
as
well.
A
Now,
if
your
application
doesn't
have
users
in
front
of
it,
you're
a
service
or
a
demon,
something
along
those
lines,
we
first
and
foremost
think
that
you
should
be
using,
whenever
possible,
a
managed
identity
for
azure
resources.
So,
if
you're
building
these
services
on
azure,
you
should
be
using
an
azure
managed
identity
for
azure
resource.
A
The
first
thing
is:
they
are
more
secure
because
there's
no
need
for
secrets
management.
If
you
can't
manage
a
secret,
you
can't
lose
it.
You
can't
have
it
stolen,
you
can't
have
it
incorrectly
used
in
some
other
way,
shape
or
form.
So
this
is
a
really
big
improvement
to
the
security,
but
it
also
means
that
we
can
also
use
additional
optimizations
since
we
handle
the
code
for
both
ends
of
the
manage
identity.
A
We
can
turn
around
and
localize
to
that
region
with
respect
to
the
interactions
with
the
identity
and
any
azure
id
that's
required
as
well,
so
that
helps
us
stay
and
not
take
a
dependency
on
another
data
center
or
another
region.
If
your
service
is
running
from
one
region,
we
won't
bring
in
a
dependency
on
a
second
region
because
we're
using
a
generic
authentication.
A
We
have
a
confidential
client
object
there
and
it
again
knows
how
to
work
with
tokens.
It
knows
how
to
do
this
to
to
to
refresh
them,
etc.
The
proactive,
typical
refresh
comes
into
play,
and
we
also
can
can
work
with
the
gateway
when
it's
if
the
gateway
is
down
so
using
msol
for
your
daemon
or
service
applications
can
also
help
with
the
resiliency
you
have
now.
A
Now
this
application,
this
api,
rather
doesn't
know
really
where
this
token
came
from
all
it
knows,
is
it
came
from
the
the
the
client
that's
calling
the
api
it
needs
to
check
to
find
out.
You
know
what,
if
this
token
is
actually
been
issued
by
the
authority
azure
ad
in
this
case,
that
they
can
trust.
A
A
The
keys
which
we
have
published
that
we
are
using
to
sign
these
tokens,
so
the
token
is
going
to
be
signed,
we're
going
to
make
sure
that
it's
it's
properly
signed
and
then
once
we
look
at
it
signed,
we
can
then
say:
oh,
is
this
a
token
that
that
microsoft
identity
says
it's
using,
so
this
is
not
a
call
that
you
make
on
every
every
call
that
every
time
somebody
calls
your
api,
you
don't
turn
around
and
call
us.
You
use
this.
A
So
the
thing
is
that
token
is
actually
valid,
therefore,
until
it
expires,
so
we
issue
a
token
by
by
we
usually
issue
a
token
for
say
an
hour
and
that
token
is
good
and
can
be
used
for
that
entire
hour.
As
far
as
the
api
is
concerned,
now
this
creates
a
problem,
because
what,
if
an
event
happens
after
the
token
issues,
but
before
the
hour
expires?
A
Well,
we
don't
have
an
opportunity
to
er
by
default
to
do
anything.
About
that
token,
it
simply
has
to
expire
well
with
one
option
that
some
identity
providers
do
is
instead
of
providing
a
token.
That
is
a
job
token
that
can
be
validated
just
on
the
api
side.
Without
calling
the
identity
provider,
they
suggest
that
the
api
for
every
api
call
needs
to
call
back
to
the
identity
provider
and
see
if
that
token
is
still
valid.
A
It
does
allow
them
to
to
to
invalidate
the
token
or
revoke
the
token
quickly,
but
it
also
means
every
time
somebody
calls
your
api.
Another
api
call
needs
to
be
made,
so
this
is
a
very
expensive
process
because
it
will
slow
down
the
responsiveness
of
your
apis
on
top
of
just
causing
a
a
lot
of
overhead
in
adding
these.
These
extra
calls,
so
we
at
microsoft,
identity
aren't
going
to
adopt
a
introspection
model.
A
Instead,
what
we
are
doing
is
working
with
working
to
create
something
we're
calling
microsoft,
continuous
access,
evaluation,
we're
doing
this
in
consultation
with
the
the
open
id
connect,
shared
signals
and
events
working
group,
so
we're
quite
keen
on
aligning
our
efforts,
but
we're
implementing
this
before
the
standard
is
done.
If
you
will
so,
we
can
today
have
microsoft,
continuous
access
evaluation
and
what
happens
there
is
before
I
even
have
an
application
in
the
picture.
A
A
relationship
is
established,
a
conversation
if
you
will
is
established
between
the
api,
in
this
case
microsoft,
graph
and
microsoft
identity.
So
now,
microsoft
identity
has
the
ability
to
push
events
to
the
to
the
resource
in
here
microsoft
graph
api.
So
we
can
tell
the
resource:
hey,
there's
a
security
event
for
a
user
that
you
need
to
be
aware
of,
or
we
can
say,
oh
well,
this
user
has
a
conditional
access
policy
that
includes
their
location.
A
A
But
now
the
api
can
say:
hey
has,
has
this
token
been
revoked?
Should
I
really
accept
this
token
still
or
you
know,
is
this:
this
user
have
a
conditional
access
policy
that
includes
location
and
therefore
I
should
check
the
user's
location
or
the
location
that
this
api
was
called
from
right
before
I
go
ahead
and
continue
so
I
do
see
we
have
a
question.
You
say
an
access.
Token
usually
expires
about
an
hour.
What
can
change
the
expiration
time?
Is
it
more?
A
Someone
could
revoke
rebut
the
longest
lifetime
is
one
hour,
no
there's
a
number
of
different
factors
that
could
change
the
token's
lifespan
there.
There
is
an
ability
to
customize
the
the
life
of
a
token,
which
is
something
we
don't
normally
suggest,
because
it's
better
to
make
things
happen
automatically,
but,
for
example,
we're
starting
to
issue
our
tokens
around
about
an
hour.
So
we
will
we'll
issue
a
token
life
stand
somewhere
between
60
and
90
minutes,
so
in
average
about
75
minutes.
A
The
reason
for
that
is,
you
know
we
find
situations
where
we,
you
know
a
company
shows
up
and
everybody
signs
in
at
nine
o'clock.
Well
now,
everybody's
refreshing
their
tokens
every
hour
and
it
kind
of
puts
the
strains
on
everybody's
infrastructure,
so
we're
adding
some
jitter
if
you
will
to
the
length
of
token
lifespan
so
that
not
all
of
the
tokens
are
are
expiring
at
the
same
moment
and
need
to
be
authenticated
at
the
same
moment.
A
A
A
A
Is
it
needed
to
be
issued
after
noon
after
one
o'clock?
Let's
say
because
at
12
30
the
user
lost
their
device
and
we
revoked
all
their
sessions.
So
we
need
a
token
that's
issued
after
one
or
we
need
it.
We
need
to
check
your
location
or
the
user's
password
change,
but
your
claims
in
the
token
you
have
at
the
moment
or
insufficient
because
they
were
issued.
It
was
issued
too
early,
for
example,
so
the
the
I
have
my
the
error
comes
from
azure
id.
A
It's
insufficient
claims
and
if
I
look
at
something
like
a
claims
challenge,
I
decoded
here
we
see
that
the
challenge
is
the
claim
that
you
have
you're
not
before
is
not
after
the
value
I
actually
need,
which
is
the
the
new
time
upon
which
the
token
has
to
be
issued.
For
I
see
we
have
another
question
conditional
access
sessions,
control
refresh
and
session
tokens.
Like
token
lifespan
policy
access
tokens.
Yes,
we
can.
There
are
other
ways
that
will
affect
those
lifespans,
that's
true.
A
So
we'll
handle
events
today,
things
like
the
users,
obviously,
if
the,
if
the
account
is
disabled
or
deleted,
if
their
password
changes
any
of
these
areas
will
cause
us
to
send
a
message
to
the
api,
so
azure
ad
would
say:
oh
look.
The
users
change
their
password
we'll
go
and
inform
the
microsoft
graph
api
that
they
now
need
to
to
issue
a
claims
challenge,
because
with
the
new
password
we
want
to
the
the
the
user
to
put
the
new
password
on
that
other
device.
A
Oh,
so
that's
so
we
are
talking
a
bit
about
how
we're
going
to
make
the
app
more
resilient
to
an
azure
id
outage.
Conditional
access
evaluation
is
one
big
area
here,
so
we
can
generate
this
conditional
access,
evaluation
event
based
on
you
know
the
user.
Something
happened
to
the
user
or
the
api
itself
can
check
and
say.
Oh,
the
user
has
a
a
conditional
access
policy
that
requires
location.
A
It
needs
the
user,
the
ad
to
re
access
this
resource.
The
user
has
to
be
on
corpnet,
for
example,
or
some
location
based
policy,
and
if
the
api
call
comes
from
a
different
policy,
then
we
can
simply
go
ahead
and
and
fail
that
call
so
conditional
access.
Poli
evaluation
really
does
help
security
a
lot.
Let
me
just
do
a
quick
demo
here,
so
I've
signed
in
a
couple
of
applications
already.
A
So
this
application,
as
you
see,
is
using
continuous
access
evaluation
and
if
I
look
at
my
token
response,
the
token
is
good
for
until
just
before
nine
o'clock,
when
I
signed
in
later
today,
the
on
the
june,
the
18th.
I
also
have
another
instance
of
this
application.
Running
this
instance
is
not
using
continuous
access
evaluation.
So
you
see
the
check.
Mark
is
unset
and
if
I
look
at
my
token
lifespan
here,
I
see
that
the
token
is
good
until
10
o'clock,
so
about
an
hour
after
I
signed
in,
but
today
not
tomorrow.
A
So
I'm
sorry,
today's
the
17th.
This
token
is
good
for
an
hour
until
10
o'clock.
This
token,
which
was
signed
in
about
the
same
time,
is
good
for
a
day.
So
one
thing
here
is:
I
don't
need
to
go
back
to
azure
ad
and
ask
for
a
token
again
until
this
day
expires
right.
So
now
I've
increased
my
resiliency
to
an
azure
ad
outage,
because
I'm
not
going
to
ask
for
tokens
anymore
or
as
often
anymore.
A
A
Decode
it
and
then
I
can
simply
go
ahead
and
call
for
getting
at
my
my
mso
getting
an
access
token,
but
now
I'm
going
to
include
my
claims
challenge
as
part
of
that
request.
So
I
acquire
a
token
silently
so
maybe
the
the
user
can
can
authenticate
go
through
this
process
without
silently
so,
for
example,
if
we
just
change
locations
and
they
change
back,
we
could
acquire
the
token
silently
but
mo.
A
If
I
revoke
the
sessions,
that's
going
to
require
a
full
authentication,
so
I'll
fall
back
to
acquire
token,
interactive
and
again
I'll
provide
that
claims
challenge.
When
I
make
that
call
as
long
as
I
have
this
code
in
my
application,
then
I
can
go
ahead
and
when
I
create
my
mso
client,
I
can
add
the
client
capability
of
cp1,
which
is
really
telling
azure
active
directory
and
the
api
that
your
application
understands
and
has
implemented
continuous
access
evaluation.
A
A
A
So
now
what
will
happen
is.
I
have
a
perfectly
valid
token.
That's
good
for
12
more
hours
when
this
clock
finally
says
yep.
You
can
start
refreshing
the
token
now,
if
is
anything
wrong
with
azure
id
or
or
any
of
the
path
between
your
application
and
getting
a
token
from
azure
ad
the
network's
down.
What
have
you
it
doesn't
matter,
because
I
can
still
use
the
token
I
have
now,
if
there's
a
an
outage
for
an
hour
or
two
hours
or
three
hours,
your
application
would
be
unaffected
because
it
still
has
a
token.
A
It's
still
allowed
to
call
the
other
call
the
api,
but
and
then,
as
soon
as
the
token
flow
it
gets
going
again.
It
gets
a
new
token
and
off
you
go
so
we've
seen
applications
that
have
these
long
live
tokens
which
do
this
proactive,
refresh,
be
completely
unaffected
during
an
outage
because
they
don't
really
need
the
the
token
flow
to
work
at
that
particular
instant
and
that
can
really
improve
the
resiliency
of
your
application.
A
So
we
do
have
some
information
today
on
how
you
can
write
this
code
at
that
at
that
link
there
in
terms
of
how
you
would
make
your
your
application,
continuous
access,
evaluation,
aware,
let
me
see
if
I
can
catch
up
on
the
questions
harish.
I
know
you've
been
answering
some.
Do
we
have
some
open
questions
in
the
chat.
B
A
Yeah
so
there's
two
two
phases:
there
continuous
axis
evaluation
is
in
production
force
the
for
some
microsoft,
apis
and
microsoft
applications.
The
key
here
is
the
microsoft
graph
api.
That's
currently
in
preview.
I
don't
have
an
end
target
of
when
it
will
be
generally
available,
but
I
expect
it
will
be
relatively
soon
that
we'll
be
able
to
have
the
microsoft
graph
api
be
ga
for
continuous
access
evaluation.
A
B
Open
one,
I
think
we
could
quickly
talk
through,
is
on
a
client-side
standpoint,
how
what
is
the
recommendation
to
encrypt
the
tokens
or
our
or
the
token
cache
best
practices?
I
think
if
we
can
just
summarize
that,
in
a
single
line
on
the
whole,
I
think
that
will
take
care
of
the
last
question
and
then
we'll
be
able
to
okay.
A
Yeah,
absolutely
we
should
certainly
so
when
you're
persisting
these
tokens.
One
of
the
reasons
we
don't
automatically
persist
on
every
amsoil
implementation
is,
it
has
to
be
done
in
a
secure
way,
an
encrypted
way.
If
you
will,
and
in
some
platforms
it's
not
a
given
that
it's
built
in
so,
for
example,
on
ios
and
android
it.
Here's
exactly
how
you
would
store
information
that
is,
you
know,
needs
to
be
kept
private,
so
we
simply
implement
that
in
msol.
So,
yes
for
token
caching
and
storage,
you
should
definitely
be
encrypting.
A
Those
tokens
wherever
excuse
me
whenever
you
can
so
I
want
to
bring
up
another
point,
though
of
authorization.
So
we
have
authorization
based
on
the
just
the
the
the
transmission
of
tokens.
That
sort
of
allows
me
to
call
an
api.
I
also
have
authorization
options,
sometimes
either
in
the
api
or
in
my
application,
where
I
need
to
know
additional
information
to
decide
whether
this
user,
for
example,
gets
to
use
a
particular
functionality
in
the
app,
and
I
have
two
choices
of
where
I
get
my
authorization
information
from
one
is.
A
I
can
get
information
directly
from
the
token
and
if
it's
a
standard
claim
today
or
an
optional
claim
say,
I
need
to
know
the
user's
ip
address
or
I
need
to
know
the
last
time
they
authenticated
or
I
need
to
know
the
user's
upn
or
or
some
particular
element
attribute
about
the
user.
I
can
put
that
information
directly.
In
the
token,
obviously,
if
I
get
it
back
in
the
token,
it
saves
me
needing
to
make
another
network
call,
so
it
improves
my
resiliency.
A
So,
for
example,
one
of
the
things
we
certainly
advise
against
is
to
use
the
user
info
endpoint.
It's
there.
It's
so
that
we
are
standards
compliant,
but
everything
you
find
in
the
user
info
endpoint
will
actually
be.
In
the
token
you
have
anyway,
so
you're,
just
adding
an
extra
call
unnecessarily,
but
another
area
that
we
we
can
use
tokens
for
is
authorization
based
on
roles
in
groups.
A
So
I
can
ask
for
I
can
define
a
role
for
my
application
and
I
can
put
that
role
into
into
the
into
my
app
and
assign,
and
users
and
groups
can
be
assigned
to
those
roles
and
I'll
get
a
role
claim.
In
my
token,
or
I
could
ask
to
see
the
group
membership,
you
know
what
member?
What
groups
is
this
user,
a
member
of
etc?
A
And
I
can
get
asked
to
see
that
in
my
in
my
token,
so
normally
this
is
pretty
good,
because
you
end
up
with
a
new
token
every
hour,
but
when
you
start
adopting
continuous
access
evaluation
at
the
moment,
those
tokens
will
be
will
be
sitting
in
your
cache
for
up
to
a
day.
So
now,
if
the
user
changes
roles
in
the
middle
of
the
day,
you
might
need
your
token
won't
reflect
that
until
you
go
ahead
and
get
that
new
token.
A
I
should
consider
whether
I
should
continue
to
use
my
client,
my
claims-based
authorization,
because
it's
in
the
token
or
whether
I
should
switch
to
using
something
like
microsoft
graph
instead
now,
whenever
I
use
group
token,
a
group
claims.
In
my
token,
I
have
to
implement
the
microsoft
graph
fallback
because
of
the
overage
that
can
happen
when
I
have
groups.
A
So
it's
something
to
consider
as
you
go
to
adopt
continuous
access
evaluation
is,
you
know,
are,
am
I
getting
authorization
things
in
my
token
and
how
will
that
be?
If
the
token
has
a
24
life
period
to
it,
and
it
goes
stale
now
we
are
looking
and
working
toward
creating.
Probably
a
handling
group
changes
in
continuous
access
evaluation.
It's
on
our
list.
I
just
don't
have
a
tight
date
and
time
when
that
might
be
might
be
available.
B
B
So,
ultimately
you
need
to
validate
the
signature,
and
in
order
to
do
that,
you
need
access
to
the
signing
keys
and
if
those
signing
keys
are
not
part
of
the
token
itself,
then
you
need
to
go
ahead
and
fetch
it
from
the
openid
connect,
metadata
document
or
the
discovery
endpoints
for
the
identity
provider.
So
a
microsoft
identity
platform
does
go
ahead
and
host
the
metadata
discovery
document
on
an
open,
endpoint
on
a
pertinent
basis
and
also
from
a
platform
specific
standpoint.
B
B
This
can
be
custom
built
apis
that
you're
going
to
do,
and
this
api
is
going
to
go
ahead
and
fetch
this
metadata
and
go
ahead
and
cache
it
in
its
memory
or,
let's
say
persistent,
cache
based
on
a
certain
logic
and
then
going
to
use
it
to
validate
the
tokens
that
it
gets
every
single
time
now.
The
point
is
in
order
to
make
sure
that
we
don't
run
into
issues
with
respect
to
this
mechanism.
B
So,
yes
from
a
resiliency
standpoint,
ca
is
going
to
help
you
so
that
you
don't
need
to
go
and
talk
to
azure
id
often
and
we
extend
the
lifetime
so
that,
instead
of
talking
to
azure
id
24
times
in
a
single
day,
you're
only
going
to
go
ahead
and
talk
to
it
once
and
get
a
token
and
give
it
to
the
api
and
the
api
will
go
ahead
and
worry
about
getting
an
event.
In
case
of
a
certain
critical
change
as
kyle
mentioned,
but
then
what
about?
B
If,
let's
say
the
there
is
an
issue
in
the
metadata
refresh
document
policy
itself?
Let's
say
due
to
certain
outage
scenario:
let's
say
we
have
been
forced
to
go
ahead
and
change
the
signing
keys
on
an
emergency
basis,
let's
say,
for
example,
the
application
did
not
go
ahead
and
handle
the
metadata
caching
in
a
proper
way,
where
we
have
seen
certain
instances
that
has
happened
in
the
past,
wherein
the
whole
mechanism
going
ahead
and
fetching.
This
did
not
work
and
that
basically
caused
a
lot
of
application
issues
from
an
uptime
standpoint.
B
So
that
is
this
guidance.
So
what
do
you
do?
Or
how
can
you
go
ahead
and
handle
this
in
terms
of
the
microsoft
identity
model,
the
set
of
libraries
that
we
have
make
sure
that
we
explicitly
utilize
the
microsoft
identity
model
version
starting
7,
which
has
a
protection
wherein
what
you
see
here
is
that
hey
in
an
asp.net
core
application
when
you're
instantiating
the
authentication
middleware
just
make
sure
to
go
ahead
and
have
refresh
on
issuer
key
not
found
set
to
true.
B
So
what
we
go
ahead
and
say
is
if
at
all,
you're
getting
a
token
for
which
the
key
is
not
found
in
the
metadata
cache
for
your
application.
Consider
the
current
cache
invalid
go
ahead
and
fetch
a
brand
new
metadata
from
azure
ready
endpoint.
So
that's
what
this
particular
line
item
does.
Similarly
from
an
asp.net
or
oven,
middleware
standpoint,
it's
a
hard
coded
value.
So
the
open
middleware
at
this
point
of
time,
when
integrated
with
microsoft,
identity
platform
that
is
azure
active
directory
authentication
system.
B
B
B
Make
sure
that
you
do
this
process
only
once
in
five
minutes,
so
that
your
application
is
not
going
ahead
and
trying
to
go
ahead
and
hit
the
service
continuously.
If
at
all,
just
to
go
ahead
and
get
rid
of
a
transient
problem.
Maybe
you
tried
it?
You
did
not
get
a
response
because
of
a
throttling
or
something
just
wait
for
five
minutes,
just
sleep
for
five
minutes
and
try
to
go
ahead
and
get
the
metadata
again
after
that,
following
the
same
logic,
to
go
ahead
and
have
a
better
success
rate.
B
So
this
is
exactly
the
same
mechanisms
that
we
recommend
our
internal
teams,
our
first
party
applications
like
exchange,
sharepoint
and
all
of
those
azure
services
to
go
ahead
and
follow
and
fetch
it,
and
this
is
exactly
the
same
guidance
that
we
say
if
at
all,
if
you're
using
a
custom
mechanism
in
any
of
your
applications.
Again,
if
any
of
you
are
using
our
asp.net
middleware,
if
you're
talking
about
using
owen,
they
have
their
own
mechanisms
of
handling
it.
B
B
There
is
no
corruption
in
the
data
and
if
it
is
corrupted,
if
you're
not
able
to
pass
the
json
format
by
syntax,
discard
it
and
go
ahead
and
start
the
process
again
after
five
minutes
and
make
sure
that
once
you
are
able
to
format,
identify
the
key
endpoint.
So
the
metadata
format
is
part
of
the
rfc.
It
has
a
specific
format
and
there's
going
to
be
a
url.
B
That's
going
to
say,
hey
here
is
where
all
the
signing
keys
are
stored
and
inside
that
generally,
we
have
three
keys
at
any
given
point
in
time
at
minimum
two,
at
least
so
make
sure
you're
able
to
find
one
key
and
store
it
into
a
cert
object
and
make
sure
that
it's
a
valid
public
search.
So
those
are
the
things
that
you
can
go
ahead
and
do
from
your
application.
Web
app
slash
web
api
end
when
doing
manual,
token
validation.
So
let's
say
your
ram
you're,
not
using
any
of
our
native
libraries.
B
You
are
doing
the
heavy
lifting
in
terms
of
going
ahead
and
validating
the
metadata,
validating
the
tokens
and
doing
everything.
This
is
a
logic
that
can
go
ahead
and
help
you
minimize
the
downtime
in
terms
of
the
application
when
you're
facing
issues
with
the
whole
token
validation
logic.
Now,
with
this,
let's
directly
jump
onto
the
token
validation
scenario,
so
token
validation
is
key
in
terms
of
the
whole
resiliency
piece.
B
So,
as
I
said
right
when
you're
talking
about
having
an
application
calling
an
api,
the
first
thing
that
we
want
to
go
ahead
and
say
is
on
a
client
application
application
that
is
running
on
a
desktop
application
that
is
running
on
a
browser
application.
Let's
say
that
is
running
purely
on
a
native
client
that
is
like
a
mobile
phone.
B
Do
not
go
ahead
and
perform
a
direct
signature,
validation
or
any
of
that,
if
at
all,
if
you
want
to
fit
some
artifacts
from
the
token
feel
free
to
do
that,
let's
say
you
want
a
name
and
so
on
absolutely
cool.
But
then
there
is
no
additional
benefit
that
you're
going
to
go
ahead
and
get
when
you're
doing
validation
on
a
client,
and
why
is
that
I'll
come
to
it?
B
The
actual
validation,
the
minimum
validation
that
you
need
to
do
is
at
the
web,
app
slash
web
api
layer,
wherein
you
got
a
request
to
your
app.
You
have
processed
the
metadata
refresh
logic
and
you
have
the
keys
the
the
discovery,
endpoint
keys
and
you've
cached
the
valid
keys
by
following
the
previous
logic.
Now,
you've
gotten
a
token,
and
now
you
need
to
make
sure
that
you
confirm
the
token
is
not
hampered
with
the
token
signature
matches
so
that
you
know
that
azure
ready
gave
the
token
to
the
client.
B
B
For
some
reason,
then,
yes,
you
can
perform
the
signature
validation
to
this
and
again
we
go
ahead
and
document
all
the
values,
payload
data
that
we
go
ahead
and
publicize
on
hey.
This
is
the
format
of
an
id
token
and
what
are
the
values
that
we,
as
microsoft,
send
in
an
id
token
and
an
access
token
in
this
reference
article?
B
Just
allow
the
user
to
sign
in
because
you
have
a
direct
line
of
site
and
if
at
all,
if
any
malicious
actor
can
compromise
it,
he
is
going
or
he
or
she
is
going
to
compromise,
not
only
the
token
but
also
the
whole
signing
process
as
well.
Then
he
can
go
ahead
and
intercept
a
brand
new
key
for
you
so
that
he
can
spoof
you
into
thinking
hey.
This
token
is
correct
because
it
is
signed
by
a
correct
key,
whereas
the
key
is
malicious
at
that
point
of
time.
B
So
that's
the
whole
idea,
but
if
at
all
let's
say
we
are
talking
about
the
confidential
client,
what
do
we
want
to
do?
So?
You
are
in
a
scenario
where
you
do
want
to
go
ahead
and
validate
an
id
token.
Then
validate
the
audience
claim,
meaning
hey.
I
am
application,
a
I'm.
Getting
an
id
token
validate
the
audience.
Value
includes
the
client
id
of
my
application,
so
somebody
is
not
giving
me
an
id
token
that
was
got
for
some
other
application.
That's
rule
number
one
rule
number
two
is
validate
the
lifetime.
B
B
It's
a
security
mechanism
in
terms
of
let's
say
where
the
application
goes
ahead
and
uses
a
specific
random
value
in
terms
of
it
when
requesting
a
token,
so
that
we
inject
it
into
the
token
as
well,
so
that
you
can
identify
as
an
application
or
as
an
app
that
hey
kyle
go
ahead
and
send
me
this
token
at
x
or
at
point
y
with
the
nonce
abc
now
am
I
getting
the
same
token
again
with
the
same
nonce?
If,
yes,
I
as
an
application,
can
go
ahead
and
take
decisions
to
deny
this
particular
token.
B
So
there
is
guidance
in
terms
of
how
you
can
go
ahead
and
handle
the
nonce
claim,
but
that's
purely
at
the
application
layer.
It's
not
that
you're
going
to
go
ahead
and
have
native
token
replay
token
theft
protection,
that's
proof
of
position,
but
this
is
native
capability
that
we
have
as
of
today
as
how
applications
can
maintain
a
database
store.
The
nonce
values
understand
that,
if
announce
is
being
repeated,
maybe
a
token
is
being
replayed
and
then
you
can
take
a
call
to
whether
deny
it
or
approve
it
as
an
additional
authorization
and
last
part.
B
I
know
that
we
just
have
six
minutes
left.
So
that's
the
reason
I
just
want
to
quickly
go
through
it
and
have
at
least
a
couple
of
minutes
in
the
end.
So
the
last
part
of
what
we're
going
to
go
ahead
and
talk
about
today
is
access
token.
So
this
is
the
main
piece
of
it.
So
this
is
what
enables
a
client
to
go
ahead
and
access
a
secure
resource
and
client
application
should
not
worry
about
an
access
token.
It
should
consider
it
or
back
simple
reason
being
as
microsoft.
B
We
can
go
ahead
and
choose
to
encrypt
it
tomorrow
and
there
is
nothing
stopping
us
from
doing
it,
because
there
isn't
any
exact
specification
like
how
we
have
in
saml
payloads,
like
hey
an
access
token
that
is
coming
from
an
over
to
compliant
idp,
should
be
in
this
format.
There's
nothing
of
that
sort.
It's
just
an
agreement.
Microsoft
can
go
ahead
and
change
that
agreement
any
time
and
say
we
are
going
to
encrypt
it
and
the
client
application
will
start
breaking
so
don't
just
get
for
an
access
token.
B
C
B
Ahead
and
get
the
metadata,
it
will
go
ahead
and
perform
the
signature,
validation
and,
after
that
it
is
expected
to
go
ahead
and
do
these
checks
at
minimum
make
sure
that
again,
the
audience
is
correct.
Your
graph
api
make
sure
that
you're
getting
a
token
with
audience
as
graph
api.
If
you
are
api,
a
you
need
to
make
sure
that
you
get
an
access
token
with
an
audience
of
api
the
issuer.
So
this
is
something
that
is
significant
to
applications
simply
because
you
decide
hey.
This
is
an
app.
B
I
only
want
to
allow
my
company
users
logging
in
or
do
I
want
to
go
ahead
and
allow
anybody
from
logging
in
or
do
I
have
a
specific
list
of
tenants
that
I
want
to
allow
like
company
a
company
b
company
c.
This
is
the
value
that
allows
you
to
go
ahead
and
do
that
like
you're,
going
to
go
ahead
and
get
the
tenant
identifier
and
you
can
go
ahead
and
decide
hey.
This
is
my
tenant
id
and
hence
the
user
is
logging
in
from
my
company
or
my
tenant
and
I'm
going
to
allow
them.
B
But
if
you
see
any
other
value
or
a
value
that
you
do
not
trust,
you
can
go
ahead
and
choose
to
take
a
call
saying:
don't
allow
access
to
the
app
slash
api
again.
The
lifetime
and
nons
are
similar
in
terms
of
it,
wherein
you're
going
to
do
the
same
validation
and
from
a
non-standpoint.
As
I
mentioned,
you
as
an
application
developer
need
to
have
additional
validation,
additional
storage
of
the
nonce
values
to
identify
a
token
is
being
replayed
for
that
to
go
ahead
and
work
again.
B
I
will
go
ahead
and
put
a
quick
link
on
that
in
terms
of
talking
about
how
exactly
you
can
implement
it
in
our
libraries
and
what
exactly
is
the
guidance
that
you
as
an
application
developer
needs
to
follow
for
that
and,
finally,
the
most
important
aspect
look
for
scopes
or
roles.
So
this
is
an
access
token
you're
going
to
go
ahead
and
have
certain
roles
such
as
hey
the
user.
Who's
logging
in
is
a
simple
user.
B
The
user
who's
logging
in
as
an
administrator,
the
user
who's
logging
in
is
a
tier
one
or
a
tier
2
admin,
or
he
can
have
scopes
like
how
we
have
scopes
in
graph,
that
is,
user
dot,
read
user
dot,
read,
write
and
so
on.
So
it
can
be
our
first
party
apis
or
it
can
be
even
your
apis
that
you
build,
for
which
you
can
define
scopes
and
read
the
scopes
from
the
access
token,
and
let
the
user
know
that.
B
Okay,
you
have
a
scope
of
read,
only
I'm
not
going
to
go
ahead
and
let
you
write
for
this
particular
application
for
this
particular
api.
With
that
this
is,
let's
say
for
advanced
scenarios.
Let's
say
the
capability
that
we
have
in
open,
where
we
go
ahead
and
perform
native
signature,
validation
and
native
audience,
validation
and
issuer
validation
as
well.
Let's
say:
you're,
not
okay.
B
With
that
you're
building
a
multi-donand
application,
then,
yes,
you
need
to
use
the
microsoft
identity
model
to
extend
the
validation
logic,
and
we
have
a
full-fledged
github
sample
that
we
have
written
in
an
asp.net
scenario,
saying
hey
if
you're
using
asp.net
and
you're,
using
our
libraries
to
go
ahead
and
login.
But
then
you
want
custom
validation
of
tokens.
You
have
a
special
logic.
Here
is
a
sample
that
we
basically
use
this
particular
class
to
extend.
We
pass
the
token
and
then
we
go
ahead
and
implement
our
validation,
our
custom
validation.
B
B
B
B
Again,
but
just
a
quick
recap:
the
idea
is,
as
a
web
app
slash
web
api
make
sure
you
have
a
resilient
way
of
going
ahead
and
getting
the
metadata
once
you
get
the
metadata
when
you're
getting
an
access,
token
make
sure
that
you're
able
to
go
ahead
and
validate
the
issuer
audience
if
the
default
validation
is
not
enough.
Use,
customize,
custom,
token
validation,
so
that's
the
gist
of
it
and
I'll.
Let
a
stephen
go
ahead
and
just
give
a
close
out
and
then
we'll
definitely
hang
out
for
a
couple
more
minutes
as
well.
C
Thank
you,
harish
and
thank
you
kyle
and
thank
you
everyone
for
joining
us
today.
I
really
appreciate
it
if
you
can
take
a
few
minutes
to
fill
out
the
survey
that
I
just
posted
in
the
chat
window.
That
will
be
great.
That
will
give
us
feedback
on
these
calls
and
also
it
gives
you
an
opportunity
to.
Let
us
know
what
other
topics
you
would
like
us
to
cover.
C
So
if
you
have
any
ideas
for
a
next
month's
call
or
future
calls,
that
is
really
welcome
to
us.
So
thank
you
very
much.
The
recording
will
be
posted
next
week.
You
can
follow
us
in
our
twitter
channels
that
I
just
posted
in
the
chat
window
and
we'll
let
you
know
when,
when
those
are
posted,
so
thank
you
have
a
great
day.