►
Description
This month’s in-depth topic: Using Conditional Access Auth Context in your app for step-up authentication. Use the Microsoft Azure AD Conditional access engine’s new Auth Context feature to trigger a demand for step-up authentication, like MFA, from within your application and services. This capability helps developers build low friction user experiences for some parts of their application, while keeping access to more secure operations and data behind stronger authentication controls. Learn how to enable these scenarios in this session. Microsoft Program Manager presenters – Caleb Baker and Kalyan Krishna. This session was recorded on May 20, 2021. Live and in-chat Q&A throughout call.
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
Well,
welcome
and
thanks
for
joining
today,
my
name
is
kayla
baker,
I'm
a
program
manager
in
the
azure
ied
team,
working
on
in
the
identity,
security
protection
group
and
specifically
on
conditional
access
policies,
and
I'm
happy
and
excited
to
be
talking
to
you
about.
This
is
something
that
we've
been
working
on
for
a
while
to
kind
of
allow
apps
to
like
more
deeply
integrate
in
with
conditional
access
and
really
use
it
to
protect
that
that
in-app
data.
So
I'm
excited
to
to
be
here
thanks
a
lot.
A
All
right
so
then,
for
the
the
agenda
today,
I'm
just
going
to
start
off
a
little
bit
talking
about
zero
trust,
and
you
know
how
it
relates
to
developers
with
conditional
access
policy
and
then
going
through
some
of
these
concepts
around
app
triggering
step-up
authentication,
and
this
is
just
kind
of
like
background
about
like
what's
motivating
the
feature
and
and
how
it
fits
into
this
bigger
picture
around
zero
trust.
Then
kalyan
will
talk
about
the
identity
platform.
A
All
right
well
so
to
get
started.
I'm
going
to
talk
about
just
microsoft,
zero
trust-
and
you
might
have
already
heard
this-
is
a
story
that
we're
we're
really
amplifying
and
and
talking
to
a
lot
of
customers
about,
particularly
with
enterprise
customers
that
are
facing.
You
know
new
security
threats
and
figuring
out
how
to
maintain
a
strong
security
posture
as
they
move
to
the
cloud
as
customers
or
as
their
employees
are
working
from
any
location.
A
So
xero
trust
is
really
approach
to
and
a
mindset
to
how
to
continue
to
secure
your
data
with
in
this
new
world,
where
you
don't
necessarily
have
like
this
corporate
boundary
or
have
this.
You
know
trusted
network
that
you
might
be
operating
in
some
of
the
principles
here
and
again,
like
the
reason
that
I'm
kind
of
going
into
this
is
because
so
many
enterprise
customers
are
concerned
with
this,
and
they
are
going
to
be
deploying
this
type
of
model.
A
lot
of
them
are
already
on
their
journey.
A
A
So
some
of
the
the
principles
that
they're
pivoting
around
and
really
how
we
tell
this
story-
is
to
verify
explicitly.
So
this
is
don't
assume
just
because
someone's
from
a
trusted
location
or
has
one
trusted
aspect
of
them
that
they're
good
and
give
them.
You
know
full
access
to
everything,
but
have
stronger
authentication
have
all
of
those
steps
in
place,
use
other
signals
and
data
to
help
identify
who
they
are
use.
A
You
know
least
privilege
this
kind
of
falls
more
into
the
the
space
of
when
you're
making
graph
api
calls
to
use
like
that
minimum
set
of
permissions.
So
if
something's
compromised,
there's
a
lesson
impact
and
then
there's
also
assume
breach
and
assume
breach
is
kind
of
the
the
one
that
fits
the
most
with
the
topic
today.
We're
assume
breach
is
kind
of
that
assumption
that
there's
always
an
attacker
someone's
already
always
inside
an
organization.
A
C
A
So
that
maybe
for
like
a
day-to-day
activities,
you
have
a
lower
bar
in
terms
of
authentication,
but
then
to
do
you
know
get
to
the
real
important
data.
You
know
that
there's
stronger
policies
in
place
and
you
can
still
maintain
those
controls,
so
there's
multiple
layers
that
someone
would
have
to
break
through
to
really
get
to
like
the
keys
to
the
kingdom.
A
So
I'll
just
break
real
quick
here,
since
I'm
going
to
be
talking
now,
specifically
around
conditional
access
just
to
level
set
and
know
a
little
bit
in
terms
of
like
how
much
detail
to
go
into
in
the
different
areas
toss
in
the
chat.
How
familiar
are
you
with
conditional
access
like?
Is
this
a
new
topic
to
some
of
you
or
are
you
pretty
familiar?
You
know
you've
set
it
up.
You
understand
how
it's
working
so
far.
A
A
That
could
be
a
common
policy
for
if
someone
was,
you
know,
going
to
be
downloading
files
from
that
application
to
their
local
machine,
so
that
the
company
can
keep
control
over
that.
The
the
graphic
here
really
shows
a
lot
of
the
signals
that
we
evaluate
and
that
we
can
use,
including
like
that
user
location,
ip
ranges,
the
device,
health,
other
information
about
the
device,
there's
the
real-time
risk,
where
this
is
integration
with
azure
id
identity
protection.
C
A
Those
signals
we
can
enforce
the
policies
like
that
multi-factor
authentication,
reduce
access
of
that
user
or
block
access,
and
then
that
applies
to
applications
in
the
end
in
terms
of
what
they're
trying
to
get
access
to
now.
Most
of
conditional
access
right
now
is
pivoted
around
that
application
access
and
this
kind
of
starts
really
getting
into
what
we're
we're
here
to
talk
about
today.
A
So
if
you
think
about
creating
one
policy,
one
access
policy
for
an
app,
I
can
use
like
sharepoint
as
an
example
here
that,
if
you're
making
one
policy
decision
for
all
of
the
files
that
live
across
sharepoint
that
can
be
challenging
because
it's
not
like
there's
just
one
file
that
lives
on
sharepoint.
There's.
A
A
Is
this
pattern
around
like
stepping
up
or
triggering
multi-factor
authentication
from
an
application
and
and
how
this
works
in
in
other
places
and
like
other
applications,
do
this
piece,
because
we
really
wanted
to
follow
like
a
common
pattern
that
was
already
out
there
in
the
industry
would
be
that
an
application
could
have
some
code
in
it.
That
says,
you
know,
I
know
to
access
this
piece.
There
has
to
be
a
multi-factor
authentication
can
check
within
the
token
see
if
there's
a
claim
that
expresses
multi-factor
authentication
occurred.
A
If
there
isn't,
then
the
app
can
start
a
new
sign-on
trigger
a
new
sign-in
add
an
additional
parameter.
That'll
indicate
that
multi-factor
authentication
is
needed,
then
the
identity
provider
would
prompt
the
user
and
after
the
user's
done,
multi-factor
auth
insert
that
claim
and
the
token
so
they
can
pass
the
authorization
check
we
have
like.
We
have
very
limited
support
for
that
within
azure
active
directory.
A
Workstation
and
someone
would
author
a
policy
that
says
only
these
devices
can
interact
with
a
service,
that's
handling
some.
You
know
sensitive
devops,
operation
or
or
some
other
service.
That's
that's
critical
to
the
business
and
then
the
other
one
is
location
where,
with
the
integration,
you
can
just
pick
up.
Other
controls,
we've
recently
added
like
gps
controls
and
being
able
to
lock
down
specific
actions
in
the
app
that
way
too
so
kind
of
taking
all
of
that.
A
Instead,
the
application
can
reference
conditional
access
policies
that
an
admin
has
authored
so
what's
showing
on
the
the
left.
Here
is
the
sort
of
dialogue
and
configuration
that
could
appear
within
an
application
where
someone
who's
administering
the
app
can
see
like
what
are
the
event
available
policies
that
I
can
use
within
my
application
behind
the
scenes
there.
You
also
get
the
the
identifier
that
would
you
would
use
when
working
with
azure
active
directory.
A
A
And
then
you
know
once
it
is,
the
claim
comes
back
and
you
allow
access
and
the
really,
I
think,
one
of
the
powerful
things
here
is
that
then,
as
we
do
add,
all
of
those
things
in
the
conditional
access
like
the
gps,
coordinates
or
a
specific
device
or
expand
out
the
the
type
of
authentication
method
supported
in
conditional
access
policy,
the
the
app
just
kind
of
like
picks
all
of
those
up
for
free,
since
it
doesn't
need
to
know
about
those
methods,
the
the
coupling
is
pretty
loose.
It's
just
by
this.
A
B
Thank
you,
caleb.
That
was
a
great
introduction
to
the
security
policy.
Posturing
using
the
conditional
access
engine
and
the
zero
trust.
Okay.
So
before
we
get
on
with
the
actual
development
aspects
of
it.
As
quick
introduction
to
the
microsoft
identity
platform,
which
is
a
a
part
of
the
azure
active
directory
product
offering
the
identity
platform
is
a
distinct
set
of
tools
and
libraries,
starting
with
the
app
registration
portal
where
you
can
go
and
register
your
applications
that
you
want
to
authenticate
using
the
azure
active
directory.
B
We
also
ship
a
number
of
libraries
called
microsoft,
authentication,
libraries
and
we
will
be
using
those
in
our
demos
today
and
we
have
open
id
connect
and
oauth
two
certified
endpoints
which
allow
you
to
make
applications
which
are
protocol,
independent
and
and
and
quite
interoperable.
We
also
have
popular
apis
like
microsoft,
graph
and
azure
service
management,
apis
that
you
can
use
to
manage
your
resources
and
get
access
to
your
data
in
the
microsoft
cloud.
B
We
support
the
azure
various
types
of
identities,
the
most
popular
being
the
azure
adm
microsoft
accounts,
which
is
your
hotmail
and
outlook
and
a
whole
set
of
external
identities
by
our
b2c
product,
and
the
whole
platform
is
built
up
on
open
protocols.
Nothing
proprietary
allows
us
to
you
and
us
to
basically
innovate
faster
and
make
sure
that
you
do
not
end
up
getting
locked
up
with
any
particular
identity
provider.
B
Having
said
that,
going
on
I'm
just
going
to
cover
the
identity,
microsoft
authentication
lab
in
a
little
bit
more
detail.
We
have
these
available
for
various
platforms
and
you
will
find
it
quite
useful
again
to
program
against
azure,
active
directx,
authentication
and
authorization
and
including
the
feature
that
we
are
going
to
present
here
today.
They
abstract
a
lot
of
work
for
you
and
we
recommend
that
you
can
use
one
of
the
open
id
compliant
libraries
or
you
should
give
the
microsoft
authentication
libraries
a
try
when
you
have
a
chance.
B
Having
said
that,
let's
cover
the
conditional
access,
auth
context
in
more
detail,
as
caleb
had
very
nicely
explained.
Conditional
access
is
the
control
plane
that
allows
you
to
target
policies
to
for
access
to
all
your
applications
and
the
auth
context
or
ca
auth
context
as
we
refer
to
it
essentially
allows
you
to
allow
apply
policies
within
your
application
and
by
saying
by
that
I
say,
different
policies
within
your
applications.
B
B
The
common
scenarios
for
developers,
if
you
are
curious,
is
like
okay,
if
somebody
is
accessing
a
certain
sensitive
document
or
somebody
is
carrying
out
the
hyper
video
operations,
like
you
know,
assigning
admin
roles
to
users
or
if
somebody
is
carrying
out
a
sensitive
operation
like
transferring
funds
that
you
see
on
the
banking
sites.
So
these
are
the
scenarios
where
you
can
say:
okay,
if
you
are
doing
a
I'm
gonna,
have
you
do
an
mfa
or
if
you
are
going
to
do
something
like
you
know,
assign
roles.
B
Maybe
you
should
not
just
have
dynamic,
but
also
access
the
application
from
a
compliant
device
or
if
it's
a
very
heavily
sensitive
operation.
You
can
say-
and
not
only
these.
I
also
want
your
applica,
the
user,
to
be
accessing
the
application
from
an
ip
address
range
and
you're,
making
these
decisions
or
driving
these
decisions
from
within
the
various
operations
that
you
have
within
in
your
application.
B
So
what
are
we
talking
about
here?
So
what
I'm
going
to
do
is
I'm
going
to
first
start
with
the
end
user
experience
and
what
they
see
and
then
we
will
basically
unravel
it
and
see
how
what
are
the
various
parts
that
that
make
up
this
experience.
So
I
have
picked
up
this
standard
code
sample
that
we
have
where
we
have
a
client
application
called
to-do
list,
client
which
uses
an
api
called
to-do
list
service
and
basically
it
creates
to-do
list
items
using
calls
to
this
web
api.
B
B
And
then
I
can
delete
it
and
I'm
asked
for
a
confirmation
and
I'm
able
to
delete
it
now.
The
difference
here
is
that
we
want
to
make
this
little
bit
of
a
change
where
we
want
to
basically
impose
a
higher
bar
of
authentication
when
a
delete
operation
occurs.
So
what
we
have
in
this
demo
are
in
the
sample
and
which
is
shared.
I've
shared
the
link
to
the
sample,
indeed
in
the
deck
as
well,
is
that
in
the
web
api
side-
and
this
is
the
this
is
where
my
web
api
looks.
B
I
have
an
admin
portal
for
the
web
api
and
here
I
basically
do
something
like
fetch.
These
authentication
contacts
and
just
bear
with
me
is
because
I
will
explain
it
in
more
detail
and
I
have
these
various
operations
available
in
my
web
api.
I
picked
up
post
and
delete,
and
I
say
you
know
what,
if
it's
a
delete
operation,
I
want
to
have
a
strong
authentication,
so
I
save
it
and
then
I
go
back
here
and
I'm
going
to
create
another
task
again
as
an
end
user.
B
This
is
the
end
user
functionality
that
we
want
to,
basically
that
we
have
brought
to
you
and
now
again,
I'm
back
to
my
delete
confirmation
screen
and
now
I'm
able
to
delete
it.
So
this
is
the
exact
feature
capability
that
we
have
brought
to
you
and
that
we
will
talk
about
in
this
in
this
call
today.
So
let's
go
back
to
the
deck
for
a
second
okay.
B
So
this
was
a
quick
demo
and
what
we
had
seen
here
is
an
art
context
in
actual
action
where,
for
a
certain
action
which
I
have
in
my
application,
I
was
able
to
ask
azure
active
directory
to
have
the
user
go
through
the
a
certain
policy
so
to
meet
a
certain
policy
requirement
in
this
case.
Do
an
mfa
before
they
were
able
to
carry
out
that
operation.
So
what
are
the
various
steps
that
you
need
to
do?
B
So,
let's
start
from
the
beginning
and
from
the
the
first
thing
is
that
we
would
visit
the
portal
and
we
will
look
at
what
authentication
contexts
are
and
then
we
will
look
at
some
of
the
ca
policies
that
use
those
authentication
context.
So
without
further
ado,
let's
go
to
the
portal
again,
and
so
here
we
are
back
at
the
azure
active
directory
portal
and
I'm
going
to
keep
increasing
my
screen.
So
I'm
sorry
there
is
this
top
bar
on
my
screen.
B
B
I
we
just
saw
that
a
lot
of
you
are
actually
familiar
with
this,
so
this
is
how
you
reach
to
the
conditional
access
screen.
One
of
the
things
that
you
will
notice
here
is
a
blade
called
authentication
context.
This
is
being
rolled
out
as
we
speak
to
the
to
all
the
tenants
it
might
or
might
not
have
managed
to
get
to
your
your
own
tenants
so
be
patient
for
a
few
days.
If
you
don't
see
it
here,
I
am
being
asked
to
configure.
B
I
can
see
what
authentication
contexts
are
available
and
I
can
create
new
ones.
So,
let's
look
at
this
one.
So
what
it
essentially
is
is
just
a
name
and
a
description,
and
it
has
been
given
an
id
called
c1,
so
just
make
a
note
of
it
is
because
we
will
be
revisiting
the
c1
id
over
and
over
later
in
the
demonstration.
So
once
I
have
created
an
authentication
context,
then
you
can
go
ahead
and
create
more
as
you
wish.
So
my.
B
And
once
you
do
that,
you
basically
have
another
authentication
available.
Sorry
authentication
context
available
to
you.
So
what
we
have
done
is
essentially
created
authentication
context.
These
are
entities
in
themselves
and
how
do
you
use
them?
So
you
use
them
in
your
policies,
and
this
is
where
the
bridge
between
authentication
context
and
policy
becomes
available.
So
if
you,
once
you
have
the
authentication
rolled
out
into
your
tenant,
you
can
go
ahead
and
create
a
policy
which
could
be
if
you
want,
or
you
can
edit
one.
B
You
can
basically
choose
your
targets
and
in
this
case
I
have
selected,
let's
say
a
user
or
a
group
sorry
bear
with
me
and
in
the
cloud
apps
or
actions.
You
will
now
also
see
an
authentication
context
available
here.
My
authentication
contexts
are
shown.
Now
I
can
pick
the
authentication
context
that
I
want
to
use
and
at
that
point
in
time
I
can
basically
start
demanding
the
various
grants
that
we
want
to
impose
for
this
policy.
B
So
what
we
are
doing
here
is
saying
that
if
somebody
shows
up
at
azure
active
directories,
door
and
an
app
and
a
user
shows
up
at
an
or
whoever
is
on,
our
user
in
group
shows
up
on
the
door
of
azure
active
directory
asking
for
these
authentication
context.
This
is
what
they
will
have
to
satisfy.
So
in
my
case,
I
already
have
one.
B
B
B
This
is
available
via
the
microsoft
graph
api
and
bear
with
me
for
one
more
second,
while
I
show
you
which
api
that
is
so
it's
called
authentication
context,
class
reference,
and
when
you
you
are
an
app
developer,
you
need
to
have
access
to
microsoft
graph.
You
can
enumerate
the
available
auth
context,
show
it
in
your
application
and
basically
make
use
of
it.
B
And
this
is
what
we
did
here
going
back
to
our
deck
again,
where
we
will
continue
doing
the
configuration.
So
this
is
all
you:
do
you
create
auth
context,
and
then
you
use
it
in
your
ca
policies.
Once
you
have
those
available,
you
start
basically
defining
operations
and
actions
in
your
application
and
start
attaching
them
to
our
context.
This
is
a
topic
again.
B
We
will
discuss
in
a
little
bit
more
detail
and
why
we
want
you
to
go
via
the
microsoft
graph
route
later
in
the
in
this
session,
but
this
is
this
should
be
enough
for
a
good
start.
So
going
back
to
the
deck
again
now
that
you've
seen
how
it
is
configured
and
I
have
seen
how
the
end
it
works
for
the
end
users,
let's
just
discuss
the
authentication
context.
What
the
new
entity
that
you
were
just
introduced
to
in
more
detail,
it
is
declared
at
a
tenant
level.
B
It
has
nothing
to
do
with
applications.
It's
a
tenant
wide
entity,
it
can
change
from
tenant
to
tenant.
It
is,
it
exists
at
a
tenant
level.
Applications
have
no
control
on
it
other
than
to
read
it
and
if
they
have
permissions,
update
the
add
and
update
new
ones
using
microsoft
graph.
The
authentication
context
is
the
bridge
between
the
policies
and
the
applications.
That's
exactly
what
it
is.
When
you
look
it
from
an
app
developer
perspective,
it
has
some
notable
attributes.
B
B
We
can
make
it
make
those
changes
later,
but
today
we
believe
this
should
be
more
than
enough
and
it
has
a
display
name
that
we
saw
that
we
showed
to
the
end
users
or
id
admins,
who
are
configuring,
configuring
various
actions
against
the
authentication
context.
So,
in
my
case
you
saw
we
have
three
different
auth
contacts
available.
I
they
were
given
the
ids
of
c1,
c2
and
c3,
and
they
are.
These
are
the
various
the
text
that
we
have
in
front
of
them.
B
So
if
you
have
an
app
and
you
want
to
use
auth
context,
what
are
the
various
prerequisites
that
you
have
to
meet
today?
First
of
all,
today
it
is
built
on
protocol
extensions
provided
by
open
id
connect
and
os2
so
only
available
to
applications
who
use
these
protocols.
We
have
some
planning
some
plan
planned
work
in
progress
to
address
other
types
of
applications
and
we
hope
to
address
them
in
the
in
the
coming
months,
but
today
it's
only
available
to
these
application
applications
using
these
two
protocols.
B
You
also
need
azure
active
directory
premium
p1,
which
is
mostly
from
the
fact
that
you
need
to
have
this
particular
screw.
If
you
want
to
access
conditional
access-
and
I'm
just
adding
this
obvious
part,
it's
only
available
to
applications
that
sign
in
users.
There
are
applications
like
services
and
daemons
and
they
have
very
limited
use
in
a
conditional
access
policies,
and
this
does
not
work
for
them.
B
A
A
There's
there's
quite
a
bit
of
integration,
that's
possible
with
this.
It's
a
pretty
flexible
feature
and
with
it's
similar
with
b2c
right
now,
the
b2c
flow
is
not
supported,
but
you
can
easily
imagine
how
this
would
extend
there
as
well
for
the
multi-tenanted
support,
since
every
organization
can
define
the
policies
separately
like
really
how
the
multi-tenanted
app
support
works.
There
is
being
able
to
to
call
into
that
graph
api
to
see
which
authentication
context
values
are
available
in
that
tenant.
B
Thank
you
caleb.
Yes,
there
is.
There
is
a
lot
to
unravel
here.
Some
of
the
questions
you
have
here
around
like
multi-tenancy,
and
how
do
you
cook
it
into
the
app
are
things
that
I
actually
will
cover?
You
know
in
a
quick
few
minutes,
and
this
is
where
the
using
microsoft
graph
to
save
the
mapping
in
your
application
is
important
is
because
the
authentication
context
will
differ
from
tenant
to
tenant
and
we
have
a
code
walkthrough
as
well
so
moving
on,
so
we
created
the
context.
B
B
So
and
then
what
we
do
next
is
that
we
look
for
a
claim
called
authentication
context,
requests
or
acrs,
and
if
it
is
missing,
we
raise
a
claims
challenge
so
just
hold
bear
with
me,
and
now
we
will
have
a
code
walkthrough,
where
I
will
essentially
show
you
right
in
the
code
what's
going
on,
okay,
so
this
is
the
code.
This
is
our
service.
B
B
So
in
this
action,
what
we
do
is
the
very
first
one
that
you
saw,
which
was
to
basically
create
a
fetch.
In
this
case
we
make
a
call
to
microsoft
graph
and
we
have
a
class
in
the
sample.
Sorry
really
long
named
one
authentication
class
reference
operations
which
basically
uses
the
microsoft
graph
beta
beta
sdk.
B
B
Most
app
developers
should
be
basically
just
reading
the
existing
ones,
and
once
you
read
those
you
basically
then
have
the
capability
where
you
go
ahead
and
save
them
against
some
of
your
operations.
So
in
this
case,
what
we
are
doing
here
in
this
code
is
reading
it,
and
then
we
have
defined
a
bunch
of
actions.
So
in
this
sample
we
defined
two
actions
which
are
essentially
tied
to
the
with
two
events:
two
two
mvc
events,
which
is
for
post
and
delete,
and
these
can
be
mapped
to
pause
context.
B
B
So
when
I
made
this
when
I
saved
this-
and
this
is
my
data
that
I've
saved
so
essentially
I
save
that
c1
auth
context
id
against
the
delete
operation
and
that's
what
basically
triggered
the
user
to
be
sent
back
to
the
azure
80
endpoint
for
for
getting
the
the
policy
satisfied
now
this
is
part
one.
So
once
you
have
saved
it,
what
I
have
here
in
to-do
list
controller,
a
special
method
called
check
for
required
context,
so
it
takes
the
name
of
the
method.
In
this
case,
the
method
is
either
post
or
delete.
B
What
it
then
goes
on
to
do
is
that
it
looks
for
a
claim
called
acrs.
If
it
doesn't
find
one.
Obviously
it
will
throw
an
exception
or
if
it
finds
it,
it
checks.
If
the
acrs
claim
has
the
auth
context
id
the
id
is
essentially
c1
and
c2
and
I'll
just
show
you
an
example
of
how
the
token
looks
like
if
it
doesn't
see
the
required
claim
it
will
throw
what
we
refer
to
as
a
claims
challenge.
Now
this
is
all
defined
for
you
in
the
documentation.
We
share.
B
We
hope
to
basically
move
this
code
into
the
msr
libraries
in
the
future,
but
at
this
point
in
time
this
is
a
special
kind
of
a
message
that
you
have
to
raise.
You
can
use
this
code
to
learn
about
it.
So
essentially
you
are
basically
saying
hey.
I
want
to
you
are
throwing
an
unauthorized
access
exception,
that
is
the
http
error
code,
401
back
to
the
user,
asking
them
to
go
and
and
with
a
set
of
claims
and
you're
requesting
a
claim,
which
is
your
authentication
context.
B
Id
which
is
c1
so
bear
with
me
for
a
second
is
because
I
I'll
just
walk
you
through.
So
what
this
service
does
is
that
for
each
of
its
operations
it
checks
for
an
auth
context,
so
it
first
makes
a
call
to
its
local
db,
see
that
if
there
is
an
auth
context,
id
saved
against
this
particular
method
that
is
being
called
and
if
it
is,
and
the
acrs
claims
does
not
have
that
earth
context
id.
B
In
the
token,
it
raises
a
claims
challenge,
I'm
going
to
just
stop
here
and
basically
show
you
the
actual
token,
because
I
know
there
is
a
lot
to
process
here
so
so
you
saw
how
this
works
in
the
in
this
service
setup.
Just
to
summarize,
the
admin
had
defined
auth
contacts
in
the
portal.
Then
they
created
ca
policy,
then
the
it
admin
and
it
could
be
app
admin.
Basically,
they
access
the
admin
site.
B
You
query
the
existing
auth
context
using
microsoft
graph,
you
will
be
given
a
list,
you
save
your
actions
against
your
applications,
actions
or
whatever
you
want
to
call
them
against
these
auth
context,
values
and
you
save
it
in
the
local
db,
and
then
you
use
it
so
we
just
had
a
service
walkthrough.
So
this
is
how
an
access
token
looks
like.
So
this
is
an
access
token
for
my
web
api,
which
is
what
you
can
see
in
the
very
first
clip
the
order.
B
Aud
claim-
and
it
has
a
set
of
usual
virus
scope,
app
id
and
whatnot
now
when
this,
but
what
you
will
notice
here
is
that
it
does
not
have
a
claim
named
acrs.
So
what
happened?
The
first
time
when
the
user
sent
this
to
the
service
when
they
were
trying
to
delete
a
to-do
list
item
the
code
basically
said
nope.
I
need
an
acrs
claim,
and
can
you
please
respond
to
this
claims
channel?
So
this
is
how
the
claims
challenge
looks
like.
B
B
It
reads
like
this:
if
you
can
see
that
it's
basically
saying
that
hey
in
the
access
token,
can
we
get
the
acrs
claims
and
it
should
have
a
value
of
c1
if
you
want
to
delete
the
clients
need
at
this
point
in
time
to
redirect
the
user
back
to
azure
id
with,
what's
called
as
a
claims
request.
Sorry
this
is
a
lot
of
things
to
to
explain
so
the
claim
that
we
are
requesting
back
from
azure
id
is
acrs,
and
this
has
a
auth
context.
B
Id
now,
when
azure
id
sees
that
hey,
there
is
a
application.
Is
the
client
application
asking
for
a
claim
called
c1?
Sorry
c
claim
called
acrs
with
the
value
of
c
one.
It
goes
through
its
various
conditional
access
policies
and
finds
out
which
policies
need
to
be
satisfied
before
azurity
will
issue
that
claim
back
to
the
client
application.
In
our
case,
we
have
one
policy
conditional
access
policy
that
asks
that
requires
the
user
to
do
an
mfa
and
that's
exactly
what
the
user
did
the
moment
that
is
complete
as
your
id
basically
another
access.
B
Token
sorry,
I'm
gonna
show
the
access
token,
which
has
this
again
the
same
set
of
claims,
but
in
this
time
we
also
have
a
claim
called
acrs
and
which
has
a
value
of
c1
when
this
is
sent
to
the
web
api.
The
web
api
is
able
to
again
in
the
code
that
I
have
just
discussed,
able
to
see
that
yes,
acr
screen's
present.
It
has
the
value
of
c1,
so
the
user
will
be
allowed
to
delete
a
to-do
list
task.
B
So
I'm
gonna
just
repeat
this
one
more
time
to
make
sure
that
we
are
we
have
we
have.
We
have
covered
all
the
topics
and
introduced
it
to
you.
So
in
the
service
app
you
first
after
you
have
saved
the
auth
context,
id
against
your
application
actions,
you
look
for
a
claim
called
acrs
and
you
are
searching
for
the
expected
auth
context.
Ids,
if
you
don't
find
them
against
the
saved
actions.
B
You
raise
a
claims
challenge
in
the
client
app
you
when
you
get
a
claims
challenge,
you
do
a
claims
request,
which
is
essentially
redirecting
your
user
back
to
as
your
active
directory
with
the
claims
needed,
which
is
the
which
has
the
auth
context
ids
for
azure
ad,
to
able
to
enumerate
all
its
conditional
access
policies
to
find
out
what
actions
need
to
be.
What
policies
need
to
be
satisfied
before,
as
your
active
directory
will
issue
that
as
context
in
the
claim
requested.
B
So
this
is
how
a
claims
request.
Look
like
again.
This
is
something
that
we
do
very
well
within
our
our
microsoft
authentication,
libraries,
but
I've
just
put
it
here
for
reference.
Essentially,
it's
the
same
thing.
The
claims
request
is
taking
the
user
back
to
login.microsoft.online.com
and
it
has
a
special
parameter
called
claims
in
which
we
are
saying.
B
Can
we
please
have
the
acrs
claims
with
the
value
of
c1
azure
id
does
its
magic
and
after
the
user
has
satisfied
that
the
various
policy
requirements
they're
issued
this
claim
and
before
we
move
to
the
next
part,
I'll
just
show
you
what
we
did
on
the
client.
So
now,
in
the
server
side,
you
saw
that
we
have
said
we
had
a
bunch
of
code,
but
in
the
client
side
it's
actually
much
simpler,
so
going
back
to
our
code
again,
this
is
our
server.
B
B
We
are
using
the
microsoft
authentication,
library,
the
microsoft
identity
web,
and
what
we
do
here
is
in
our
action.
So
this
is
where
let's
go
to
the
delete
method.
So
when
a
delete
is
called
out,
we
basically
look
for
an
exception
and
you
can
see
how
it
is
done
in
the
code.
It's
a
little
too
much
for
this.
B
For,
for
this
call
all
we
do
is
we
extract
the
header
value,
which
is
nothing
but
the
claims
that
we
need
and
we
use
the
consent
handler
class,
which
is
part
of
microsoft,
authentication,
libraries
and
we
call
the
challenge
user
method
and
it
does
all
the
redirection
and
getting
the
new
code
token
and
making
sure
that
it
has
the
necessary
claims
and
things
like
that.
The
moment
you
have
it-
and
this
is
all
done
so
this
is
all
you
need
to
do
in
the
client
app
today.
B
We
have
managed
to
extend
our
consent
handler
in
the
authentication.
Libraries
have
been
around
for
a
long
time
because
we
have
been
throwing
these
exceptions,
claims
challenges
and
doing
claims
requests
for
conditional
access
engine
for
a
while.
Now
we
hope
to
basically
move
some
of
this
code
that
we
have
here,
including
the
one
that
we
that
basically
creates
a
claims
challenge
in
the
in
the
libraries
itself,
but
till
then,
if
you
are
interested,
you
can
use
it
the
format
we
are
using.
B
It's
called
the
claims
challenge
and
claim
requests
are
defined
formats
in
the
open
id
specification.
It's
not
nothing
specific
to
microsoft,
if
you're
using
a
third
party
open
id
compliant
library-
and
it
supports
these-
the
challenges
and
requests,
you
should
be
able
to
program
against
this
scenario
as
well
in
in
the
language
and
platform
and
library
of
your
choice,
so
that
was
the
client
walkthrough.
I'm
gonna
just
quickly
summarize
this
for
you
one
more
time
and
then
we
will
take
some
questions
to
make
sure
that
we
have
covered
this
all
for
you.
So.
B
So
here
is
it,
it
looks
very
dense,
but
it's
actually
not
a
lot.
If
you
look
at
what
we
have
done
so
far,
we
have
a
user.
We
have
the
client
app,
which
is
the
web,
app
the
api
and
the
azure
active
directory,
the
in
the
first
instance,
the
user,
basically
signs
into
the
web
application
the
web
application.
The
client
web
application
takes
the
user
to
azure
active
directory.
Where
there's
your,
where
the
user
receives
an
access
token
for
the
api
and
then
user
starts
to
make
calls
to
api
the
web
api
always
checks
db.
B
If
there
is
a
requirement
for
an
auth
context,
if
not,
it
basically
keeps
returning
data
as
expected.
Now
when
it
say
conducts
a
high
privileged
actions
like,
in
this
case,
an
activity
to
delete
an
a
to-do
list
item.
The
save
settings
in
the
api
say
that
no,
it
requires
an
auth
context.
In
this
case,
a
claims
challenge
is
thrown
the
client
web
application
uses
the
consent
handler
class
to
send
a
claims
request
back
to
azure
radio,
as
you
already
enumerates
its
policies
to
looking
for
how
to
satisfy
all
the
various
auth
context,
ids.
B
That
was
presented,
takes
the
user
and
asked
them
to
do
all
the
actions
that
are
required.
A
new
access
token
is
issued
and
the
users
can
now
start
making
calls
without
having
to
go
back
to
azure
id
again
so
yeah,
that's
like
the
primary
meet
of
the
demo,
and
at
this
point
I'm
gonna
pause
and
see.
If
we
have
any
questions
for
a
desktop
application,
does
it
require
web
view
too?
So
the
question
is
slightly
orthogonal
anywhere.
B
If
your
application
can
render-
or
this
in
this
case
web,
you
can
render
the
azure
active,
directory's
login
screen.
It
will
work,
because
there
is
nothing
special
that
is
going
on.
It's
the
same
login
screen
where
you
use
to
sign
in
provide
credentials
change
your
password
respond
to
a
you
know,
get
a
message
asking
you
to
respond
to
an
mfa.
So
this
particular
feature
has
nothing
to
do
with
the
actual
capabilities
that
the
of
of
rendering
the
azure
active,
directory's
authentication
screen.
B
B
Client
capabilities
optional
is
actually
something
that
we
you
might
have
seen
in
our
code,
where
what
you
do
is
useful
if
you
are
an
app
developer
and
you
have
an
api
which
has
to
support
legacy,
clients
which
do
not
understand
the
claims,
request
and
claims
challenges,
and
you
might
want
to
continue
to
basically
change
your
behavior
depending
upon
whether
the
client
is
capable
or
understand,
understands
the
the
new
protocol.
Extensions
and,
in
this
case,
basically
make
sure
that
you
don't
send
claims
challenges
to
clients
who
do
not
understand
them.
B
It
is
baked
into
our
code.
Essentially,
it
is
sent
to
you
in
a
claim
called
xms
underscore
cc
and
we
only
support
a
value
of
cp1.
I'm
sorry,
I
will
not
be
covering
this
in
detail.
It's
explained
in
much
detail
in
the
documentation
and
the
code,
and
I
would
suggest
you
use
it
if
you
are
interested-
and
you
want
to
support
this
in
your
application.
B
Cp1
is
the
only
value
that
supported
and
if
you
do
this
code
to
support
cp1
and
the
consent
handler
to
redirect
the
user
for
claims
request,
your
application
will
automatically
also
support
continuous
access
evaluation
challenges
from
microsoft
graph.
So
that's
one
of
the
benefits
of
using
rims
request
is,
if
you
are
using
it
in
your
app
today.
B
So
this
is
how
a
token
looks
with
when
you
have
the
client
capabilities
enabled
you
need
to
do
this
today.
If
you
have
a
token
access
token
for
microsoft
graph
and
you
expect
to
attend
to
the
claims
challenges
that
microsoft
graphs
throws
when
a
continuous
access
evaluation
events,
one
more
thing
that
we
wanted
to
cover
before
we
finish.
This
is
understanding
the
personas
and
responsibilities
in
case
of
using
an
auth
context.
B
This
is
a
context
where
you
as
a
developer.
You
have
to
work
with
your
id
admins,
it's
not
something
that
you
can
achieve
alone
as
a
developer.
The
reasons
are
quite
straightforward.
The
conditional
access
policies
are
almost
always
crafted
and
maintained
by
iit
admins.
It
requires
the
person
who
works
with
ca
policies
today
needs
to
have
a
good
understanding
of
the
resources
available.
That
policies
can
be
applied
to
like
how
many
users
of
the
tenant
are
actually
keep
to
use.
Mfa
are
so
they
basically
can
make
these
decisions
better
than
developers.
B
So
it
is
always
good
to
let
the
it
admits,
define
the
auth
context,
use
them
into
the
ca
policies
and
developers
should.
Basically,
we
advise
them
to
start
using
the
auth
context
via
microsoft
graph.
Let
the
id
admins
do
the
different
definition
and
the
policy
crafting
from
a
developer
perspective.
You
should
only
be
using
microsoft
graph
to
first
see
what
auth
contexts
are
available
and
then
accordingly
use
them
in
your
application.
B
This
will
keep
the
bridge
well
working
for
you,
especially
if
you
have
your
isv,
who
is
building
sas
applications
and
you
have
to
work
in
multiple
customer
tenants.
The
availability
of
our
context
will
differ
from
10
into
tenant,
so
it's
quite
important
that
you
use
the
microsoft
graph
api
to
enumerate
and
use
those
rather
than
to
assume
and
use
something
like
c1
or
c2
hard
coded
in
your
code
today.
B
A
B
B
Okay,
thank
you.
So
there's
another
question
around
how
to
satisfy
some
of
these
policies.
I
understand
that
the
policy
definition
and
applicability
differs
from
clients
and
operating
systems
and
the
tools
being
used
today.
The
feature
in
itself
is
not
tied
to
those
the
some.
I
understand
we
have
some
challenges
there
in
terms
of
policy,
implementation
and
rollouts.
B
This
particular
topic
is
more
for
the
app
developer
to
demand
authentication
context
and
remain
in
a
space
where
they're
not
really
even
aware
of
what
ca
policies
are
out
there.
They
basically
just
work
with
these
auth
context.
Ids
c1
to
c25
and
the
actual
applicability
would
always
be
with
the
id
admins
who
would
be
able
to
craft
policies
depending
upon
the
limitations
or
the
capabilities
of
end
users
and
devices.
That's
the
best
answer
I
can
do.