►
Description
Need information about the person using your Bot? Want details about the Team your Bot is running in? Want to send an email, create a Microsoft Teams channel, update Microsoft SharePoint Online content, or set up tasks in Microsoft Planner? The key to all these common tasks is Microsoft Graph API. In this session, you'll learn about the Microsoft Graph and how to call it from various kinds of Microsoft Teams application features, including tabs, bots, and task modules. You'll learn how to call the Microsoft Graph on behalf of a user, or how to elevate permissions to do something the user isn't able to do on their own. Don't miss this opportunity to unlock the power of Microsoft Graph in your Microsoft Teams applications!
Speaker: Bob German (Microsoft) | @Bob1German
Supporting materials:
• Overview of Microsoft Graph - https://docs.microsoft.com/en-us/graph/overview
• Use the Microsoft Graph API to work with Microsoft Teams - https://docs.microsoft.com/en-us/graph/api/resources/teams-api-overview?view=graph-rest-1.0
Learn more:
• Learn more about the Microsoft 365 Patterns and Practices (PnP) community at: http://aka.ms/m365pnp
• Visit the Microsoft 365 Patterns and Practices community YouTube channel: https://aka.ms/m365pnp-videos
A
A
in
and
of
itself.
The
graph
is
simple:
it's
a
bunch
of
rest
calls,
but
it's
built
on
some
complexity.
Odata
is
a
little
bit
complex.
That's
the
standard
rest
convention
for
doing,
create,
read,
update
and
delete
operations
against
collections
of
data,
and
it's
great
that
the
graph
is
consistent
with
that.
So
it
works
with
various
tools
and
is
just
familiar
across
all
the
different
workloads.
A
A
Now,
your
team's
app
is
probably
going
to
call
the
graph
most
of
the
apps.
I've
worked
on
end
up
sooner
or
later,
wanting
to
call
the
graph
to
interrogate
information
about
the
user
about
the
team
structure,
maybe
to
do
something
or
access
some
content
that
the
user
has
even
to
add
relevance
and
intelligence
by
say,
pulling
up
a
list
of
recent
documents
or
relevant
documents
to
it
to
a
user,
and
that
kind
of
thing
it's
all
in
the
graph.
But
you
need
permission
and
you
need
that
access
token.
A
So
if
I
want
to
access,
say
your
notes
in
onenote
or
your
files
in
onedrive,
I'm
going
to
use
the
graph
now,
some
of
these
services
still
have
native
apis,
and
there
are
cases
where
you
have
to
use
the
native
api,
because
something
isn't
yet
supported
in
the
graph.
But
in
most
cases
you
can
and
should
use.
The
graph
api
now
recall
that
your
teams
app
does
not
actually
run
in
teams.
A
It
actually
runs
alongside
of
teams
and
it
plugs
into
the
team's
user
interface
through
a
file
called
manifest.json.
For
instance,
a
tab
is
just
a
web
page.
You
could
host
it
anywhere.
You
want.
All
you
have
to
do
is
put
the
url
in
manifest.json,
so
that
teams
can
get
there.
Bots
and
messaging
extensions
are
just
web
services
and
the
manifest
has
the
urls
of
those
as
well.
A
So
now,
when
your
web
page
or
your
web
service
wants
some
information
about
the
teams
or
about
anything
in
microsoft,
365,
it
needs
to
call
the
graph
api.
There's
no
little
shortcut
through
the
teams
through
microsoft
teams
to
get
to
all
that
information,
you're
going
to
go
through
the
graph,
pretty
much
there's
a
little
bit
of
glue
and
we'll
look
at
a
little
bit
of
it
that
you
need
to
kind
of
connect
into
the
client
but
99
of
the
time
you're
going
to
be
calling
the
graph.
A
So,
in
order
to
explain
this
better,
let's
take
a
step
back
and
look
at
kind
of
the
old
school
permission
scheme
that
most
operating
systems
have,
in
fact,
the
computer
in
your
laptop
bag
or
on
your
desk
probably
still
supports
this
old
model.
Applications
are
just
files
in
the
file
system.
Users
can
run
any
application
they
want
and
the
applications
run.
With
that
user's
permission,
the
problem
with
this
approach
is
that
the
user
has
no
way
of
knowing
exactly
what
the
application
is
doing.
A
A
A
better
permission
model
is
found
in
some
of
the
more
modern
operating
systems
such
as
all
the
phone
operating
systems
and
mobile
operating
systems.
Azure
id
works
that
way
too
windows
store
applications,
work
that
way
applications
need
to
be
registered
with
the
system.
Just
like
users.
Applications
need
permissions
just
like
users
to
access
specific
resources,
and
then
the
users
or
their
admins
have
to
consent
to
give
those
permissions
to
the
application.
I
have
a
screenshot
here
at
in
the
bottom
right.
A
Whenever
I
go
to
play
civilization
revolution
2
on
my
android
device,
it
wants
to
read
my
contacts,
I
always
say
no,
I
don't
know
what
it
would
do
if
I
said
yes,
but
it
really
has
no
business
reading.
My
contacts,
since
all
I
want
to
do
is
play
this
game,
so
the
operating
system
is
saving
me
here
from
who
knows
what
that
application
wanted
to
do
with
my
contacts,
and
actually
it
works
fine,
even
if
you
say
no,
so
sometimes
you
really
want
to
read.
A
So
how
does
that
really
manifest
here?
Well,
in
order
to
call
the
graph
you
have
to
register
your
application
in
azure
id
that's
different
from
the
application
in
your
manifest
dot.
Json
that
you
give
to
teams,
you
need
to
register
an
application
in
azure
id
and
it
could
be
in
either
your
tenant
or
your
customers
tenant.
In
other
words,
you
could
put
it
directly
where
the
users
are,
or
you
could
put
it
in
some
other
tenant.
A
Maybe
your
product
company
and
you
put
it
in
your
tenant
and
then
hundreds
or
thousands
of
customers
refer
to
it
from
their
tenant
and
use
it
in
their
tenant.
That's
either
way
that
works,
then
you
need
to
specify
the
permissions
that
your
app
needs
to
call
specific
resources
such
as
the
microsoft
graph.
So
maybe
you
need
group.read.all
in
the
microsoft
graph,
which
would
allow
you
to
read
everything
in
the
microsoft
365
groups
in
that
tenant
and
I'll
get
into
that
a
little
bit
more
in
the
next
slide.
There
are
two
ways
to
do
this.
A
Some
azure
ad
applications
can
also
do
something
called
dynamic
consent,
meaning
that
they
can
actually
ask
for
more
permission
after
the
application
is
running,
and
this
is
actually
a
very
nice
model
and
it's
available
with
the
newer
version
2
endpoint
in
azure
id
and
certain
certain
oauth
flows.
So
it's
not
always
there,
but
it
is.
It
is
good
to
have
it
when
you
need
it
and
I'll
point
out
as
we
go
through
the
different
options
here,
where
it's
available
and
where
it's
not
your
app
then
can
request
an
access
token
from
azure
id.
A
A
If
successful,
azure
ad
returns
an
access
token
to
your
app,
which
is
good
for
about
an
hour,
your
app
then
passes
that
access
to
access
token
to
graph
in
the
http
headers
to
do
whatever
it
is
that
it
needs
to
do
so
really.
Now
we
have
two
kinds
of
permission:
we
have
the
applications,
permissions
and
the
users
permissions.
A
A
A
So
app
permissions
are
useful
for
background
processing
and
daemon
applications
and
also
to
elevate
permissions,
but
it's
a
lot
of
responsibility
to
have
and
they
should
be
used
sparingly
there.
Now
these
are
the
different
authorization
flows.
The
different
protocols
available
and
I'm
not
going
to
talk
too
much
about
them,
but
I'll,
be
referring
to
them
during
the
during
the
scenarios
that
follow
some
of
them
only
work
from
a
web
browser.
Others
work
from
a
native
application
notice
that
client
credentials
flow
is
the
only
one
that
gives
you
an
app
permission.
A
Everything
else
is
delegated
user
permissions
and
there's
no
way
to
do
an
elevation
inside
of
a
client
device
or
a
web
browser.
You
really
have
to
do
that
from
a
service
somewhere.
So
we're
mainly
going
to
be
talking
about
the
user
permissions
in
this.
In
this
talk,
so
let's
just
quickly
have
a
look
inside
of
azure
active
directory,
I'm
going
to
be
going
through
a
number
of
different
scenarios,
but
all
of
the
scenarios
have
app
registrations
here
under
app
registrations
in
the
azure
id
portal.
A
A
This
is
where
you
define
the
rules
for
authentication
which
are
different
for
each
of
the
scenarios
and
also
the
api
permissions.
So
here
I'm
getting
the
graph
permission
user
delegated.
You
can
see
that
clearly,
I'm
getting
permission
to
read
the
user's
email
and
to
read
information
about
the
user.
So,
basically,
all
my
scenarios,
I'm
just
going
to
read
the
users
first
few
emails
as
my
demo,
so
they're
all
kind
of
set
up
like
this
and
then
enterprise
applications
is
where
the
customers
would
manage
their
end
of
the
deal
so
here's
enterprise
applications.
A
These
are
also
called
service
principles
which
can
be
just
a
little
bit
confusing,
but
these
are
all
the
service
principles.
What
happens
is
when
a
user
or
an
admin
consents
to
give
the
application
permission
that
gets
stored
here
in
the
tenant,
where
the
customer
is
so.
Let's
say
I
want
to
see
what
users
have
actually
granted
consents.
I
can
come
in
here
and
get
it
all
that
information.
I
can
also
delete
this
thing
if
I
want
to
kind
of
reset
and
delete
all
those
consents,
so
everybody
will
just
be
asked
to
consent
again.
A
If
I
delete
this,
that's
really
useful
during
testing
all
right.
So
let's
dig
into
some
real
scenarios
here,
I'm
going
to
show
you
three
ways
to
get
a
graph
access
token
from
a
teams,
tab
and
recall
that
your
teams,
tab,
is
just
a
website
hosted
anywhere
on
the
internet,
and
teams
is
going
to
stitch
that
in
to
the
ui
using
an
iframe.
A
So
the
first
option,
and
probably
the
best
option
in
many
cases-
is
going
to
be
to
use
azure
id
sso.
So
this
is
a
new
single
sign-on
feature
in
teams
that
was
just
generally
available
at
build
2020,
so
pretty
new,
as
I'm
recording
this
anyway.
This
gives
the
best
user
experience,
no,
no
prompting
no
pop-ups.
It
works
in
multi-tenant
apps.
So
if
you're
an
isv
and
you
want
to
register
the
app
in
your
tenant
and
then
have
customers
consent
to
your
app
in
their
tenant,
that's
possible
here.
A
Well,
you
can't
do
that
here
and
also
azurewebsites.net
hosted.
Apps
are
not
currently
allowed.
I
think
that
may
change,
however,
so
this
is
a
great
method,
probably
the
best
user
experience.
Also,
probably
the
most
complex
one
to
implement
the
tooling
is
getting
better
and
will
make
it
a
little
bit
easier.
So
I'll
show
you
that
first
and
then
sharepoint
framework
is
a
great
option.
It
has
that
same
great
user
experience
of
the
user
not
getting
prompted
and
actually
that's
because
it
runs
on
top
of
the
azure
id
sso
feature.
A
A
The
admin
has
to
consent.
So
that's
a
potentially
a
downside,
even
if
you
need
very
small
amount
of
permission,
the
user
can't
do
it
on
their
own,
and
this
is
a
caveat
that
I
think
is
going
to
change,
but
right
now
I
think
it
could
be.
Certainly
something
to
note
is
that
the
permissions
you
give
your
app
are
shared
by
all
third-party
web
parts
in
the
tenant.
I
don't
you
know,
there's
there's
a
thing
called
isolated
web
parts
that
solves
this
problem,
but
isolated
web
parts
do
not
currently
work
with
teams
tabs.
A
So
the
idea
of
a
shared
access
token
is
really
not
it's
really
kind
of
lost
here,
but
for
whatever
reason,
right
now,
if
you
had
a
an
app
that
needed
say
files.read.all
the
admin
in
the
process
of
granting
that
to
your
app
is
going
to
be
giving
every
third-party
web
part
in
the
tenant.
Files.Read.All
access.
The
third-
and
this
is
the
original
option
that's
been
around
since
the
very
beginning
of
teams-
is
to
write
a
pop-up
login
page.
So
why
a
pop-up?
A
Well,
you
know
most
browser
based
authorization
schemes
do
not
work
in
an
iframe
for
security
reasons.
So
all
this
is
is
a
very
simple
little
mechanism
inside
of
teams
that
launches
a
pop-up
and
then
allows
the
pop-up
to
send
a
message
back
to
your
application,
and
you
can
put
anything
in
there.
You
want
an
azure
id.
Login
is
obviously
what
I
will
show,
but
this
works
with
non-azure
id.
As
long
as
you
can
log
users
in
via
a
web
browser,
you
can
put
whatever
code
into
that
pop-up.
A
You
need
to
log
the
user
in
against
any
kind
of
auth
scheme.
This,
of
course,
could
also
work
with
multi-tenant
apps,
and
this
works
beautifully
in
a
completely
static
website
with
no
web
service,
which
is
what
I
will
show.
The
user
does,
however,
see
more
more
pop-ups,
so
that's
kind
of
the
downside,
all
right.
So,
let's
start
with
azure
id
sso
for
tabs.
A
When
you
look
at
this,
it
might
seem
like
the
simplest
thing
you
can
imagine,
because
all
you
have
to
do
is
call
this
a
get,
auth
token
function
and
you
get
an
auth
token.
That's
the
good
news,
the
other
news.
The,
however,
is
that
that
auth
token
is
extremely
limited.
In
its
permission,
if
you
wanted
to
do
even
a
very
basic
thing,
like
read
the
user's
own
profile,
you
need
to
implement
a
web
service
that
exchanges
that
very
weak
token.
A
For
a
stronger
token,
and
also
in
order
to
support
user
consent,
your
ui
has
to
be
prepared
to
prompt
the
user.
So
maybe
it's
the
first
time
the
user
came
and
used
your
app
and
you're
requesting
a
permission
that
they
have
not
previously
granted
to
your
app
and
the
admin
hasn't
granted
to
your
app.
So
you
actually
have
to
include
extra
code
for
that
one
case
that
will
pop
up
a
consent
window
from
azure
id.
So
that's
why
this
is.
Although
it's
the
smoothest
for
the
user
experience,
it's
actually
the
most
complex.
A
I
think
right
now
from
a
developer
experience.
So
now
I'll
show
you
the
user
experience
and
it'll
go
fast.
Okay,
that's
it!
So
it
just
got
the
token
from
get
off
token
exchange
that
in
my
own
web
service,
for
a
more
privileged
token
that
has
mail.read,
and
then
I
called
the
graph
api
with
the
mail.read
token
and
read
the
mail.
A
The
nice
thing
is,
if
I
leave
the
tab
and
go
back
it's
just
as
fast
every
time,
and
if
I
pop
over
to
a
mobile
client,
you'll,
see
that
the
experience
works
just
as
seamlessly
there
and-
and
I
think
this
is
especially
important
in
mobile,
where
users
really
don't
want
to
be
prompted
in
trying
to
type
their
password
and
stuff
on
their
phone
all
right.
So
a
quick
flyover
of
the
code
first
going
to
get
the
auth
token
from
teams
using
this
get
off
token
call
couldn't
be
simpler.
A
Then
I'm
going
to
exchange
that
so
I'm
going
to
take
that
client
side
token
and
send
it
to
my
own
endpoint,
slash
off
slash
token
and
I'm
going
to
get
back
a
server
side.
Token
and
I'll
show
you
that
code
in
just
a
sec,
then
I'm
going
to
use
that
server
side
token
to
call
the
graph
in
order
to
do
that,
exchange.
A
But
there
is
the
possibility
that
I
could
get
an
invalid
grant
or
an
interaction
required
error
here,
and
I
should
really
be
checking
for
just
those
errors
and
this
will
trigger
the
pop-up
to
request
consent
and
then
try
the
whole
thing
again
after
the
user
has
had
a
chance
to
consent
to
the
elevated
permissions.
The
first
time
next
up
is
sharepoint
framework,
and
this
is
really
a
nice
scenario
because
you're
actually
writing
a
sharepoint
framework
web
part,
which
could
also
be
something
you
had
already,
maybe
built
for
sharepoint.
A
So
the
key
here
is
to
include
in
your
sharepoint
app
manifest
the
permissions
that
you
need
and
then
an
admin
has
to
go
and
grant
those
permissions.
I
have
a
screenshot
over
here.
They
it's
actually
in
the
sharepoint
admin
and
rather
than
azure
id
that
that
happens,
and
then
the
beauty
of
it
is
that
sharepoint
framework
just
handles
all
the
security
for
you.
All
you
have
to
do
is
use
the
ms
graph
client
factory,
and
it
gives
you
a
client,
that's
already
loaded
with
all
of
the
authorization
code
that
you
need.
A
So
you
just
make
your
call
it's
it's
really
a
beautiful
thing.
You
can
also
call
your
own
azure
id
protected
services
or
anything
other
than
graph
using
the
aad,
http,
client
object
and
sharepoint
framework
will
fill
in
the
security
part
for
that
too.
So,
let's,
let's
see
how
that
works
again.
This
is
a
really
quick
demo
that
that
was
it
right
it,
the
the
tab,
just
comes
right
up
and
if
I
click
on
it
again,
it
comes
right
up
again
and
the
mobile
client.
I
think
they
just
recently
added
support
for
this.
A
Mobile
client
works
great
too.
So
this
is
a
great
option
as
long
as
you're
happy
to
use
the
sharepoint
framework
toolchain
and
to
host
in
sharepoint.
So
the
third
option
that
I'll
show
is
to
use
a
pop-up
window,
and
this
is
extremely
flexible
because
you
really
could
put
anything
you
want
inside
of
the
pop-up.
So
if
you
look
at
the
diagram
you
can
see
the
white
box
on
the
left
is
where
your
single
page
app
is
running
in
an
iframe.
You
have
some
javascript
there.
You
call
the
team's
client
sdk
it
launches
a
pop-up
window.
A
You
can
put
any
code,
you
want
in
there
to
get
any
information
you
want
or
do
whatever
you
kind
of
want
and
pass
back.
Usually
it's
the
access.
Token,
in
my
case,
I'll
also
pass
back
the
expiration
date
and
the
username
to
the
hosting
application,
and
this
just
uses
the
inter
frame
messaging,
which
has
to
be
supported
by
the
hosting
application
of
microsoft
teams.
So
you
just
make
this
call
to
authentication.authenticate,
which
ironically,
doesn't
actually
authenticate
anyone.
A
A
I
didn't
actually
have
to
log
into
the
pop-up,
because
azure
ad
had
already
left
a
cookie
in
under
its
own
url
in
the
browser
and
was
able
to
to
just
sort
of
say:
oh
he's
already
logged
in
right,
but
it
could
have
logged
me
in
it
could
have
done
multi-factor
authentication.
It
could
have
done
some
user
consents
it.
It
basically
azure
id
could
kind
of
work
with
me
for
a
while
to
get
everything
it
needed.
In
this
case
there
was
nothing
and
it
was
very
quick.
A
The
thing
is,
if
I
leave
the
the
tab
and
go
back
to
it,
I'm
starting
over
again
right,
I
have
to
go
through
and
I'm
gonna
see
that
pop
up
again.
Why
is
that?
Well,
it's
because
really,
this
is
a
new
browser
view
right
like
when
I
left
the
tab.
Teams
doesn't
keep
all
your
tabs
kind
of
alive
in
suspended
animation.
Somehow
it
doesn't
just
hide
them
the
way
a
web
browser
would
the
tab.
It's
an
iframe,
it's
gone
when
you
leave
the
tab
in
the
teams
ui.
A
So
if
I
go
into
the
mobile
client,
you'll
see
that
it
works
there
too,
and
I
am
going
to
see
that
off
experience
real,
quick,
okay
and
then
it's
actually
going
to
work.
So
to
do
this,
I
actually
had
to
write
a
separate
web
page
that
didn't
use
the
teams
sdk
that
just
used
the
msl
msal
client
that
I'm
using
to
get
my
access
token
directly.
On
the
page,
I'm
told
that
this
will
be.
A
So
this
is
the
main
react
component
and
when,
whenever
this
runs,
it's
actually
going
to
call
my
init
function
and
it
exists
because
at
certain
points
in
the
sequence,
azure
ad
is
going
to
interact
with
the
user
in
either
the
team's
pop-up,
which
is
my
web
page
or
in
my
mobile
web
page,
it's
going
to
interact
with
the
user
and
then
send
an
auth
code
back
which
I
can
exchange
for
an
access
token.
Now
this
auth
code
is
actually
new.
A
This
came
out,
msal
2.0,
with
auth
code,
pkce
flow
for
browsers,
just
came
out
at
build
and
is
a
more
secure
method
than
the
implicit
flow
that
we
had
previously
used.
So
that's
what
I'm
doing
here
and
but
I
do
have
to
check
every
time
a
page
comes
in
hey.
Is
this
the
the
thing
that
has
that
auth
code
in
it?
A
So
after
that's
done,
I
can
check
and
see
I'll
set
a
state
variable
so
that
I
can
see
that
I've
done
that
at
least
once
and
now
I'm
going
to
route
my
request
out
to
the
various
virtual
pages
in
this
little
single
page,
app
notice.
I
have
one
for
tabs
one
for
the
web,
the
standalone
web,
and
I
have
this
teams
auth
pop-up
that
is
going
to
handle
the
pop-up
page.
A
The
username
access
token
and
the
expiration
on
that
and
maintain
that
in
a
singleton,
where
I
can
sort
of
only
go
back
and
do
this
when
the
expires
on
has
been
has
been
passed
right
when
that
time
has
been
passed
now,
then
I'm
not
going
to
walk
through
all
the
code
in
the
in
the
pop-up
or
in
the
stand-alone
browser
you
can
download
all
of
it,
but
I
will
show
you
that
basically
they're
just
calling
login,
which
does
a
login
redirect
so
this
takes.
This
is
the
other
end.
A
I'm
going
to
close
with
a
bot
scenario:
the
user
delegated
choice
is
to
use
the
auth
dialog.
So
this
is
a
dialog
inside
the
bot
framework
that
can
pop
up
and
authenticate
the
user
not
going
to
have
a
lot
of
time
to
to
get
into
the
details,
because
bots
are
a
big
topic,
but
let
me
just
show
you
what
it
looks
like
to
the
user.
A
So
if
I
go
in
and
talk
to
the
bot,
it's
going
to
give
me
a
sign
in
button.
So
this
is
the
auth
dialog
in
the
bot
and
again
I
get
sent
to
a
web
browser.
It
really
works
better
if
it's
in
a
web
browser
because
then
azure
id
can
interact
directly
with
the
user
through
the
browser
and
then
all
I
have
to
do
is
click
the
button
to
get
my
mail.
A
So
here's
my
troubleshooting
checklist
really
quickly,
always
test
and
post
man
check
all
your
ids
and
secrets
check
the
admin
consents
just
I'll.
Let
you
read
this
on
your
own,
and
but
sometimes
it
can
be
a
little
frustrating
because
you
get
just
like
a
401
access
denied.
It
can
be
a
little
tricky
to
figure
out
what
happened.
So
I
recommend
these
steps.
A
Here
is
the
resources,
and
you
can
see
here
there's
a
companion
blog
article
that
should
cover
most
everything,
that's
in
the
talk
and
maybe
go
a
little
bit
deeper
and
then
all
of
the
demos
that
I've
showed,
including
an
additional
one,
which
is
the
graph
toolkit
option
which
basically
wraps
around
scenario
number
three
right
now
but
for
the
tabs,
but
it
could
change
in
the
future
because
everything
is
packaged
up
into
these
beautiful
little
web
components.
My
teammate
aicha
bosh
has
actually
written
a
great
article
and
walk
through
on
that
and
demo.
A
So
I'll
point
you
to
that,
and
I'm
also
putting
in
a
plug
for
teams
samples
so
as
part
of
the
pnp
community,
I'm
actually
gathering
and
curating
teams
application
samples.
So
I
would
love
your
pull
request.
Please
check
out
the
sample
browser
and
see
what's
there
across
both
the
community
and
microsoft
and
then
do
a
pull
request
and
let
us
have
your
samples
as
well
there's
also
some
great
videos
up
there
on
the
pnp
channel.
So
thank
you
so
much
for
joining.