►
From YouTube: Registering and securing custom Azure AD secured APIs for Viva Connection ACEs (series 4/4)
Description
In this video, you can see how to register Azure AD secured multi-tenant APIs that you can consume from Adaptive Card Extensions (ACEs) for Microsoft Viva Connections. Specifically, you can learn how to expose an API from an Azure AD registered app, how to host the API on Azure as a Function App, and how to configure SharePoint Framework (SPFx) to consume it.
Here you can find the source code of an end to end reference solution used in the videos: https://github.com/pnp/spfx-reference-scenarios/tree/main/samples/ace-pnp-contoso-orders
Video Presenter: Paolo Pialorsi (PiaSys) | @paolopia
Here you can find additional information about the topic covered:
- Playlist on the four video series -
- PnP Contoso Orders - Reference Solution - https://github.com/pnp/spfx-reference-scenarios/blob/main/samples/ace-pnp-contoso-orders/docs/Introduction.md
- Scenario ACEs Implementation Details - https://github.com/pnp/spfx-reference-scenarios/blob/main/samples/ace-pnp-contoso-orders/docs/ACEs-Implementation-Details.md
- Scenario APIs Implementation Details - https://github.com/pnp/spfx-reference-scenarios/blob/main/samples/ace-pnp-contoso-orders/docs/APIs-Implementation-Details.md
- Overview of Viva Connections Extensibility - https://docs.microsoft.com/en-us/sharepoint/dev/spfx/viva/overview-viva-connections
- Build your first Viva Connections Adaptive Card Extension - https://docs.microsoft.com/en-us/sharepoint/dev/spfx/viva/get-started/build-first-sharepoint-adaptive-card-extension
Additional resources:
• 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
Welcome
to
this
session
about
registering
and
securing
a
custom
already
secured
apis
for
viva
connections,
adaptive
card
extensions-
I
am
paulo
pelorsi
and
I'm
a
proud
member
of
the
microsoft
65
pmp
team.
This
is
the
fourth
and
final
episode
of
a
series
of
videos
about
how
to
create
adaptive
card
extensions,
consuming
a
backend
multi-tenant
api,
and
in
this
video
we
will
focus
on
how
to
register
in
azure
active
directory
in
app
which
will
be
used
for
the
backend
api
consumed
by
adaptive.
A
Current
extensions
registering
an
app
means
that
we
will
have,
for
example,
to
configure
a
proper
return
url
for
the
constant
flow
of
the
application.
We
will
need
to
configure
proper
permission
scopes
for
consumers
of
our
api
and
optionally.
We
will
have
to
configure
api
permissions
that
we
want
to
have
granted
to
our
application
in
order
to
consume
a
backend
workload
like,
for
example,
micrograph
from
a
sharepoint
online
point
of
view.
A
So
in
order
to
register
the
application
in
azure
active
directory,
you
need
to
open
a
browser
and
go
to
portal.azure.com
targeting
a
tenant
which
will
be
the
main
tenant
of
your
multi-tenant
application
registration.
You
go
to
azure
active
directory
and
you
click
on
app
registrations.
From
there.
You
can
choose
to
create
a
new
registration.
You
will
have
to
provide
a
name
which
will
be
also
used
in
sharepoint
framework
in
the
package
solution.json
file
to
specify
the
name
of
the
resource.
A
You
want
to
get
the
api
permission
request
for,
and
you
will
have
to
choose
the
multi-tenant
option
right
here
and
eventually
provide
a
direct
uri
to
redirect
users
after
the
content
will
be
applied
now
in
our
tenant.
I
already
did
it
for
the
application
we're
going
to
use.
So
let
me
click
on
this
one
and
let
me
search
for
the
pmp
contoso
orders,
application-
and
here
it
is
this-
is
the
application,
the
multi-tenant
application
that
I
created
for
this
sample
solution.
A
What
is
important
to
notice
is
the
name.
As
I
said,
this
one
will
be
used
also
in
spfx
configuration
the
application
or
client
id,
which
is
the
unique
id
of
your
application
and
the
object
id,
which
is
the
internal
id
of
the
object
and
specifically
the
tenant
id,
which
is
the
unique
id
of
the
tenant
in
which
you
register
the
multi-tenant
application,
so
display
name,
client,
id
and
tenant
id.
A
Then,
in
order
to
expose
an
api,
you
need
to
click
on
the
exposing
api
item
right
here
and
you
have
to
specify
the
unique
application
id
for
your
application
by
default.
Azure
active
directory
will
use
api
followed
by
the
client
id.
I
would
advise
you
to
replace
it
with
a
meaningful
name
like,
for
example,
the
name
of
the
api
that
you
are
going
to
expose.
This
will
be
the
unique
id,
for
example,
that
you
will
use
again
in
sharepoint
framework
to
create
a
new
instance
of
the
ad
http
client
object.
A
Then
you
can
specify,
as
many
permission
scopes
as
you
like,
and
whenever
you
add
a
permission
scope,
you
have
to
specify
a
scope
name
which
is,
for
example,
in
my
scenario,
orders.read
or
order
dot
full
control.
Then
you
have
to
make
a
choice
if
you
want
this
permission,
scope
to
be
grantable
by
admins
only
or
if
you
want
to
make
it
possible
for
common
users
to
consent
it
as
well,
and
not
only
for
admins
and
depending
on
what
you
will
choose
here.
A
You
will
have
to
specify
the
admin
display,
name
and
description,
and
eventually
the
user
display
name
and
description,
and
you
have
to
enable
it
once
you
have
configured
all
of
your
permission
scopes.
You
can
then
rely
on
them
like
we
did,
and
you
can
see
it
in
the
previous
episode
number
three.
We
can
rely
on
them
in
the
azure
function,
implementation
to
authorize
user
requests
based
on
the
permission
scopes
provided
in
the
access
token.
A
So
from
an
api
registration
prospecting,
that's
it
plus
in
the
authentication
section
you
have
to
specify
the
redirect
url
of
the
application
which
will
be
used
when
the
user
will
consent
to
your
api
in
their
own
tenant,
and
they
will
be
redirected
to
any
of
these
url
based
on
what
you
will
configure
as
the
content
url.
In
our
scenario,
in
the
sample
application,
we
are
talking
about.
The
constant
url
will
be
the
login.microsoft
online.com
under
https,
followed
by
the
tenant
id
or
common
for
multi-tenant
applications.
A
That's
what
I'm
using
right
now
and
admin
constant,
because
my
application
is
configured
to
require
admin
content
only
followed
by
in
the
query
string
the
client
id
that
we
want
to
consent
and
the
redirect
uri
to
use
after
the
constant
will
be
applied
and
optional.
You
can
specify
a
custom
state
property
in
which
you
can
provide
strings
with
whatever
value
you
like
and
in
my
scenario
again,
I
decided
to
accept
as
the
state
a
variable
custom
variable,
the
name
of
the
tenant,
where
I'm
registering
I'm
consenting
the
application.
A
This
is
an
important
step,
because
if
you
don't
content,
if
you
don't
register
the
multi-tenant
application
in
your
target
tenant,
you
will
not
be
able
to
grant
the
permissions
to
use
this
api
when
you
will
add
the
sharepoint
framework
package
to
the
app
catalog,
as
we
will
see
pretty
soon
in
this
video.
So
here
I
have
configured
my
application.
My
multitenant
application
is
ready
and
I
have
the
constant
url
that
I
can
use
to
grant
and
to
register
the
application
in
the
target
attainment.
A
Now
we
need
to
host
the
application
on
a
hosting
environment,
and
here
we
have
the
azure
function,
I'm
using
for
this
application,
and
here
again
we
have
the
functions
available
in
the
api.
But
what
is
worth
noting
right
now
is
the
configuration
section
where
we
can
see
that
we
defined
in
the
configuration
of
the
azure
function
all
of
these
settings
that
we
saw
also
in
episode
3
when
defining
the
settings
of
our
azure
function.
So
we
have
the
audience,
which
is
the
unique
uri
that
we
just
defined
registered
in
the
application.
A
We
have
the
client
id
and
the
tenant
id,
and
we
have
the
instance,
which
is
the
url
of
the
azure
active
directory
tenant,
which
will
be
used
to
provide
and
to
issue
the
tokens.
So
these
are
the
settings
we
need
in
the
function
app
to
properly
support
the
authentication
and
authorization
based
on
the
access
token,
once
we
have
done
that,
we
can
publish
the
application
and
we
can
constant
the
application
to
a
target
tenant.
A
A
I
will
have
to
make
my
solution
10
and
wide
available,
which
is
a
an
option
that
I
can
choose
when
I
upload
the
package
in
the
app
catalog
and
once
I've
done
that
I
will
have
to
grant
the
permissions
to
my
app
in
order
to
access
the
backend
api
and,
as
I
said,
in
order
to
be
able
to
do
that.
First
of
all,
I
need
to
consent
that
application
in
my
target
tenant.
A
So
let
me
open
a
tab
and
let
me
copy
the
url
of
the
admin
consent,
so
we
can
use
it
to
start
the
admin
consent
flow,
and
here
we
are-
and
this
is
the
url
I'm
going
to
use
perfect.
So
let's
go
there,
we
will
use
the
currently
connected
user.
We
will
consent
the
application,
so
we
accept
to
register
the
multi-tenant
application
in
our
target
tenant
and
once
we
have
done
that,
we
will
be
redirected
to
a
page,
which
is
something
which
we
implemented
in
the
custom
function.
A
You
can
provide
the
redirect
url
that
you
like
and
in
our
solution.
We
decided
to
use
a
smart
url
this
one,
this
one,
which
is
an
api
running
under
the
function,
app
which
will
do
the
magic
to
make
a
redirect
to
the
api
access
page
of
sharepoint
online,
and
here
we
have
the
capability
to
grant,
to
approve
the
permission
request
and
to
make
it
possible
to
consume
the
target
api.
A
If
you
will
not
consent
the
application
and
register
the
application,
the
multi-tenant
application
in
target
tenant,
you
will
not
be
able
to
grant
the
permissions
and
you
will
get
an
exception
when
you
will
try
to
grant
those
permissions
from
this
ui.
That's
why
we
created
a
flow
based
on
the
powershell
script
available
in
the
source
folder
of
our
solution,
and
that's
why
I'm
highlighting
you
these
steps
and
the
fact
that
we
created
this.