►
Description
In this 26-minute developer-focused demo, Philippe Signoret from the Microsoft Identity team demystifies permissions and consent when accessing Microsoft Graph. Most Microsoft Graph permissions allow access to lots of data. Learn how apps and services access Microsoft Graph resources - application permissions and delegated permissions, requesting permissions, granting permissions, and restricting data access scope. Covers general concepts like direct access, access on behalf of user, app and user authorizations, permission types, service principals, consents and more. This PnP Community demo is taken from the Microsoft Graph community call – May 2021, recorded on May 4, 2021.
Demo Presenter - Philippe Signoret (Microsoft) | @psignoret
Stay connected:
• Twitter - https://twitter.com/microsoft365dev
• YouTube - https://aka.ms/M365DevYouTube
• Microsoft 365 Developer Blog - https://aka.ms/M365DevBlog
• Microsoft 365 PnP Blog - https://aka.ms/m365pnp/community/blog
A
So
today
I
want
to
talk
a
little
bit
about
api
permissions
and
consent,
in
particular
when
it
comes
for
permissions
and
consent
for
access
to
microsoft
graph
and
rather
than
do
what
we've
done
other
times,
which
is
sort
of
to
show
you
how
you
use
msl
or
the
graph
sdk
to
to
request
the
token
and
get
access
I
wanted
to
take
it.
Maybe
a
step
back
and
sort
of
talk
about
some,
some
more
general
concepts
around
authorization
for
applications
accessing
apis
in
general
and
specifically
microsoft
graph.
A
So
some
of
the
topics
that
we're
going
to
cover
today
is
basically
just
in
general
how
apps
and
services
can
access
microsoft
graph,
which
will
lead
us
to
two
of
these
authorization
flavors,
which
is
application.
Permissions
and
delegated
permissions
we'll
go
over
the
concepts.
Some
of
the
ways
in
which
permissions
can
be
requested
we'll
go
over
some
of
the
ways
in
which
permissions
can
be
granted,
and
then
I
think,
most
importantly,
we'll
talk
about
sort
of
some
of
the
aspects
regarding
to
how
much
data
these
permissions
grant
access
to
and
what
alternatives
we
have
for.
A
Restricting
the
the
set
of
data
the
permissions
give
access
to
so
just
to
very,
very
broadly,
whenever
an
app
or
a
service
needs
to
access
data,
let's
just
say
in
general,
through
an
api.
There
are
two
ways
in
which
this
data
can
be
accessed.
Two
ways
in
which
that
the
microsoft
identity
platform
explicitly
supports
one
of
them
is
what
we
call
direct
access.
The
the
application
is
is
not
there's
no
user
involved.
The
application
is
just
directly
going
and
going
to
try
to
perform
an
action.
A
Read
the
data
download,
a
file,
create
a
file
update,
a
user
reset,
a
password,
etc.
That's
one
flavor
direct
access.
The
second
flavor
is
and
indirect
access
the
api,
so
microsoft
graph.
If
you're
calling
microsoft
graph
is
going
to
ask
just
one
question
in
terms
of
authorization,
and
the
question
is:
is
this
app
authorized?
A
A
The
other
form
is
when
the
application
is
not
doing
what
we
call
direct
access,
it's
actually
accessing
on
behalf
of
a
user.
We
also
call
this
sometimes
delegated
access
or
apples
user
access.
That's
why,
in
this
diagram,
there's
a
user
and
an
application
on
the
left
and
then
the
api
is
on
the
right
and
the
little
token,
if
you,
if
you
notice
the
pentagon
in
the
middle,
is,
is
the
user
right,
because
the
the
the
thing
that's
identified.
That's
making
this
request
is
the
user,
and
so
the
first
question
is
not
is
the
app
authorized?
A
The
first
user
is
actually
is
the
user
authorized,
and
so
that
question
that
first
question
on
both
sides
is
actually
the
same
question.
It's
is
the
subject
authorized.
It
just
turns
out
that,
on
the
left,
the
subject
is
the
application
or
technically
the
application
service
principle
and
on
the
right,
it's
the
user.
So,
ultimately,
the
question
is:
is
the
thing
or
person
that's
identified
by
in
this
api
request?
Are
they
authorized
to
take
this
action?
A
That's
the
first
question
now
when
an
application
is
accessing
on
behalf
of
a
user,
it's
the
application
is,
is
not
allowed
to
do
anything
it
wants
on
behalf
of
the
user.
The
application
will
be
restricted
and
limited
or
a
scoped
is
another
term
we
use
to
what
it
can
do
on
behalf
of
the
user.
So
there's
a
second
question
in
terms
of
authorization,
which
is
with
that
the
api
will
ask.
Is
the
app
allowed
to
do
this
on
behalf
of
this
user
right,
and
so
when
it's
access
on
behalf
of
a
user?
A
A
If
you
imagine
a
list
of
everything
that
a
user
is
allowed
to,
do
all
the
actions,
read
files
or
read
this
one
file
list,
all
users
etc,
all
the
actions
user
could
do,
and
then
you
list,
you
have
a
list
of
all
the
things
that
the
application
is
allowed
to
do
on
behalf
of
that
user.
Then
you
intersect
the
two:
that's
what
the
application
will
also
actually
be
able
to
do.
A
The
application
won't
be
able
to
do
something
that
the
user
themselves
is
not
allowed
to
do,
which
is
one
of
the
big
benefits
of
this
form,
because
there's
no
risk
of
the
application
accidentally
allowing
the
user
to
do
something.
The
user
shouldn't
have
been
able
to
do,
and
the
user
won't
be
able
to
use
the
application
to
do
something
that
they
wouldn't
otherwise
be
allowed
to.
A
For
these
two
forms
of
access.
We
have
two
types
of
permissions.
So
when
we're
talking
about
permissions
for
access
on
behalf
of
a
user,
we
have
something
we
call
delegated
permissions,
and
these
delegated
permissions
are
used
for
answering
that
second
question:
it's
for,
representing
what
an
application
is
allowed
to
do.
A
On
behalf
of
a
user,
and
so
when
we
say
an
application,
has
the
delegated
permission,
user.read.all
we're
not
saying
the
application
can
read
all
users,
we're
saying
the
application
can
read
all
users
on
behalf
of
a
user,
and
so
whether
or
not
the
application
will
actually
be
able
to
read.
All
users
depends
on
whether
the
signed
in
user
is
allowed
to
read
all
users,
and
so,
if
the
sign
in
user,
for
example,
is
a
guest
user
who's
not
by
default,
allowed
to
read
all
users
that
won't
work.
A
But
if
the
sign
in
user
is
a
regular
member
user,
then
yes,
they'll
be
able
to
list
all
users
for
direct
access.
One
form
we
have
for
granting
the
permission
to
access
data
directly
microsoft
graph
is
what
we
call
application
permissions.
We
also
call
them
app
roles.
Apples
is
actually
the
more
general
term.
There
are
two
flavors
of
apple
or
actually,
technically
speaking,
there's
one
flavor
of
april
that
can
be
configured
to
be
an
apple
that
can
be
given
to
a
user.
A
We
don't
use
those
for
microsoft
graph,
but
we
can
also
have
apples
that
can
be
granted
to
applications
or
to
application
service
principles
and
the
app
roles
that
can
are
configured
so
that
they
can
be
assigned
to
other
applications.
That's
that's
what
we
call
application
permissions,
but
really
they're,
just
apples,
and
so
every
api
that's
registered
in
the
microsoft
identity
platform,
including
microsoft
graph,
can
define
a
list
of
application,
permissions
or
a
list
of
app
roles,
and
they
can
define
a
list
of
delegated
permissions
and
so
microsoft.
A
As
the
publisher
of
the
microsoft
graph
application,
we've
defined
a
list
of
application
permission,
a
pretty
long
list
and
a
list
of
delegated
permissions.
One
thing
to
keep
in
mind
is
that
it
is
for
especially
for
direct
access
application.
Permissions
are
not
the
only
way
to
authorize
an
application
to
access
data
through
microsoft,
graph
or
through
other
apis,
and
one
good
example
of
an
api
that
doesn't
rely
on
application.
Permissions
for
authorization
for
direct
access
would
be
azure.
A
So,
if
anybody's
familiar
with
the
azure
management
api,
there
are
no
application
permissions
instead
directly
in
azure,
an
application
or
a
service
principle
that
represents
an
application,
can
be
granted
a
role
in
an
azure
subscription
and
can
be
given
access
to
data
directly
like
that.
That
application
is
still
going
to
use
microsoft,
identity
platform
to
get
a
token,
for
example,
to
azure,
but
that
token
won't
identify
any
application.
Permissions
it'll
say:
look,
I
don't
know
what
they
have
access
to,
but
this
is
who
they
are,
and
then
it
is
the
resource.
A
The
api
in
this
example
azure
the
azure
management
api.
That's
going
to
look
and
see.
Okay,
do
they
have
access?
The
same
applies
for
microsoft.
Graph
except
microsoft.
Graph
also
has
application
permissions,
so
it
is
possible
and
in
some
cases,
explicitly
supported
for
applications
to
be
granted
other
forms
of
permission
to
access
data,
for
example
an
application
or,
whenever
I
say,
an
application
in
terms
of
authorization.
I'm
actually
saying
the
service
principle
for
an
application
within
a
customer's
tenant
can
be
made
owner
of
a
group
and
when
a
service
principal
is
owner
of
a
group.
A
A
Likewise,
a
service
principle
can
be
assigned
a
directory
role,
it's
possible
to
take,
let's
say
the
application
administrator
directory
role,
assign
it
to
a
service
principal
and
let's
make
it
even
fancier,
let's
assign
it
to
a
service
principle,
but
scoped
only
to
one
other
service
principle.
So
we've
taken
a
service
principle
representing
your
application
we've,
given
it
the
role,
application
administrator,
but
only
over
one
other
service
principle,
and
so
by
that
point,
that
application
will
be
able
to
get
a
token
call
graph
and
make
use
of
that.
A
So
it's
a
really
important
point
to
call
out
is
that
not
all
forms
of
authorization
are
necessarily
going
to
be
application,
permissions
and
delegated
permissions.
It's
also
possible
for
apps
to
be
authorized
in
other
ways,
but
going
back
to
these
two
forms.
One
thing
that's
particular
about
the
two.
A
These
two
types
of
permissions
application
permissions
and
delegated
permissions-
is
that
they
can
be
requested
and
there's
this
experience
that
we
call
consent
where
the
application
developer,
the
application,
publisher,
requests
permissions
and
then
the
customer
that's
trying
to
use
that
application
has
an
opportunity
to
grant
those
permissions
and
then
microsoft,
identity
platform
is
sitting
in
the
middle,
helping
orchestrate
this
negotiation.
Let's
say
all
right,
so
one
way
in
which
an
application
can
request
permissions
for
microsoft.
A
Graph
is
during
sign
in
right,
so
during
sign
in
using,
of
course,
a
library
like
emcell,
an
application
can
dynamically
request
permissions
in
this
case
delegated
permissions.
Now
we
know
it's
delegated
permissions
because
I
said
during
sign
in
so.
If
it's
during
sign
in
it
means
there's
a
user
involved,
and
so
necessarily
we're
talking
about
those
permissions
that
are
on
behalf
of
the
user.
An
applicant
can
dynamically
request
a
list
of
permissions.
In
this
example,
user,
read
and
user
read
basic
call.
Now.
A
A
The
other
way
to
do
this,
it's
also
as
part
of
sign
in,
is
what
we
call
static,
consent
and
off
requesting
the
whatever
permissions
have
been
configured
so
here,
instead
of
requesting
any
list
of
permissions,
we're
just
saying
dot
default
or
technically,
because
if
omitted,
we
assume
it's
microsoft
graph.
This
would
be
https
graph.microsoft.com
dot
default,
and
what
that
means
is
the
application
is
trying
to
get
access
to
microsoft
graph.
But
it's
not
stating
what
permissions.
A
If
these
permissions
are
granted
in
this
case,
this
will
actually
revoke
anything
that
was
granted
previously.
This
does
allow
configuring
both
application,
permissions
and
delegated
permissions.
So
when
it
comes
to
granting
the
permission,
so
we
talked
about
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.
A
We
talked
about
how,
during
sign-in
or
through
the
configuration
you
can
configure
your
client
application
to
request
permissions
and
when
it
comes
to
granting
permissions,
one
way
to
grant
permissions
is
through
the
consent
experience.
So
when
an
app
requests
access,
the
user,
that's
signing
into
the
app
might
be
prompted
for
consent.
It's
very
important-
and
this
is
an
example
of
a
consent
screen
for
the
microsoft
graph
explorer
application
trying
to
get
access
to
graph
right.
A
In
this
example,
the
user
here
was
allowed
to
consent
to
these
permissions
and
they
actually
have
the
option
to
accept,
but
it's
very
possible
that
a
user
signing
into
an
application
will
actually
not
be
allowed
to.
Every
customer
can
configure
when
users
are
allowed
to
consent
and
which
users
are
allowed
to
consent
for
applications,
and
customers
can
take
into
account
publisher
verification.
So
in
this
example
here
it
is,
they
verified
the
app
does
come
from
verified
publisher.
They
can
take
into
account.
A
Customers
can
choose
permission,
classifications
and
say:
look
I'll
only
allow
users
to
consent
to
permissions
from
verified
publishers,
and
only
if
they're,
one
of
these
permissions
that
I've
classified
low
and
then
there
are
other
conditions
such
as
where
the
app
was
registered,
maybe
an
individual
trusted,
app
publisher,
etc.
So
there's
lots
of
variables
and
as
an
app
developer,
you
should
never
assume
that
users
will
be
able
to
consent
to
your
application.
A
Now,
consent
is
one
way
and
what
we
actually
walk
through
here
is
what
we
call
user
consent
where
a
user's
consenting
for
delegated
permissions
on
behalf
of
themselves.
There
are
a
few
other
flavors
or
forms
of
granting
these
two
permissions
that
we've
talked
about
the
first
one
is
admin,
consent
or
tenant-wide
admin
consent,
as
the
name
suggests.
This
is
something
that
is
a
very
privileged
operation
that
normally
an
administrator
would
do
by
default,
global
administrator.
A
In
some
cases,
application
administrator
can
do
right.
This
is
for
granting
tenant-wide
consent.
So
we're
not
saying
this
application.
You
can
do
these
permissions
on
behalf
of
this
one
user,
we're
actually
saying
on
behalf
of
all
users,
so
any
other
user
in
the
organization
who
signs
into
that
same
application.
A
Admin
consent
can
be
triggered
by
the
application
by
redirecting
the
user
off
to
a
special
url.
They
can
be
done
from
the
azure
portal
from
the
the
admin
consent,
request,
queue
or
just
from
under
the
apps
listed
in
enterprise
apps
and
some
customers
have
taken
to
constructing
the
admin
consent
url
themselves.
There's
lots
of
forms
of
this.
This
works
for
both
there's
a
flavor
for
dynamic
and
for
static.
In
this
example.
A
Here
we've
an
example
of
admin
consent
using
the
static
approach
where
it's
just
for
whatever
is
configured
then,
in
addition
to
that,
customers
can
use
microsoft
graph
to
grant
permissions
so
application
permissions,
as
I
mentioned,
are
actually
app
roles
and
so
to
grant
an
application
permission.
You
create
an
app
role
assignment
delegated
permissions
in
microsoft.
Graph
are
represented
as
something
we
call.
Oauth
2
permissions
or
oauth
2
permission
scopes
and
to
grant
them.
A
What
you
create
is
an
oauth
2
permission
grant
and
an
app
role
is
very
simple:
it
identifies
the
api,
it
identifies
the
client
app
service
principle
and
identifies
which
app
role
so,
which
application
permission
and
delegated
permission
is
basically
the
same.
There's
the
client
application,
the
api,
the
permission
or
actually
the
list
of
delegated
permissions,
but
there's
an
extra
thing
which
is
on
behalf
of
whom,
on
behalf
of
one
user
or
on
behalf
of
all
users,
so
both
of
those
can
be
done
with
microsoft.
A
A
Almost
every
application
permission
is
what
we
call
tenant
wide
right
all
files
in
the
entire
organization,
the
files.read.all
permission,
delegated
permissions
are
restricted
to
what
the
user
can
access,
but
within
the
scope
of
what
the
user
can
access.
It's
any
file
in
the
organization
that
the
signed
in
user
can
access.
Many
users
can
access
a
lot
of
files
and
some
of
them
might
be
quite
sensitive,
and
it
might
be
that
the
application
really
needs
access
to
some
of
them.
A
Other
permissions
do
actually
limit
which
resources
can
be
accessed
so,
for
example,
the
user.read
permission
only
allows
reading
one
user
profile
and
that's
the
user
profile
of
the
signed
in
user.
Mail.Read
likewise
only
allows
accessing
one
mailbox,
which
is
the
mailbox
for
the
signed
in
user.
So
these
are
examples
of
delegated
permissions
that
do
restrict
the
set
of
resources,
but
it's
important
to
keep
in
mind
that
that's
why
many
of
the
other
permissions
end
in
all,
because
it's
for
a
lot
of
things
now.
A
Even
delegated
permissions,
though,
can
also
be
very
broad
or
very
sensitive,
for
example,
and
what
ends
up
becoming
most
important
there
is
who
is
signing
in
if
an
administrator
signs
in
and
an
application
has
been
granted
the
delegated
permission
to
take
administrative
actions,
and
if
you
have
an
admin.
Well,
you
can
do
anything.
You
want
basically,
at
that
point,
if
the
ceo
of
the
company
or
some
other
user,
with
access
to
highly
sensitive
data
signs
in
the
application
might
have
access
to
that
data.
A
So
that's
something
to
keep
in
mind
and
a
very
good
reason
to
make
sure
you're
only
asking
for
access
your
application
really
needs.
There
are
some
capabilities
available
today
and
more
coming
soon
to
restrict
the
set
of
resources
that
an
app
can
access
so
for
mail,
calendar
and
contacts,
so
things
in
exchange
online.
We
have
something
today
called
exchange
app
access
policies
that
can
allow
limiting
the
set
of
mailboxes.
The
app
has
access
to
a
set
of
calendars,
a
set
of
user,
mailboxes,
etc.
A
So
that's
one
of
the
limitations
today,
as
I
mentioned,
we're
working
on
some
changes
in
this
area,
coming
up
teams,
channels
and
conversations,
and
what
we're
working
on
is
in
general
for
for
ways
to
to
restrict
access
for
teams,
channels
and
conversations
a
team
owner.
So
this
is
in
microsoft.
Teams
a
team
owner
can
consent
when
installing
a
team's
app
to
only
give
the
app
access
to
that
team.
A
We
can
restrict
that
to
just
the
data
for
a
specific
team
and
it's
the
team
in
which
the
app
was
installed
for
sites.
We
have
a
new
capability,
sharepoint
site
collections,
there's
a
new
capability
that
allows
an
admin
to
consent
to
sites.selected,
which
is
a
restriction
basically
saying
hey.
This
app
has
access
to
specific
individual
sites
and
then
on
sharepoint
using
microsoft.
Graph
can
say:
okay.
A
Looking
at
time,
I'm
going
to
wrap
up
there,
a
few
reminders
is,
as
an
app
developer,
always
ask
for
release
privilege
permissions,
keep
an
eye
on
the
graph
api
and
once
in
a
while,
just
check
in
to
see
if
there's
any
new
permissions,
especially
if
some
permission
in
particular
is
causing
you
heartache,
because
you
have
to
ask
for
it
or
difficulty
for
your
customer
customers
to
actually
grant
access,
because
it's
more
privileged
than
you
actually
need
to
you.
Just
don't
have
any
other
option.
A
We're
constantly
working
on
defining
new
permissions
that
are
lesser
privileged
to
allow
more
granularity
there
and
as
an
app
customer,
do
keep
in
mind.
If
you
see
an
application,
that's
asking
for
more
than
you
think
it
needs
dig
into
that,
find
out
why
and
and
often
challenging
the
application,
publisher
or
developer.
The
result
is
oh
yeah.
A
I
was
actually
just
testing
and
I
finally
found
a
combination
that
worked
and
I
stopped
there
and
maybe
there's
something
better
than
that
and
on
our
side,
we're
working
at
microsoft,
we're
working
on
some
ways
to
better
inform
developers
and
customers
on
what
the
best
combination
is
for
the
scenarios
always
prefer
delegated
access,
so
access
on
behalf
of
a
user
over
direct
access.
If
there's
a
user
involved
right.
So
if
there's
a
user
involved,
you
don't
want
your
application,
which
has
been
granted
more
access
than
the
user.
A
To
be
the
reason
the
user
was
exposed
to
data
they
weren't
supposed
to
see
and
delegated
access
not
only
restricts
the
scope
of
access
of
your
application,
which
is
a
good
thing.
It
make
sure
that
the
rules
that
are
enforced
include
the
authorization
for
whatever
whoever
signed
it.
Then,
whenever
you
can,
if
you're
doing
a
teams
app
if
you're
accessing
sharepoint
always
use
these
options
to
have
lesser
privilege
and
smaller
scopes
of
access
wherever
possible,
and
you
can
expect
that
moving
forward,
there
will
be
more
opportunities
for
this
all
right
in
one
minute.
A
A
Generally
speaking,
a
role
or
authorization
in
general
will
not
be
given
to
an
app
registration.
It
will
be
given
to
the
service
principal.
I
only
make
that
distinction,
because
if
you
ever
try
to
do
it
through
graph
or
something
you
won't
want
to
assign
a
role
to
the
application
entity,
you
want
to
assign
it
to
the
service
principal
entity
that
maps
to
that
application.
So
technically
it
is
possible
to
take
any
directory
role
and
assign
it
to
any
service
principal,
but
that
doesn't
necessarily
mean
that
the
result
will
be
what
you
expected.
A
Ideally
it
would,
but
today
there
are
some
directory
roles
that
don't
work
or
are
not
recognized
in
some
areas
of
microsoft,
graph
and
microsoft
365
in
general
directionally.
We
want
all
of
these
roles
to
work
for
all
of
them,
so
it
is
possible
to
take
the
teams
communication
support
specialist,
to
sign
it
to
a
service
principal
so
that
application
can
then
use
the
direct
access
flavor
get
an
app
only
access
token.
The
question,
then,
is:
will
this
work
and
do
what
you're
expected
to
do
and
to
answer
that
question?
A
B
Excellent.
Thank
you
so
much
for,
like
that
was
excellent
overview
of
afternoon
really
getting
some
of
the
the
nice
details.
I'm
sure
a
lot
of
people
are
having
questions
about,
so
thank
you
so
much
for
that.
Yes,
see.
A
lot
of
applause
is
now
in
the
thanksgiving
bottom
of
motion,
so
excellent.
Thank
you
so
much
again
for
your
time
and
really
appreciate.