►
From YouTube: Increase resilience of authentication and authorization applications you develop–February 2021
Description
This month’s featured topic: Increasing the resilience of the authentication and authorization applications you develop. 2 scenarios discussed - Apps that sign in users and Apps without users. Bottom line - use MSAL. Fundamentally, the frequency of making token calls affects your application’s resiliency. MSAL makes your apps more resilient by proactively refreshing tokens at the right time. General recommendations - develop apps that are Continuous Access Evaluation (CAE) ready, serialize and persist tokens, acquire tokens silently, handle service responses properly, use broker authentication on mobile devices, evaluate authorization options. This session delivered by Kyle Marsh (Microsoft) | @kylemar, was recorded on February 18, 2021.
Resources:
• Documentation - Building Resilience into identity and access management with Azure Active Directory | Building resilient identity and access management with Azure Active Directory | Microsoft Docs
• Documentation - Build resilience in your identity and access management infrastructure | Build resilience in your IAM infrastructure with Azure Active Directory | Microsoft Docs
• Documentation – Build resilience in your customer identity and access management with Azure Active Directory B2C | Build resilience in Customer Identity and Access Management using Azure AD B2C | Microsoft Docs
• Documentation – Increase resilience of authentication and authorization applications you develop | Increase resilience of authentication and authorization applications you develop - Microsoft identity platform | Microsoft Docs
• Documentation - How to use Continuous Access Evaluation enabled APIs in your applications | https://aka.ms/clientcae
Stay connected:
• Twitter https://twitter.com/microsoft365dev
• YouTube https://aka.ms/M365DevYouTube
• Blogs https://aka.ms/M365DevBlog
• Recurrent Invite https://aka.ms/IDDevCommunityCalendar
A
We're
going
to
cover
increasing
resiliency
of
the
applications
that
you
build.
This
is
actually
part
of
a
broader
initiative.
We've
had
a
little
while
ago
of
how,
in
general,
you
can
build
around
azure
active
directory
with
resiliency
in
mind.
We
actually
have
three
broader
topics
within
that
category.
A
A
You
know
as
an
application
developer,
both
as
a
service
or
as
a
as
a
client
app
your
real
transaction.
You
have
available
to
you
with
respect
to
how
you
interact
with
microsoft.
Identity
is
getting
a
token,
so
at
the
top
tier
it's
a
pretty
straightforward
concept.
You
need
to
ask
it
for
a
token
from
us.
You
either
get
it
and
can
proceed
or
you
don't
get
it
and
therefore
you
would
handle
that
failure
gracefully
with
whatever
fallback
has
to
happen.
A
But
how
can
you
be
resilient
to
any
kinds
of
interruptions
that
might
happen
between
you
and
getting
that
token,
maybe
there's
a
net
for
infrastructure
issue.
Maybe
there's
a
an
issue
on
our
side
with
respect
to
our
service,
maybe
there's
something
in
between
that's
going
on
and
obviously
we
want
your
application
to
be
able
to
work
and
keep
keep
working
throughout
any
kinds
of
of
any
of
those
kinds
of
of
interruptions.
A
So
the
first
bit
of
advice
is
something
pretty
generic
for
us
really
and
that
is
wherever
possible.
You
should
use
our
microsoft
authentication
libraries,
because
we
do
a
lot
of
the
best
practices
that
we're
going
to
talk
about
throughout
the
rest
of
the
session.
We
we
already
do
inside
of
our
m
cell
applications.
A
Options
of
where
you
do
your
token
cache
in
store,
we
provide
guidance
on
how
the
to
best
integrate
with
those.
So,
for
example,
on
the
asp.net
core
side,
we
have
a
number
of
different
strategies
you
can
use
for
with
respect
to,
storing
and
and
caching.
Your
tokens
now
what's
interesting
about
msol
is,
as
it
evolves
it's
becoming
more
and
more
going
past,
just
sort
of
straight
protocol
level,
things
with
respect
to
best
practices
and
picking
up
more
kinds
of
optimizations
around
microsoft
identity,
and
this
includes
some
specific
ones
around
resiliency.
A
Now
we're
always
trying
to
be
more
performant
and
and
have
new
capabilities,
but
were
there
also
some
specific
things
that
we're
doing
that
mso
will
understand
with
respect
to
how
to
make
your
app
more
resilient.
The
first
one
is
something
called
proactive
token
refresh
now
with
various
new
functionality.
That's
coming
up
things
like
continuous
access
evaluation.
A
What
we
can
do
with
a
managed
service
id
manage
identity
for
azure
resources.
We
have
found
that
we're
able
to
extend
our
token
lifespan.
So
as
a
developer,
of
course,
you
never
will
know
exactly
how
long
a
token
we
issue
will
be
valid
for
until
you
get
the
token
right.
So
you
should
never
count
on
us
being
an
hour
long
token
or
a
five
minute
token
or
a
two
day
token.
Or
what
have
you
obviously
we'll
issue
the
tokens
appropriately,
given
the
situation
and
the
circumstances?
A
So,
instead
of
waiting
until
the
end
of
the
token
lifespan,
we
as
a
service
can
send
you
an
msol,
a
notification
that
says
hey
I've.
Given
you
a
24-hour
token,
why
don't
you
go
ahead
and
try
to
refresh
that
token
in
12
hours
now
the
nice
thing
about
that
is.
If
I
use
a
standard,
I'm
you
know
at
the
at
the
end
of
the
token
lifespan,
I
need
to
get
a
token
within
a
few
minutes
in
order
to
continue
working.
A
A
Your
application
now
has
12
hours
to
complete
a
token
refresh
now,
obviously,
most
of
the
time
that's
moments
not
not
hours,
but
it
does
mean
that
if
there
was
any
particular
glitch
in
the
network
or
some
issue
between
you
and
your
token,
if
you
will,
during
that
initial
request,
you've
got
more
time
in
which
case
to
to
pick
that
up
to
actually
get
a
fully
refresh
the
token.
So
a
proactive
token
refresh.
A
Another
big
area
for
resiliency
is
we've
already
talked
about
very
very
briefly
in
a
couple
of
blog
posts
by
nadeem,
our
our
vp
about
another
azure,
ed
backup,
authentication
service
that
we
have
under
construction
right
now.
This
backup
authentication
service
will
usually
kick
in
completely
silently
and
automatically
and
nothing
you
need
to
do
to
your
application.
It
comes
into
play
and
when
that's
the
situation,
everything
will
just
work.
However,
there
is
a
situation
where
we
want
to
have
the
backup
service
in
place.
Should
your
primary
path
to
azure
ad
somehow
get
interrupted.
A
So
there's
another
big
resiliency.
So
if
there
was
anything
problematic
in
accessing
to
the
primary
service
and
even
the
the
the
gateway
in
front
of
the
primary
service
that
makes
that
decision,
then
emsa
will
have
a
an
understanding
of
how
to
how
to
fall
back
to
the
backup
again
automatically
so
using
our
msol
or
microsoft.
Authentication.
A
So
so
the
next
thing
is
I
do
want
to
highlight,
and
I'm
going
to
bring
this
forward
because
we're
going
to
do
a
little
demo
and
it
takes
a
takes
a
few
minutes.
So
I
want
I
do
want
to
talk
about
continuous
access
evaluation.
I
did
have
a
session
in
more
detail
on
continuous
access
a
little
while
ago.
That
should
be
up
on
the
up
on
our
published
sites
somewhere.
But
let
me
reiterate:
continuous
access
evaluation
because
it
really
is
a
an
enormous
capability.
A
A
First,
the
api
itself
is
going
to
register
in
order
to
get
events
from
azure
ad
microsoft
identity
directly
to
the
api
about
the
state
of
any
access
tokens
that
have
been
issued
for
the
api
that
are
currently
out
in
the
world
valid.
So
if
I,
if,
if
you're
an
api,
you
can
register
that
you're
an
api
and
then
you'll
be
able
to
at
some
point
be
able
to
get
from
us
signals
that
say
hey.
I
issued
a
token
for
your
api
an
hour
ago.
A
Please
don't
accept
that
token
anymore
or
I
issued
that
token
a
few
hours
ago.
Please
don't
accept
those
tokens
anymore,
we'll
go
ahead
and
signal
your
api
directly,
so
the
first
two
components
are
microsoft,
identity
and
the
api
working
in
in
in
conjunction
to
determine
what
the
validity
of
a
particular
token
is.
So
we
issue
json
web
tokens
for
as
access
tokens
to
apis
they're,
normally
good
until
they
expire
so
they're
good
for
as
long
as
the
lifespan
of
the
token
is
there.
A
But
this
opera
gives
us
an
opportunity
for
the
microsoft
identity
to
talk
to
the
api
implementation
directly
and
say:
yeah.
Don't
accept
that
token
anymore?
Now
we
don't
have
a
way
for
you
as
an
api
designer,
yet
a
developer
to
be
part
of
this
process.
We
are
participating
in
something
called
the
shared
signals
and
events
working
group,
and
you
can
see
our
link
to
that
here
on
the
page.
A
That's
not
a
link
to
us,
but
to
a
working
group
where
they're
going
to
standardize
that
connection
between
an
identity
provider
and
an
api
implementation
or
resource
so
that
these
signals
can
be
shared
and
there'll,
be
a
standard
way
to
talk
to
the
services,
the
standard's
not
quite
ready,
but
we're
going
ahead
and
implementing
it
across
our
own
apis
to
begin
with.
So
as
soon
as
those
standards
are
in
better
shape
or
a
little
more
mature,
really
they're
in
good
shape,
but
and
the
more
mature
you'll
be
able
to
start
participating
as
an
api
developer.
A
The
third
piece
is
the
client
application
itself.
The
client
application
has
to
be
changed
because
it's
now
going
to
get
a
rejection,
an
unauthorized
response
to
an
api
call
when
the
client
has
what
it
believes
is
a
perfectly
valid
json
web
token
in
hand
you,
you
know
the
the
token
response
we
gave
said
it
was
good
for
an
hour
or
24
hours,
so
it
should
still
be
good,
so
the
client
actually
has
to
listen
and
when
it
could
do
that
that
that
listen,
hey,
I'm
gonna.
A
When
you
call
the
api,
the
api
may
say,
I'm
no
longer.
Accepting
that
token,
your
access
token
anymore,
the
client
will
understand
and
know
it
needs
to
go
back
and
ask
for
another
access
token.
So
we
need
the
clients
to
be
updated
and
we
have
some
guidance
on
the
second
link
you
see
here
on
the
page.
A
A
So,
instead
of
having
you
come
back
to
the
system
every
hour
for
a
new
access
token,
so
you
so
in
a
normal
working
day,
you
have
to
go
eight
times
for
someone
who's
using
your
app
all
day.
Now
you
only
have
to
go
once
because
that
token's
good
for
the
entire
entire
working
period
or
in
a
full
24
or
28
hours
of
the
day
and
again
the
msol
will
understand
that
when
the
server
can
give
it
the
right
signals,
we
could
even
go
ahead
and
proactively
refresh
that
token.
A
B
A
Some
questions
so
yeah
we
can't
support
the
idea
of
of
azure
active
directory.
Supporting
introspection
is
just
too
expensive
for
everybody.
You
know
every
time
you
call
graph
api
or
every
time
well,
graph.
Api
is
different,
but
every
time
we
call
one
of
your
apis
to
require
introspection.
It
is
a
very
expensive
process
and
therefore
would
slow
everything
down.
So
that's
why
we're
we're
not
looking
to
implement
token
introspection
ever.
A
A
Let's
take
a
quick
look
at
continuous
access
evaluation,
so
I
have
a
very
simple
application
here,
but
I
had
a
very
simple
application
here.
Let
me
bring
it
up,
let's
go
ahead
and
start
this,
so
it's
a
very
simple
app
and
I'm
just
going
to
do
a
couple
of
things
with
it
to
start:
let's
bring
it
over.
A
So
we'll
sign
in
here
and
single
sign-in
kicked
in,
so
I'm
using
a
special
user
called
test
cae
and
here
I'll
make
a
profile
api
call.
So
microsoft
graph
is
not
quite
in
private
preview.
Yet
so
it's
it's
one
of
the
apis
that
that
will
be
supporting
this
over
time,
but
I
can
show
you
that
it's
sort
of
half
implemented
today
my
test
tenant,
is
in
the
the
dem
in
the
early
group
access
to
this
capability,
and
I
want
you
to
note
that
token
expires
time
frame.
A
On
the
token
we
just
got
so
it's
about
half
past
the
hour
25
past
the
hour,
but
notice
that
it's
going
to
expire,
not
at
10,
10,
10,
30
or
10
25
today,
but
rather
9
25
ish
tomorrow
so
effectively.
I
have
a
24
hour
token
here
I'll
do
our
outlook
apis
as
well
just
to
show
you
another
api.
That's
also
enabled-
and
I
get
a
similar
results.
The
token
is
good
until
tomorrow
and
and
I
can
go
ahead
and
and
get
that
token-
it's
good
for
a
long
time.
A
So,
let's
take
a
few
minutes,
but
let
me
go
ahead
here
and
first
I
want
to
show
you
at
least
some
of
the
code
that
comes
into
play
here,
so
we
do
a
normal
access
token.
Whenever
we're
about
to
call
a
microsoft
graph,
api
or
any
other
api,
we
go
ahead
and
do
a
normal
flow.
If
you
will
to
get
an
access
token.
First
off,
we
attempt
to
acquire
token
silent
and
if
that
fails
specifically
with
something
like
user
ui
required,
then
we
go
back
and
acquire
a
token
interactively
passing
along.
A
What's
called
a
claims
challenge
that
might
have
come
back
from
the
initial
token
choir
token
silent
call
that
claims
challenge
makes
it
so
we
so
our
application
would
be
handled
to
handle,
say
the
need
for
interaction
because
of
some
conditional
access
policy
or
something.
So
that's
the
standard
pattern
you
would
use.
This
is
a
little
net
desktop
application
to
acquire
a
token
before
I
call
say
microsoft
graph,
what's
going
to
happen
where
it
becomes
interesting
is
when
I
use
that
token
down
here
to
call
my
api.
A
A
A
And
if
that's
the
case,
then
my
application
needs
to
go
back
and
access
a
get
an
access
token
again,
but
this
time
with
a
claims
challenge.
So
all
that's
going
to
happen
is
we're
going
to
take
our
claims
challenge,
which
we
got
off
of
the
response
to
the
call
to
the
api
we
decoded
it
and
then
we're
going
to
pass
it
back
to
acquire
token
silent,
but
now,
right
in
at
a
quiet
token
silent.
A
We
have
our
claims
challenge
to
tell
microsoft
identity
the
nature
of
why
this
an
additional
token
is
being
required
at
this
time.
If
that
fails,
and
most
of
the
time
acquire
token
sign,
that
probably
will
fail
may
be
a
little
bit
overstating,
but
certainly
if
I've
done
something
like
revoke
all
the
user
sessions,
we're
not
going
to
acquire
acquire,
let
the
token
be
acquired,
silently
we're
going
to
require
user
interaction
and
then
again
I'll
use
that
same
claims
challenge
to
make.
That
call
back.
A
So
that's
the
kind
of
code
that
we
need
to
go
I'm
going
to
let
this
sit
for
just
a
minute,
because
it
takes
five
or
six
minutes
for
us
to
get
our
to
get
our
continuous
access
evaluation
working
right
now,
but
we'll
we'll
move
on
we'll
come
back
to
the
take
a
look
at
that
result
in
just
a
minute.
I
see
there
is
a
question
here:
does
msull.js
have
the
continuous
access
of
ability
I
will
check,
but
I
believe
it
does
it's.
A
A
Therefore,
we
can
issue
a
cae
token
to
you
so
that
that's
really
the
the
part
where
msol
needs
to
understand,
as
well
as
handling
the
the
claims
challenges
so
looking
at
now,
if
you're
not
using
msol
and
you're
doing
other
kinds
of
things.
Oh,
I
got
another
question:
let's
see,
is
there
an
out
of
box
adel,
the
msul
converter?
A
We
do
have
some
sample
code
and
some
guidance
on
moving
from
a
delta
msol,
but
we
don't
have
any
tool
that
would
just
change
your
code
for
you
so
back
on
the
resiliency
side,
so
we
do
have.
If
we're
not
using
msul,
there
are
some
additional
guidances.
We
can
provide
you
just
for
the
sake
of
of
also
increasing
your
resiliency.
The
first
part
is
doing
making
sure
that
you
use
a
token
for
as
long
as
it's
good.
A
You
should
never
try
to
look
inside
of
an
access
token
that
we
give
you
you
know
open
it
up,
see
the
the
expiration
time
in
the
token
and
and
work
from
that,
make
sure
you
always
work
from
in
the
token
response.
Whenever
we
give
you
an
access
token,
we
tell
you
when
that
token
expires
right
in
that
response,
and
and
that's
the
data
that
you
should
be
using
to
drive
your
your
token
caching
lifespan
and
how
long
you'll
catch
those
tokens
a
couple
of
things
here.
A
The
so
the
reason.
Well,
I
think
the
question
is:
why
wouldn't
you
want
to
open
the
token
well
to
begin
with?
We
might
start
encrypting
those
tokens,
so
you
wouldn't
want
to
to
do
that
if
an
attacker
were
to
change
the
token
expiration
in
your
response,
it
really
is
not
that
big,
an
issue,
because
the
token
is
valid
as
long
as
the
token
is
valid.
A
In
addition
to
caching
the
token
just
say:
caching,
those
those
access
tokens
securely,
you
also
should
be
securely
serializing.
Your
tokens
remember
the
token
is
good
for
as
long
as
it's
valid
right.
So
if
I
issue
an
hour
token,
the
user
stops
your
application
starts
it
up.
Five
minutes
later,
you
have
a
perfectly
good
access
token.
You
shouldn't
go
off
and
get
another
token
again,
the
more
times
you
go
back
and
ask
for
tokens
the
more
opportunity
you
have
to
not
be
resilient,
because,
oh,
I
didn't
store
the
token.
A
The
user
started
the
app
five
minutes
later
and
now
there's
something
wrong
with
the
network
or
that
token
response
isn't
coming
back
quickly
and
and
now
my
app's
not
working
when
it
it
could
have
worked.
Just
fine
if
you
had
just
serialized
your
your
access
tokens
more
to
the
point,
of
course,
is
for
our
refresh
tokens.
A
Refresh
tokens
are
valid
for
days,
not
hours
right,
so
it's
perfectly
sensible
that
user
signs
out
of
the
application
in
the
more
in
the
evening
comes
back.
The
next
day,
signs
into
starts
up
your
application
again
or
starts
up
their
machine
again.
You
should
be
able
to
pick
up
the
refresh
token
silently
acquire
a
token
and
off
you
go
now.
That
sounds
like
hey.
I'm
just
doing
the
same
thing
with
a
refresh
token,
but
remember
we're
going
to
a
different
subsection.
A
If
you
will
of
of
the
service,
I'm
not
going
to
the
authorized
endpoint,
I'm
going
to
the
token
endpoint
the
token
endpoint
kind
of
acts
more
like
a
rest
api.
It
is
not
a
bunch
of
ui
involved,
there's
not
a
lot
of
other
components
under
the
covers,
so
the
the
making
sure
that
I
use
these
these
these
silence
options
and
refreshes
can
really
again
help
increase
my
resiliency
to
any
kinds
of
outages
back
on
the
service
side.
A
I
think
andres
is
just
reinforcing
yeah,
so
andres.
I
know
that
it's
technically
possible
that
you
should
look
inside
those
tokens,
I'm
just
vehemently
against
anyone
doing
that.
So
I
understand
that
it's
there
and
that
it's
tempting,
but
even
just
making
a
decision
like
modifying
it
sure
you
can't
do
because
you
know
that'll
be
caught
through
the
signature
validation,
but
even
just
looking
at
it
to
make
a
decision.
A
What,
if
the
api
designer
suddenly
decides,
they
don't
need
that
information
right,
because
you
don't
have
any
control
of
that
token.
You
have
no
idea.
What's
going
to
be
in
that
token,
tomorrow
the
api
designer
could
come
and
say
you
know
what
we're
optimizing.
This
token
we're
taking
out
these
claims.
You
know,
don't
need
these
anymore.
Aren't
we
working
with
them
and
the
next
thing
you
know
your
application
could
end
up
breaking
because
you
have
no
control
over
something
that
you're
asking
for
to
take
that
information
on.
A
So
I
still
am
sort
of
opposed
to
looking
at
tokens
because
of
these
issues.
Now
it
is
also
important
that
you
try
to
use
our
silent
token
acquisition
again.
Our
the
first
pattern
we
ask
for
in
msol
always
is
to
use
acquire
token
silent
first
and
the
reason
for
that
is,
there's
a
whole
bunch
of
things
on
the
back
end
that
don't
have
to
be
up
and
running
if
I
can
acquire
a
token
silently
so,
for
example,
we
always
want
you
to
start
with
if
you're
at
the
protocol
level
prompt
equals
done.
A
That's
what
we
do
with
acquire
token
silent,
because
maybe
there's
an
issue
with
this
particular
users:
getting
an
mfa
prompt
over
their
cell
phone
provider
and
we're
going
to
hit
that
if
we
have
to
have
this
user,
do
an
authentication
which
requires
an
mfa
and
now
I'm
not
just
reliant
on
making
one
network
call
to
get
a
token,
but
I'm
reliant
on
the
user.
I
the
ui,
popping
up
the
the
mfa
service
being
up
the
infrastructure
to
the
phones,
all
being
up
the
response
times,
etc.
A
The
prompt
equals
none
to
begin
with,
whereas
if
you
do
something
a
prompt
equals
login
you're
causing
us
to
have
to
go
through
the
login
prompt,
which
might
mean
off,
we
go
for
an
mfa
and
you're
putting
yourself
effectively
at
the
will
of
the
of
the
the
infrastructure
between
your
user
and
and
their
mobile
device
in
order
to
pull
off
those
various
mfas
and
sure.
Nowadays,
things
are
awfully
reliable.
There's
lots
of
things
there
just
the
more
stuff
you
put
in
the
way,
the
more
chance
that
any
any
link
in
the
chain.
A
If
you
will
is
likely
to
go
down
so
defensively,
you
always
want
to
make
sure
you
use
this
acquired
token
silent
pattern
to
start
with,
and
you
should
really
be
avoiding
prompt
equals
login
and
prompt
equals
consent
if
login
or
consent
is
needed.
We'll
look
after
that.
Your
application
shouldn't
be
saying.
Well,
I
need
prompt
equals
consent,
which
means
we're
going
to
have
to
prompt
the
user
for
consent
when
we
might
not
have
had
to
so
always
do
those
silent
acquisitions
to
begin
with.
A
Now,
when
you
go
ahead
and
make
a
a
request
of
us,
you
do
need
to
handle
those
responses
correctly.
Now
emsa
will
do
some
of
this.
For
you,
this
applies
both
to
microsoft
graph
and
to
microsoft,
identity
as
well.
You
have
to
look
out
in
case
we
we
we're
sending
you
a
429,
meaning
that
we're
going
to
throttle
you
or
we're
spending
you
a
response
code.
We
do
have
a
retry
after
header.
We
would
give
back.
So
if
you
tried
to
do
an
authentication
and.
A
Issue
we're
going
to
give
back
a
retry
after
you
need
to
honor
that
retry
after
we've
seen
no
too
many
applications
who
they
get
that
error
and
they
immediately
retry.
In
fact,
sometimes
they
try
to
pick
up
the
pace
and
retry
as
fast
as
they
possibly
can,
because
they
just
feel
they
have
to
get
that.
You
know
get
their
retry
in
the
problem.
A
So
always
make
sure
you,
you
honor
the
retry
after
header,
a
response
that
we
give
you
so
if
we
say
hold
off
for
3
seconds
or
30
seconds
or
whatever
it
is
hold
off
for
that
time.
If
we
didn't
provide
a
retry
after
so,
supposing
you
know,
there's
some
issue
bad
enough
that
that
that
that
doesn't
even
show
up,
then
you
should
use
an
exponential
back
off
algorithm,
go
ahead
and
retry.
A
We
do
offer
a
broker
model,
so
there's
the
authentication
broker.
It's
either
the
authenticator
app
on
ios
or
android,
or
the
company
portal
app
on
android,
where
we
send
the
authentication
first
to
the
broker,
rather
than
directly
to
azure
ada.
First,
this
helps
because
these
brokers
know
how
to
get
something
called
a
primary
refresh
token
and
because
it
has
the
primary
refresh
token,
we
can
cut
down
on
how
many
what
we
would
refer
to
as
fresh
authentications
are
needed.
A
So
by
cutting
down
again
the
needs
for
these
fresh
authentications,
you
cut
down
the
need
of
the
amount
of
infrastructure
on
the
back
end
or
in
the
service
or
in
the
cloud
that
your
application
is,
is
dependent
on.
So
whenever
you
can,
you
should
try
to
use
one
of
these
brokers.
If
you're
on
one
of
these
native
devices
and
like
I
said
with
msol
a
few
weeks
ago,
adding
the
support
for
the
web
account
manager
wham
on
windows.
Now
it's
also
a
broker
option
for
your
desktop
applications
as
well.
A
I
see
we
do
have
a
comment.
Yes
andres.
I
absolutely
agree.
It's
your
job
to
look
at
id
tokens
for
sure.
So
great
yeah,
I'm
glad
we're
in
agreement.
There
is
the
retry
on
throttle
built
into
msol
itself.
It
we
do.
One
retry
in
most
m
solves
we're
working
on
adding
the
better
capability
there,
but
the
the
installs
today
will
tend
to
do
one.
They
they
honor
the
retry
after
they
try
one
retry
and
that's
it.
So
you
would
have
to
do
some
additional
work
there.
A
A
I
believe
we
still
do
company
portal,
but
only
on
android,
so
they're,
because
on
android
the
the
system
is
a
little
more
open.
They
can
have
multiple
implementations
so,
but
generally
it's
authenticated.
I
will
double
check
to
make
sure
we
we
haven't
changed
that
lately,
but
that's
been
the
process
until
now.
A
Another
thing
is
to
think
about.
When
should
I
use
my
authorization
options?
You
know,
I
have
various
ways.
I
can
get
information
about
authorizing
the
user.
So,
for
example,
I
can
ask
for
optional
claims.
In
my
token,
where,
instead
of
making
a
graph
call
to
get
additional
information,
maybe
I
could
just
get
that
additional
information
in
my
claim.
There's
always
a
trade-off,
because
graph
can
be
very
rich.
A
I
can
get
all
kinds
of
information
stuff
that
I
don't
even
have
available
as
an
optional
claim,
but
it
does
mean
I'm
doing
another
set
of
calls
right.
So
the
the
fewer
network
calls
I
do.
The
fewer
infrastructure
calls.
I
do
the
more
resiliency.
There
is
a
trade-off
here
that
you
need
to
evaluate.
So,
for
example,
we
definitely
don't
think
you
should
use
the
user
info
info
endpoint.
It's
there.
A
A
So,
let's
go
back.
We've
had
plenty
of
time
now
we'll
go
back
to
our
application.
Now
I
know-
or
at
least
yesterday
when
I
tried
this-
the
microsoft
graph
api,
which
is
not
yet
reached
private
preview
stage,
is
issuing
me
a
cae
token,
but
not
yet
handling
the
events,
so
I
should
be
able
to
still
call
the
profile,
so
you
notice
the
profile
called,
because
I
have
a
24-hour
token,
and
yet
I
revoke
that
user
sessions.
I
shouldn't
be
allowed
to
make
that
call.
A
A
But
now,
given
that
that
has
occurred,
I
have
to
go
ahead
and
and
do
my
authentication
again,
I
won't
even
be
able
to
have
single
sign-on,
because
the
sessions
were
of
course
rejected,
so
the
user
does
have
to
authenticate
again
that's
expected,
and
now
I
get
my
call
and
if
I
go
back
and
look
at
my
token
response.
Of
course,
I
I
end
up
getting
a
new
token
there,
as
well
or
15
minutes
later.
I
had
a
whole
new
token
there,
because
we
threw
out
all
the
tokens
that
once
we
got
the
first
event.
A
So
this
helps
your
again.
You
can
see
we're
much
more
secure
because
if
we
look
at
the
original
behavior
of
that
one
token,
I
could
still
get
my
profile
information
about
the
user,
because
cae
has
been
turned
on
for
that
api.
Yet,
but
as
soon
as
I
did
hit
a
cae
enabled
api
the
session,
the
token
was
invalidated
and
off
I
go
and
get
a
proper
reauthentication,
so
those
are
really
really
do
help
your
resiliency,
because
the
length
of
these
tokens
is
so
long
that
we
can
pre-actively
refresh
them.
You're,
not
asking
for
tokens.
A
Very
often
etc,
but
we
can
do
that
because
the
whole
thing
is
a
lot
more
secure.
So
what
about
applications
where
there
are
no
user's
presence?
Well,
the
first
suggestion
here
is-
and
this
is
unfortunately
tied
to
using
azure
today.
But
if
you
are
building
your
services
on
azure
you're,
using
azure,
vms
or
functions
or
services,
we
would
really
strongly
suggest
using
ad
manage
identity
for
azure
resources.
A
First
off
they
are
also
more
secure.
You
don't
have
a
password
to
manage,
there's
no
credentials,
you
don't
have
to
rotate
the
search
or
anything
like
that,
and
there's
no
way
for
anyone
to
intercept
that
information
and
use
it
in
in
in
the
wrong
way.
We
also,
of
course,
are
doing
additional
optimizations.
One,
of
course,
is
we're
issuing
long-lived
tokens
for
these
identities.
Therefore,
we'll
go
through
the
proactive
token
refresh
so
again
that
gives
us
hours
to
make
sure
that
the
token
can
be
reacquired
and
that
can
really
really
help
resiliency.
A
You
know
we.
We
find
anything
that
that's
using
this
process
to
be
rarely
affected
by
any
any
glitches
between
that
token
acquisition
path,
and
we
even
have
additional
optimizations
things.
Like
understanding
that
you
know
I'm
an
azure
resource
and
this
resource
is
running
in
this
specific
azure
data
center,
therefore
we'll
talk
to
the
azure
ad
implementation
data
center
for
that
data
center
as
well
so
everything's
local,
is
what
we
would
refer
to
as
regional.
That
helps
reduce
any
dependency
we
might
have
on
something
outside
of
that
data
center.
A
So
as
long
as
the
data
center's
up
and
running
my
resource
I'll,
have
the
the
right
azure
active
directory
to
go
with
that
as
well,
so
we
can
again
increase
our
resiliency
by
not
taking
cross
data
center
dependencies.
If
you
will,
let's
see
so,
we
have
a
couple
of
questions
here.
Regarding
token
lifespan,
power
automate
allows
a
user
to
authenticate
to
sharepoint
power.
Automate
will
run,
for
example,
every
time
a
sharepoint
item
is
changed.
A
A
Automate
won't
be
able
to
participate
because
they're
making
the
calls
cae
not
just
does
token
it
doesn't
do
just
when
the
tokens
the
user
sessions
get
revoked,
but
it
also
can
check
for
things
like
iphs
changes
and
if
there's
a
conditional
access
policy
that
says
this
can
only
be
used
from
some
locations,
then
a
backend
process
like
power
automate,
may
not
be
eligible,
but
outside
of
that
generally,
the
flow
that
that
this
works
on
is
access.
Tokens
are
issued
for
some
specific
amount
of
time.
A
That
could
be
an
hour
that
could
be
a
day
if
it's
cae.
At
the
end
of
that
time,
we
are
strongly
encourage
our
developers
to
use
this
thing
called
auth
code
flow.
What
auth
code
flow
is
gives
you
something
called
a
refresh
token.
This
all
is
happening
under
the
covers
in
amsoil,
but
we
end
up
with
a
second
token.
The
second
token
is
issued
normally
for
days
instead
of
hours.
A
So
if
I
signed
in
and
the
access
token
was
good
for
an
hour
and
then
something
shows
up
on
sharepoint
or
the
the
you
know,
then
two
hours
later,
I
do
something-
and
I
don't
do
anything
for
three
hours
well,
that
access
original
access
token
has
expired,
but
the
refresh
token
is
still
good.
So
the
application
goes
and
asks
for
a
new
access
token,
using
its
refresh
token.
We
give
it
both
a
new
access
token
another
hour
and
a
new
refresh
token.
A
So
if
the
refresh
token
was
issued
for
14
days
now,
we
got
a
new
14-day
clock
started,
so
we
will
roll
those,
you
know,
do
rolling
refresh
tokens
on
those
access
tokens.
So
we
find,
for
example,
that
for
most
of
the
time
I
think
our
default
is
about
90
days
before
another
authentication
is
required
that
is
configurable
by
the
tenant.
So
some
of
our
more
security
conscious
need
to
be
locked
down.
A
Tenants
might
set
their
need
for
authentications
every
day
right,
so
they
can
control
how
long
they
want
between
a
user
is
required
to
do
their
authentication.
So
you
can't
count
on
that
time
span,
but
for
lots
of
tenants
are,
you
might
have
your
application
continue
working
on
that
over
a
month's
long
period,
three
months
or
so
authenticator
is
a
password
manager,
but
I
won't
be
able
to
talk
about
that
today.
There's
a
new
preview
feature
of
authenticator
to
also
work
for
your
to
be
a
password
manager.
It's
it's
a
nice
thing
to
go.
A
Can
you
do
on
on
behalf
of
flow
with
managed
identities
on
behalf
of
flow
of
the
managed
identity
shouldn't
be
required
and
on
behalf
of
flow
is
so
that
the
entity
can
work
on
behalf
of
the
signed
in
user,
so
the
nature
here
is,
I
have
a
user
who
signed
in
and
maybe
that
user
called
my
api,
so
I
have
a
token
in
hand
for
that
application
to
call
on
behalf
of
the
user
to
my
api.
Now
my
api
needs
to
make
another
call.
What
we
don't
want
is
your
api
to
say.
A
A
A
Identity
has
never
got
a
user
in
front
of
it
and
it
shouldn't
be
working
even
in
a
service
account
if,
if
that
can
be
avoided
at
all,
therefore
they
shouldn't
be
looking
at
it
on
behalf
of
flow,
because
it's
all
in
you
know
they
just
needed
a
token.
They
just
go
ahead
and
use
their
the
token
and
since
we're
as
part
of
the
the
nature
of
managed
identity
for
azure
resources,
we're
actually
doing
all
the
token
acquisition
low-level
protocol
stuff.
A
Does
it
exist
a
way
to
authenticate
external
users
outside
of
my
company
without
using
federation
and
azure
id
b2c?
If
I
invite
users
as
guests,
they
can
access
to
our
internal
applications
like
office
online.
We
do
not
like
this
to
happen,
so
you
can.
A
guest
user
does
authenticate
back
to
their
original
authentication
point.
You
would
have
to
control
that
through
conditional
access
or
by
user
assignment
is
usually
the
the
point.
A
So
one
of
the
things
that
lots
of
I
see
lots
of
customers
doing
is
requiring
user
assignment
to
any
app,
and
then
they
can
simply
have
a
group
of
of
guests
who,
and
they
have
a
separate
group
for
people
who
are
not
guests
and
those
are
the
apps
they
assign
to
people
who
for
whom
guest
apps
shouldn't
be
accessible.
So
you
can
control
that
at
the
it
admin
side
by
using
things
like
assigning
users
and
groups
to
apps,
so
the
default
would
be
90
days
and
not
longer.
A
So,
depending
on
the
policy,
it
is
possible.
We'll
keep
issuing
tokens
on
a
on
that
rolling
refresh
90
days
is
our
default.
Some
of
them
are
14
days
now,
as
well,
depending
upon
the
configuration
of
the
tenant
and
what
the
options
they
picked
and
then
again
they
they
have
another
knob.
That
says
I
want
to
do
it
this
way.
A
So
a
couple
more
points
again,
if
you
are
writing
an
application
that
that's
not
using
you
know,
maybe
you're
not
running
on
azure,
so
you
can't
use
a
manage
identity.
Another
good
step
here
is
to
use
msul.
We
do
all
of
the
same
work.
We
do
that
we
did
for
client
applications
for
what
we
call
confidential
clients.
These
are
the
ones
that
are
using
client
credential
flow.
So
we
have
a
similar
set
of
capabilities
that
will
work
for
these
daemon
or
service
apps
in
insole.
So
it's
another
choice.
A
B
Yeah
just
want
to
thank
everyone
and
remember
to
please
take
some
time
to
fill
out
a
survey
just
take
a
few
minutes
and
give
us
feedback
on
this
call,
and
if
you
have
ideas
for
future
topics,
I'm
also
going
to
post
the
link
where
you
can
watch
the
recording
next
week,
and
so
thank
you.
Everyone
and
we
hope
to
see
you
on
our
next
call
on
march
18th
appreciate
it.