►
Description
In this 15-minute Developer-focused demo, Philippe Signoret demystifies the identity model with a clearly delivered 100 level overview of app permissions - operation and terminology, i.e., delegation, requests, grants, consent, tokens, etc. How app/services permission delegation works, how tokens are aligned to a machine or to a person. Is the app or person authorized to access resources? How and when machines dynamically/statically request permissions and more. This PnP Community demo is taken from the General Microsoft 365 Development Special Interest Group (SIG) - Bi-weekly sync call recorded on April 29, 2021.
Demo Presenter: Philippe Signoret (Microsoft) | @psignoret
Learn more:
• Learn more about the Microsoft 365 Patterns and Practices community at: http://aka.ms/m365pnp
• Visit the Microsoft 365 Patterns and Practices community YouTube channel: https://aka.ms/m365pnp-videos
A
My
name
is
felipe
signore,
I'm
a
program
manager
at
microsoft,
in
the
ada
entity
division
and
today
I'm
going
to
talk
a
bit
about
delegated
permissions
and
application
permissions
in
the
microsoft
identity
platform.
This
is
indeed
similar
to
a
talk
I
gave
for
the
mvp
summit.
I
changed
things
around
just
in
case
you'd
already
seen
the
mvp
summit
one
and
some
things
are
a
little
bit
different,
but
generally
it's
the
same.
A
So
when
we
talk
about
applications,
forget
the
title
of
the
session
white
application
permissions
delegated
permissions.
Let's
just
talk
about
how
applications
and
services
actually
access
data.
There
are
two
ways
we're
going
to
talk
about
today
in
which
an
application
or
a
service
I'll
use,
those
interchangeably
can
access
data
at
a
service
and
when
I
say
access
data
generally
speaking,
we're
talking
about
an
api
request,
not
necessarily
rest,
but
usually
some
form
of
api
right.
The
one
simple
way
is
direct
access,
also
known
as
service
to
service.
A
We
sometimes
refer
to
it
in
our
documentation
or
on
stack
overflow
answers.
That's
app
only
access-
and
this
is
it's
very
simple-
there's
a
client
application
or
service,
which
is
the
one
on
the
left,
and
then
we
have
a
resource
application
or
service,
which
is
the
one
on
the
right
and
the
client
application
is
accessing
the
the
resource
service
directly
as
itself.
There's
no
user
involved.
It's
saying,
hi,
I'm
client
I'd
like
to
do
take
this
action
at
you.
A
If
the
resource
in
this
example
would
be
microsoft
graph,
the
client
could
be
trying
to
create
a
user
or
reset
a
password
or
download
a
file,
and
this
is
so
that's
one
form
of
access.
Direct
access,
pretty
straightforward.
The
other
form
of
access
is
access
on
behalf
of
a
user
right,
so
we
have
a
user
involved.
A
As
the
subject
of
the
token
and
that's
an
important
that
will
be
an
important
thing
in
the
next
few
slides
when
we're
talking
about
access
on
behalf
of
a
user,
we
often
just
to
decode
some
of
the
terms
we
use.
We
sometimes
refer
to
this
as
delegated
access.
Sometimes
we
call
it
hapless
user
access
very.
In
some
cases,
I've
heard
him
constrained
impersonation
or
impersonation
access,
but
all
of
these
are
access
on
behalf
of
a
user.
A
One
important
thing
to
call
out
here
is
that
on
the
identity
platform,
this
is
always
on
behalf
of
a
signed
in
user,
so
a
user
that
at
some
point
in
time,
actually
signed
into
the
application
as
opposed
to
arbitrary
impersonation
of
any
user
who
didn't
actually
sign
it
right.
So
these
are
the
two
forms
of
access
that
we're
going
to
be
talking
about
the
the
what
I'm
talking
about
here
I
mentioned
often
the
resource
or
the
api.
A
You
can,
of
course,
always
imagine
think
of
microsoft,
graph
as
a
good
example
of
an
api,
but
there's
also
the
azure
management
apis
or
apis
that
you,
you
develop,
I'm
laughing
at
the
comments,
direct
access.
So
when
we
have
direct
access
again,
just
the
client
accessing
the
resource,
the
resource
needs
to
make
a
decision
and
for
in
terms
of
authorization.
It's
asking
a
very
simple
question:
is
the
app
authorized
to
do
this
a
little
bit?
More
generally
is
the
subject
of
the
token
authorized
to
take
this
action
right
and
on
the
identity
platform.
A
We
offer
a
permit
a
type
of
permission
or
permissions
for
direct
access,
and
we
call
them
app
roles
and
when
it
turns
out
that
app
roles
are
granted
to
other
applications,
we
just
change
the
name
and
we
call
them
application
permissions,
but
app
roles
or
application.
Permissions
for
this
conversation
are
interchangeable
and
they're
just
a
way
of
expressing
authorization
that
is
used
for
direct
access
now.
One
very
important
thing
to
keep
in
mind
in
particular
for
direct
access
is
that
there
are
actually
many
ways
in
which
an
application
can
be
given.
A
Authorization
for
direct
access,
application,
permissions
and
apples
is
just
one
of
those
ways
and
it's
a
very
common
way
for
reasons
we'll
see
in
a
bit,
but
many
other
ways
are
possible.
For
example,
if
you
think,
if
you're
familiar
with
how
azure
does
authorization
for
direct
access
for
applications,
there's
no
app
role,
there's
an
azure
rbac
role
assignment
and
it's
granted
to
the
service
principal
that
represents
the
application
in
that
tenant.
But
there's
no
consent
for
an
app-only
permission
like
there
is
for
microsoft
graph.
A
So
likewise
you
can
assign
a
directory
role
to
an
application
or
you
can
make
a
service
principal
owner
of
a
group
or
of
another
service
principal,
and
that
is
giving
it
authorization
to
do
things
or
make
it
a
member
of
a
group,
etc.
So
always
keep
in
mind
that
there
are
many
different
ways
in
which
an
application
can
be
given
authorization
and
if
you're,
building
an
api
or
others
have
built
apis.
A
They
could
also
just
have
a
list
internally.
That
says:
hey
these
applications
are
allowed
to
take
these
actions,
and
that
would
be
another
form
of
authorization,
but
all
of
that
is
for
direct
access
when
it
comes
to
access
on
behalf
of
a
user.
Authorization
is
a
little
bit
different,
but
it's
when
you
look
at
it.
It's
actually
the
same
thing.
There's
just
one
extra
question
right:
the
first
question
is
very
similar
to
the
previous
one
is:
is
the
user
authorized
to
take
this
action
in
the
previous
case
for
direct
access?
It
was.
A
Is
the
app
authorized
to
take
this
action
now
again?
The
the
more
general
question
being
asked
here
is:
very
simply.
Is
the
subject
authorized
to
take
this
action?
The
subject
is
a
user?
Is
it?
Is
the
user
allowed
the
subject
as
an
app?
Is
the
app
allowed
right,
and
so
we're
always
going
to
ask
that
question
is?
A
Is
the
person
I
or
the
thing
identified
in
the
token
authorized
to
take
this
action,
but
in
the
case
of
access
on
behalf
of
a
user
there's
a
second
question,
the
resource
always
has
to
ask
and
is,
and
that
question
is,
is
the
app
allowed
to
take
this
action
on
behalf
of
the
user
right
and
the
microsoft
identity
platform
offers
delegated
permissions
to
help
answer?
That
second
question
right:
is
the
app
authorized
to
do
this
on
behalf
of
the
user?
A
It's
delegated
permissions
have
no
say
whatsoever
and
whether
the
user
is
allowed
to
take
an
action.
Delegated
permissions
are
only
for
expressing
whether
an
app
is
allowed
to
do
something
on
behalf
of
the
user
right.
So
it's
always
important
to
keep
in
mind
that
the
user
needs
to
be
authorized
and
the
app
needs
to
be
allowed
to
do
what
it's
trying
to
do
on
behalf
of
the
user.
There
are
lots
of
ways
to
look
at
this.
One
way
to
explain
it
is
sort
of
how
I've
done
it
now.
A
Another
fairly
common
way
to
explain
it
is
to
say
you
can
imagine
everything
the
user
can
do.
You
can
email.
So
imagine
everything
the
app
has
been
allowed
to
do
on
behalf
of
the
user
and
what
the
app
can
actually
do
is
the
intersection
right.
It's
the
things
the
user
can
do
and
the
app
has
been
allowed
to
do
on
behalf
of
the
user,
so
just
to
walk
through
an
example.
Real
quick
of
this
here,
I'm
using
microsoft
graph
as
the
example
api.
But
again
you
can
imagine
this
being
a
different
api.
A
In
the
first
case,
we're
trying
to
list
users
we're
doing
a
get
for
users
and,
as
always,
the
first
question,
because
these
are
all
access
on
behalf
of
the
user
is,
is
the
user
allowed
to
do
this?
And
if
the
case
of
a
guest
user,
which
is
this
row,
it
happens
to
be
a
get
the
user
signed
in
as
a
guest
user?
A
Well,
the
answer
is
no,
because
guest
users
by
default
are
not
allowed
to
list
all
users,
and
so
we
would
answer
no
immediately
and
the
resource
in
this
case,
microsoft
graph
would
would
just
stop
there.
It
wouldn't
even
ask
the
second
question
and
say
no
user
is
not
allowed,
so
I
won't
even
check
if
the
app
now
in
this
case
it
turns
out
that
the
app
is
allowed
to
take
this
action
on
behalf
of
the
user,
but
that's
irrelevant
because
the
user
themselves
can't
do
it
right.
A
So
the
result
for
this
request
would
actually
be
an
authorization
failure.
The
second
example
the
app
the
user
is
a
global
administrator,
but
the
user,
the
and
the
app
is
trying
to
delete
a
user
right
now.
So
again,
the
answer
to
the
first
question:
is
the
user
allowed
to
do
this?
Well,
yep
global
admins
are
allowed
to
delete
users
unless
that
user
happened
to
be
the
global
admin
themselves.
But
let's
assume
that
wasn't
the
case.
A
The
second
question,
though,
is,
can
the
app
do
it
on
behalf
of
the
user
and
in
this
example,
because
the
app
had
only
been
granted
the
delegated
permission
directory
read
all
which
does
not
include
the
permission
to
delete
users.
The
answer
here
again
is
well:
no,
you
can't
do
it,
the
user
is
allowed,
but
the
app
is
not,
and
that
middle
row
is
the
reason
why
delegated
permissions
exist.
A
A
So
now
we
haven't
talked
so
far
about
like
okay,
great.
We
have
direct
access
access
on
behalf
of
a
user
for
direct
access.
We
have
application
permissions
for
access
on
behalf
of
a
user.
We
have
delegated
permissions.
How
does
an
application
request
them
and
how
does
it
get?
How
do
they
get
granted?
A
So
one
way
permissions
can
be
requested
by
an
application
by
a
developer,
who
wrote
the
code
so
that
the
application
would
do.
It
is
dream
sign-in
and
that's
a
very
common
approach.
So
if
there's
now
as
soon
as
we
say
during
sign-in,
that
means
there's
a
user
and
so
we're
usually
talking
about
delegated
access
and
delegated
permissions.
A
So
an
application
can
during
sign
in
can
dynamically
request
a
list
of
delegated
permissions,
and
that's
just
part
of
the
protocol
open
eddy
connect.
In
this
case,
we
use
the
scope
parameter
where
you
can
identify
the
resource.
In
this
example,
the
resource
would
be
widgets.example.com
and
the
delegated
permission
at
that
resource
right.
So
every
resource
registration,
the
app
registration
for
an
api
or
a
resource
can
define
its
list
of
delegated
permissions
and
can
define
its
list
of
apples.
A
In
this
example,
the
permission
is
read:
if
permissions
that
were
requested
dynamically
are
granted
they
get
granted.
In
addition
to
anything
that
was
granted
previously,
we
call
this
incremental
consent.
This
is
useful
so
that
users
are
only
asked
for
what
they
need
at
the
point
in
time
in
which
the
application
needs
it
right.
So
basic
permissions
for
sign
in,
as
you
start
moving
forward.
Yes,
new
features
are
being
used,
then,
at
that
point
in
time
the
application
requests
the
additional
permissions.
A
It
helps
for
least
privilege,
and
it
helps
ensure
some
level
of
interaction
with
the
user
before
they
have
to
go.
Find
the
person
to
to
grant
the
permissions
this
waiver
of
requesting
permission
only
works
for
delegated
permissions.
Then
we
have
the
statically
configured
permission
list
so
this
for
those
familiar
in
the
azure
portal.
Under
app
registrations,
api
permissions,
you
can
choose
a
list
of
application,
permissions
and
delegated
permissions,
and
these
are
the
permissions
that
will
be
asked
for
if
you,
if,
if
the
keyword
dot
default
is
used
instead
of
a
permission
name
right.
A
A
A
Basic
permissions
for
signing
microsoft
will
step
in
and
block
user
consent,
even
if
it
would
otherwise
be
allowed
for
apps
that
we
consider
to
be
either
risky,
or
at
least
not
trustworthy
enough.
So
there
are
some
cases,
depending
on
algorithms,
working
behind
the
scenes
that
will
determine
hey
this.
This
situation
is
not
something
doesn't
look
right,
so
we're
not
going
to
lose
your
consent
when
a
user
is
not
allowed
to
consent
for
themselves.
It's
not
the
end
of
the
world.
They
can
always
go
request
for
admin,
review
and
approval,
and
there's
a
feature
for
that.
A
You
turn
it
on.
If
the
user
is
not
allowed
to
consent,
they
can
click,
request,
admin,
approval
and
provide
the
justification,
and
then
a
workflow
starts
there,
and
so
that
takes
us
to
admin
consent,
which
is
a
very
common
way
in
which
permissions
are
granted
to
applications
through
admin.
Consent
is,
as
the
name
implies,
something
that
a
privileged
operation
only
can
only
be
done
by
an
admin
or
a
sufficiently
privileged
user.
It
applies
tenant
wide.
A
So
when
we're
consenting,
for
example,
for
delegated
permissions
they're
being
granted
on
behalf
of
all
users-
and
it
also
works
now
for
application
permissions
admin
consent
can
be
triggered
by
the
application
itself.
It
can
send
the
user
off
to
the
url.
It
can
be
done
from
the
azure
portal,
or
sometimes
customers
themselves
will
construct
the
url
and
go
there
to
to
grant
admin
consent.
We
could
support
both
dynamic
and
incremental.
A
What
we
mentioned
dynamic
and
static
to
modes
I
mentioned
earlier,
and
one
thing
to
always
keep
in
mind
is
a
customer
can
always
also
manually
grant
access
you
can
you
can
write
a
powershell
script
or
call
graph
directly
to
create
service
principles,
create
app
registrations,
create
app
role,
assignments,
so
grant
application
permissions
or
create
delegated
permission
grants
so
grant
delegated
permissions
now?
Those
of
course
are
extremely
privileged
operations,
especially
if
the
application
doing
this,
the
automation
granting
permissions
is
not
constrained
in
what
permissions
it
can
grant.
A
B
A
B
So-
and
this
is
a
great
great
great
stuff
to
get
recorded
and
as
a
video
for
youtube
as
well.
So
thank
you.
Thank
you,
phillip.
On
that
one,
a
lot
of
people
clearly
happy
on
the
on
the
clarification
so
really
really
great
stuff.
I
think
it's
it's
super
important
that
we
demystify
the
identity
model
because
people
are,
I
don't
think
people
are
educated
enough
or
maybe
it's
too
complicatedly
explained,
but
this
was
a
good
clarification.
How
things
are
actually
working.