►
Description
In this 24-minute developer-focused demo, Paolo Pialorsi delivers an overview of On-Behalf-Of (OBO) flow, tokens, permissions and use in SharePoint Framework. OBO is great for when you need a background task running (in middleware that needs to consume another back-end service like Microsoft Graph) on-behalf-of a user that triggers the middleware from a SharePoint Framework app. 2 OBO scenarios shown - get my personal data via OBO and send Teams chat message via OBO. This PnP Community demo is taken from the Viva Connections & SharePoint Framework Bi-weekly sync call recorded on October 20, 2022.
Demo Presenter
• Paolo Pialorsi (PiaSys) | @PaoloPia
Supporting materials
• Documentation - Microsoft identity platform and OAuth 2.0 On-Behalf-Of flow | https://learn.microsoft.com/azure/active-directory/develop/v2-oauth2-on-behalf-of-flow
• Sample - SPFx On-Behalf-Of flow | https://adoption.microsoft.com/sample-solution-gallery/sample/pnp-spfx-reference-scenarios-spfx-obo/
Learn more
• Microsoft 365 Unified Sample gallery - https://aka.ms/m365/samples
• Microsoft 365 Platform Community in YouTube - https://aka.ms/m365/videos
• Microsoft 365 Platform Community - http://aka.ms/m365/community
A
B
Flow
Grant
flow
in
SharePoint
framework,
Solutions,
I'm,
Paul
Pelosi
from
pcs.com,
and
here
you
can
find
my
reference
on
Twitter.
So
first
of
all,
I
will
start
with
some
Theory
just
to
better
understand
what
we
are
going
to
talk
about
and
to
be
sure
that
we
are
all
on
the
same
page
and
then
we
will
see
how
we
can
use
the
ampl
flow
in
a
SharePoint
framework.
B
So
the
idea
of
the
unvial
flow
is
just
to
have
yet
another
option.
You
get
another
mode
to
get
an
access
token
in
order
to
consume
a
backend
API
through
Azure
active
directory
when
we
are
using
a
middleware
and
we
want
to
consume
from
that
middleware
a
back-end
API.
So
the
idea
is,
we
have
a
front
end.
The
front
end
will
rely
on
the
middleware,
providing
an
access
token
to
access
an
API
or
a
service
in
the
middleware,
and
in
there
in
the
middleware
we
will
be
able
to
get
get
another
access.
B
I
have
a
diagram
which
will
explain
you
how
the
ambial
flow
works
from
a
functional
point
of
view.
So
imagine
that
we
have
an
application
where
we
have
an
end
user
consuming
that
application
and
we
want
to
consume
a
back-end
service
or
a
backend
API
through
a
middleware
leveraging
the
identity
platform
in
between
the
Microsoft
identity
platform
in
between.
So
the
idea
of
the
Overflow
is
that
the
application
will
provide
or
will
send
a
request
to
the
middleware,
providing
an
access
token
for
the
middleware.
B
Indeed,
in
this
diagram,
I'm
already
talking
about
a
scenario
where
the
user
already
authenticated
and
already
got
an
access
token
for
the
middleware
API,
once
we
provide
the
access
token
to
the
middleware
API,
the
middleware
API
will
provide
that
access
token,
together
with
a
client,
ID
and
a
secret.
So
with
the
client
credentials.
B
Making
that
request
and
as
such
we
can
leverage
the
delegated
model
and
we
can
get
access
to
information
like
the
mailbox,
the
personal
data
of
the
user.
We
can
send
messages
on
behalf
of
the
user
and
stuff
like
that.
That's
the
idea.
The
basic
idea
of
the
on
behalf
flow
when
we
do
that
and
generally
speaking
whenever
we
consume
an
API
using
an
Azure
active
directory.
There
is
also
the
need
for
a
grant
for
the
permission
in
order
to
have
the
application
consuming
an
API
on
behalf
of
a
user
to
be
granted
to
do
that.
B
So
how
does
it
work
when
we
have
a
middleware
in
between
and
we
use
the
on
behalf
flow
in
order
to
consume
a
backend
API,
because
indeed,
when
we
use
a
diagram
like
the
one
that
I
just
showed
you,
we
cannot
have
a
dialogue
prompting
the
user
to
Grant
permissions
for
the
middleware
to
access
the
backend.
So
how
does
it
work?
Well,
there
are
few
options
available.
B
One
is
to
Define
in
the
manifest
definition
of
the
middleware,
the
fact
that
there
will
be
a
known
client
application
for
our
middleware,
so
that,
when
the
front
end
will
make
a
request
for
Access
token,
the
very
first
time
for
an
access
token
to
consume
the
middleware.
The
end
user
will
be
prompt
not
only
to
Grant
access
to
the
middleware,
but
also
to
Grant
the
consent
to
access
the
resources
and
the
services
in
the
back
end
through
the
middleware
and
that's
one
option.
B
Another
option
is
to
use
the
pre-authorized
application
section
of
the
manifesto
which
will
simply
Define
what
are
the
applications
that
are
pre-authorized
with
a
grant
for
some
specific
applications
are
a
third
option
that
we
have
is
the
so-called
admin
consent,
meaning
that
an
administrator
of
our
tenant,
a
tenant
admin
will
grant
10
and
wide
the
permissions
to
the
middleware
to
call
a
backend
API,
which
is,
for
example,
the
scenario.
The
scenario
that
I'm
using
in
the
demo
that
I'm
going
to
show
you
right
now.
B
So
how
does
this
relate
to
SharePoint
framework,
because
what
I
said
so
far
is
just
related
to
Azure
ID
to
open
authorization
into
consuming
an
API?
Well,
what?
If
we
want
to
try
to
use
this
model
in
SharePoint
framework
and
why
it
is
worth
being
able
to
do
that?
Well,
first
of
all,
let's
start
with
a
trivial
question.
Let
me
say
in
SharePoint
framework
we
already
have
the
MS
draft
client
and
the
ad
HTTP
client
available.
So
it
should
eventually
be
enough
in
order
to
being
able
to
rely
on
a
backend
API.
B
So
let's
say
you
want
to
use
micrograph
well,
you
can
easily
do
that
in
SharePoint
framework
using
the
MS
graph
client
and
making
a
rest
request
targeting
the
Microsoft
graph.
However,
when
we
do
that
in
SharePoint
framework,
we
need
to
declare
in
the
in
the
configuration
of
our
solution
in
the
web.
B
Moreover,
whatever
we
use
and
whenever
we
consume
a
back-end
API
from
SharePoint
framework,
we
are
actually
running
a
code
which
is
running
in
the
browser,
meaning
that
if
the
user
will
close
the
browser,
whatever
we
were
doing
with
our
client
site
code,
will
stop
doing
that,
because
the
browser
will
not
exist
anymore.
As
an
instance,
so
what
if
we
need
to
do
something
which
will
need
additional
processing
time
or
if
we
need
to
run
long-running
processes
in
the
background?
B
Let's
say
that
let
me
move
to
the
actual
demo.
So,
first
of
all,
let's
see
the
user
experience.
This
is
a
very
simple
and
trivial
solution,
because
the
goal
is
to
show
you
how
to
Leverage
The
ambient
flow
model
and
not
to
create
a
really
fancy
SharePoint
framework
with
part.
But
this
web
part
will
allow
us
to
specify
the
URL
of
a
back-end
middleware
and
through
that
backend
middleware
I
will
be
able
to
make
a
couple
of
requests.
B
One
will
be
a
simple
one,
which
will
simply
give
me
back
who
I
am
as
an
end
user,
so
that
I
can
see
that
we
can
read
that
information
through
the
on
behalf
of
flow
access.
Token,
as
well
as
will
give
me
back
information
about
how
many
read
messages
I
have
in
my
inbox,
which
could
be
another
interesting
information
to
get.
B
I
can
also
use
this
solution
to
send
a
message,
for
example,
to
my
colleague
Widow.
Let
me
search
for
him
and
I
can
send
a
message.
I
agree,
though,
all
good
there
and
I
can
send
the
message
in
teams
in
teams.
I
have
a
chat
open
with
my
colleague
Guido
and
as
soon
as
I
will
press
the
button,
we
will
see
that
we
will
have
a
new
message
popping
up
in
the
one
to
one
chat.
Okay,
so,
as
I
said,
this
can
be
easily
done
also
with
Ms
graph
client.
B
B
First
of
all,
in
Azure
active
directory,
we
have
an
application
registered,
which
is,
in
my
scenario,
called
spfx,
OBO
middleware
and
in
this
application
the
key
information.
The
key
settings
you
need
to
be
fully
focused
on
are,
first
of
all,
the
application
relies
on
a
client
secret
because,
as
I
said,
in
order
to
get
a
noble,
sorry
I
keep
on
saying
elbow,
which
is
the
acronym
of
on
behalf
of
flow.
Sorry
about
that.
B
But
if
you
want
to
get
a
noble
access
token,
you
need
to
use
the
client
credentials
so
a
client
ID
and
a
client
secret,
together
with
the
access
token
that
the
middleware
has
got
from
the
consumer,
and
so
we
need
to
have
a
client
secret.
Secondly,
in
the
API
permission
section
of
the
middleware
application,
we
need
to
declare
the
permissions
that
we
need
in
order
to
consume
the
backend
API
in
my
sample.
The
backend
API
is
micrograph,
so
here
I
need
to
read
the
user.
User.Read
read:
email
mail.tradesol.
B
We
need
to
being
able
to
create
a
chart.
The
one-to-one
chat
between
me
and
the
target
user
so
I
need
the
chat.create
permission
for
teams
and
I
want
to
send
a
message,
so
chat,
dot,
read,
write
still
from
A
team's
point
of
view,
plus
I
have
the
user.read.all,
because
I
need
to
read
the
information
of
the
user
that
I
want
to
involve
in
involved
in
the
chat
that
I'm
going
to
create.
So
these
are
the
permission
that
I
need.
B
As
you
can
see,
these
are
all
delegated
permissions,
so
they
will
be
applied
in
order
to
execute
as
someone
as
a
user.
So,
on
behalf
of
a
user,
and
we
have
the
grant
the
tenant
admin
grant
for
all
of
these
permissions
and
specifically
the
one
that
really
needs
the
admin
consent
is
the
user.read.org.
B
Now
this
is
my
middleware
and
I
want
to
be
able
to
consume
this
middleware
from
SharePoint
framework
and
that's
why-
and
this
is
the
the
third
and
last
steps
in
the
configuration
of
my
application
in
the
exposing
API
of
my
middleware
application
image.
Ready
I
also
declared
that
I
have
a
unique
application.
Id
URI,
which
I
would
advise
you
to
use
as
a
string
and
not
as
a
good
like
the
auto
generated
one
so
I
usually
replace
the
auto
genetic
grid
with
a
name
which
is
better
recognizable.
Whenever
you
will
need
it.
B
My
scenario
API
and
then
spfx,
album,
middleware
and
then
I
have
a
permission
scope.
You
can
easily
create
one
one
more
by
clicking
on
other
scope
and
providing
all
of
the
information,
and
this
will
be
the
permission
that
SharePoint
framework
will
need
in
order
to
consume
my
middleware,
and
then
my
middleware
in
the
back
end
will
rely
on
these
permissions
on
behalf
of
the
user
to
consume
Microsoft
graph
in
the
back
end.
Okay,
so
that's
it
from
the
Azure,
the
application
registered
as
the
middleware.
B
B
B
So
this
one
right
now
I'm
running
the
local
version
of
my
function,
to
show
you
in
the
back
what
will
happen
after
the
cover
and
I?
Have
that
I
make
a
get
request
for
that
specific
URL
and
I
will
get
packages
and
response
through
which
I
can
see
who
am
I
the
Inbox
and
read
item
and
the
inbox
total
item
count
simple
as
that:
okay,
when
I
do
this
request
under
the
cover?
What
happens?
Let
me
do
it
again
with
F12
I
can
see
in
the
network
oops
one
more
time.
B
Sorry
I
make
a
request
for
get
personal
data.
I
Target
this
endpoint
in
my
Azure
function,
which
is
running
locally
in
my
visual
studio
code
in
the
bug
mode
and
if
I
scroll
a
little
bit
down
I,
can
see
in
the
authorization
header
that
I
have
a
better
access
token,
which
is
the
one
generated
by
the
plumbing
in
SharePoint
framework.
To
give
me
an
Access
token
to
consume
the
Target
middleware.
B
In
fact,
if
I
copy
and
paste
that
access
token
right
here,
we
can
see
that
right
now,
I
have
an
access
token
for
this
audience.
So
for
my
middleware
and
the
permission
that
I
have
the
scope
that
I
have
is
middleware.com,
which
is
the
scope
that
I
declared
in
the
expose
an
API
section
of
my
middleware
application,
okay,
hopefully
so
far
so
good.
B
Now,
what
happens
is
that
when
I
make
a
request-
and
let
me
do
that-
let
me
put
a
breakpoint
in
my
Azure
function
here:
I
have
initial
function,
built
with.net,
6,
isolated
mode,
I
have
my
Azure
function
running
in
Visual
Studio
code,
and
here
I
can
put
a
breakpoint
to
show
you
what
happens
under
the
cover.
So
let
me
make
one
more
request:
oops
right
here
and
let
me
move
to
visual
studio
code,
and
here
we
can
see
that
okay
I
see
that
I
got
my
call.
B
I
can
see
if
I
have
a
authorization
header
in
the
request
and
if
not
I
will
complain
and
say
you
are
not
authorized
if
I
have
one
I
will
get
the
better
token
that
I've
just
got
from
the
request
from
the
client
request
and
I
can
rely
on
a
utility
function
that
I
created,
which
will
give
me
access
to
the
ombi
alpha
flow
token.
So
let
me
put
a
breakpoint
right
here
and
let
me
show
you
what
happens
so.
B
So
basically
I
get
the
access
token
that
was
provided
to
me
by
SharePoint
framework
and
I
will
use
it
to
make
a
new
request
for
a
new
access
to
token,
which
will
be
on
behalf
of
the
user.
But
it
will
be
a
different
one
and
in
fact,
if
I
go
here
and
I
copy,
the
value
of
my
access,
token
and
I
show
you
again
with
jwt.ms.
Here
we
can
see
removing
the
quotes
that
we
have
a
different
access
token,
where
now
the
audience
is
micrograph.
This
is
the
unique
ID
of
micrograph
everywhere
in
the
world.
B
B
So
we
made
our
week
our
request
and
we
have
got
our
information,
the
user,
principal
name
of
the
user
and
the
number
of
unread
messages
in
the
inbox.
So
this
is
the
round
trip
that
we
make
in
order
to
rely
on
the
elbow
flow
now
to
describe
the
journey
I
mean,
for
example.
If
you
think
about
the
function
well
in
the
function,
you
have
to
retrieve
the
access
token.
You
should
validate
the
access
token.
Then
you
have
to
retrieve
the
about
token.
B
You
have
to
provide
it
back
to
maxograph,
so
quite
a
quite
a
tough
journey,
I
would
say
so
just
for
the
sake
of
making
our
life
easier
in
the
sample
that
you
can
download
from
the
sample
Gallery.
You
can
also
find
this
additional
function,
which
is
the
same
teams,
chat
message
in
this
one
I
implemented
for
you
also
based
on
another
Community
sample,
which
I
slightly
changed
and
I
wouldn't
say,
improve,
but
I
would
say
adapted
to
my
scenario.
B
Access
to
the
Overflow
token,
without
the
need
to
do
all
of
the
stuff
that
I
showed
you
before
manually,
because
you
can
just
rely
on
this
functionality
which
will
be
based
on
the
middleware
functionalities
of
the
Azure
functions
engine.
This
is
not
a
session
about
the
Azure
function,
so
I
will
not
dig
into
it,
but
you
can
just
see
that
I
can
set
this
flag
and
say:
okay
from
the
function
contest.
B
Give
me
the
principle
of
the
user
and
give
me
the
on
the
alpha
of
token
and
that's
it,
and
then
you
can
use
it
so
again
feel
free
to
download
the
sample
and
dig
into
it.
I
will
not
dig
into
the
internal
implementation
of
this
functionality,
but
I
think
this
will
be
really
useful
for
you
to
easily
and
quickly
be
on
board
of
this
new
scenario.
Now
last
thing
that
I
want
to
show
we
do
before
giving
the
stage
back
to
Gary.
B
Is
that
if
you
want
to
do
that
for
real
in
a
real
solution,
you
will
have
to
host
your
Azure
function,
for
example
in
a
real
hosting
environment
in
Azure
and
as
such.
If
you
will
do
that,
remember
that
you
have
to
configure
the
course
settings
in
order
to
have
your
SharePoint
online
tenant
in
the
list
of
allowed
Origins,
for
course,
for
your
Azure
function.
Otherwise
it
will
not
work
because,
of
course,
related
issues.
B
So
let's
say
the
I
think
it
is
quite
a
long
journey
to
see
all
of
the
steps,
but
thanks
God
we
have
the
recording,
so
you
can
go
through
it
again,
step
by
step
and
I
think
this
is
a
really
useful
scenario
whenever
you
want
to
have
a
background
task
running
on
behalf
of
the
user
and
when
the
user
will
trigger
it
from
SharePoint
framework.
That's
it
back
to
you,
Gary
and
thank
you.
A
The
token
is
visible
in
here,
and
that
means
that,
if,
for
whatever
reason,
there
would
be
a
situation
that
in
the
same
browser
window
and
session
there
would
be
malicious
code
potentially
that
code
could
actually
get
access
on
this
token
right,
yeah
right,
that's
correct.
We
need
to
be
so
that
sounds.
Oh
my
God
terrifying!
A
B
And
that's
why,
for
example,
if
the
SharePoint
framework
solution
and
I
forgot
to
tell
it
so
thank
you
Visa,
because
you
reminded
it
to
me
implicitly
by
saying
what
you
said:
I
have
to
declare
in
the
web
API
permission
request
that
I
want
to
allow
the
SharePoint
framework
solution
to
have
access
to
my
middleware.
In
order
to
have
this
permissions
called
middleware
consumer
and
a
tenant
admin
of
SharePoint
will
have
to
Grant
this
permission
in
order
to
make
it
possible
to
happen.