►
Description
#Microsoft365 #MicrosoftTeams #SSO
In this video, Microsoft Cloud Advocate Bob German will help you understand the sometimes complex topic of single sign-on. It’s intended as a starting point for developers who want to build Microsoft Teams apps and who need to understand SSO with Azure Active Directory, which is the authentication system used by Teams.
This video will walk you through the concepts you need to build and troubleshoot applications. The following topics are covered:
🪐 What is SSO and why is it important?
🪐 Understand Microsoft 365 Tenants and Azure AD
🪐 Azure AD App registration, resources, and scopes
🪐 Four common confusions: Azure AD and similarly named products, Microsoft 365 and Azure tenants vs. subscriptions, different terms that mean the same thing, and the different kinds of permissions
🪐 OAuth 2.0 protocols with Azure AD
🪐 Building a Single Page Application with Azure AD, similar to how a monetized Teams store app’s landing page handles authentication
🪐 Teams tab with pop-up authentication
🪐 Teams tab with Teams SSO (the preferred method)
🪐 Teams tab with SharePoint Framework
🪐 Teams bot with Azure AD Auth
🪐 Troubleshooting tips
00:00 What is SSO and why is it important?
02:58 Microsoft 365 Tenants and Azure AD
06:20 Azure AD App registration, resources, and scopes
13:35 Four common confusions: Azure AD and similarly named products, Microsoft 365 and Azure tenants vs. subscriptions, different terms that mean the same thing, and the different kinds of permissions
21:38 OAuth 2.0 protocols with Azure AD
26:40 Single Page Applications with Azure AD, similar to how a monetized Teams store app’s landing page handles authentication
34:21 Teams tab with pop-up authentication
41:18 Teams tab with Teams SSO (the preferred method)
45:18 Teams tab with SharePoint Framework
49:20 Teams bot with Azure AD Auth
53:28 Troubleshooting tips
A
Hi
everyone,
this
video
is
understanding
single
sign-on
for
microsoft
teams
developers.
My
name
is
bob
german
and
I'm
a
cloud
developer
advocate
at
microsoft
and
something
I've
heard.
A
lot
from
my
teammates
and
our
partners
alike.
Is
that
there's
a
common
challenge
in
trying
to
figure
out
single
sign-on
when
developing
a
microsoft
teams
application?
A
A
Even
inside
of
microsoft,
the
microsoft
azure
documentation
takes
a
fairly
broad
view
of
sso,
including
federation
technologies
like
saml.
That's
not
true
for
microsoft
teams,
who
has
very
specific
definition
for
sso.
That
makes
the
login
experience
completely
silent
and
is
definitely
azure
active
directory,
specific
our
commercial
marketplace
where
you
would
build
a
transactable
offer
that
could
be
sold
in
the
microsoft
team
store.
A
They
have
yet
another
definition
of
sso,
which
is
a
little
simpler
than
the
teams
one,
but
still
requires
logging
in
directly
to
azure
active
directory
and
acquiring
an
access
token,
allowing
the
application
to
call
the
microsoft
graph
api.
This
video
will
explain
all
of
that,
and
it
will
also
explain
the
concepts
that
underlie
any
sso
implementation
inside
of
microsoft
365..
A
I
want
to
start
at
the
beginning,
because
I
know
a
lot
of
people
who
are
looking
to
build
microsoft.
Teams
applications
have
experience
on
other
platforms
and
may
be
new
to
microsoft.
365.,
microsoft
365
is
a
suite
of
cloud-based
applications,
some
of
which
have
an
optional
rich
client
or
mobile
application,
but
they
all
have
a
cloud
presence
and
are
capable
of
running
in
a
web
browser
from
the
cloud
directly.
A
What
you're
really
going
to
get
is
one
instance
of
azure
active
directory
and
access
to
some
or
all
of
these
applications,
depending
on
the
plan
that
you
have
and
the
content
that
users
create
using
those
applications,
they
all
go
into
a
tenant
which
is
a
security
boundary
and
an
administrative
boundary
around
all
of
that
content
and
all
of
your
directory
information.
In
fact,
the
users
themselves
are
registered
in
that
same
directory,
along
with
their
login
information,
etc.
A
A
If
you
write
an
application,
it
also
needs
to
be
registered
inside
of
azure
active
directory
so
that
it
can
be
authorized
to
access
the
content
on
behalf
of
those
users
or
on
its
own
behalf.
This
is
core
to
understanding
how
microsoft
365
works.
Azure
active
directory
itself
is
well,
it's
an
identity
service.
A
It
can
authorize
users
who
are
accessing
apps
via
web
browsers
native
applications
or
daemon
or
service
applications,
which
may
not
involve
a
specific
user,
and
it
can
authorize
access
to
apps
that
are
running
in
azure
in
microsoft,
365
of
course,
or
your
apps,
even
if
they're
not
running
in
azure.
Actually,
if
they're
registered
in
azure
id
azure
id
can
authorize
users
and
apps
to
come
in
and
access
those
services.
A
One
thing
that's
important
about
azure
ad
to
our
enterprise
customers.
It
synchronizes
with
the
on-premises
active
directory
service,
so
users
in
a
hybrid
environment
can
get
seamless
access
to
their
on-premises
and
cloud-based
assets
using
azure,
active
directory
and
active
directory
directory
services.
On-Prem
azure
id
provides
a
consent
model.
It
provides
for
something
called
conditional
access,
so
maybe
users
are
only
authorized
during
certain
hours
of
the
day
or
if
they
are
in
a
certain
location,
it
has
provisions
for
self-service,
password
management,
group
management,
etc.
A
Three
core
concepts
in
azure
ad,
our
first
app
registration
applications
that
want
to
authorize
users,
whether
the
client
or
the
service
side
of
that
application
they
need
to
be
registered
in
azure
ad.
We
have
resources,
which
is
the
services
that
those
apps
are
using,
some
of
which
may
be
microsoft.
Services
like
the
microsoft
graph,
which
is
the
main
api
for
microsoft,
365
or
your
own
services,
and
it
also
deals
with
permissions
which
are
called
scopes.
A
So,
for
instance,
directory.read
scope
gives
the
app
permission
to
read
the
information
inside
of
azure
80's
directory.
Why
bother
with
all
this?
Well,
some
viewers
may
be
used
to
an
old
school
operating
system
where
applications
are
just
files
in
the
file
system
and
users
can
run
any
application
they
want,
and
once
it's
running
the
application
has
all
the
permissions
of
the
user
who
runs
it.
A
This
is
the
traditional
method
that
is
used
still
in
a
lot
of
desktop
operating
systems.
The
issue
is
that
users
have
no
way
of
knowing
completely
what
the
application
is
doing.
So,
as
this
user
is
playing
a
game,
the
game
may
actually
be
reading
her
contacts
list
and
sending
spam
emails
to
all
of
them.
A
A
modern
operating
system
such
as
any
of
the
mobile
operating
systems
such
as
windows,
store
applications
and
yes,
microsoft,
teams,
applications
and
azure
id
applications
takes
a
different
strategy.
Applications
need
to
be
registered
and
the
apps
need
permissions,
just
as
the
users
would
need
permissions,
then
users
and
or
admins
have
to
consent
to
those
permissions.
So
we're
gonna
ask
that
gamer.
If
it's
okay,
to
read
her
contacts,
she's
gonna
say
that
silly
and
say
no
and
the
attempt
to
send
the
spam
emails
will
be
thwarted.
A
A
A
A
One
is
the
application
or
client
id
that
uniquely
identifies
this
application,
and
also
since
this
is
a
single
tenant
app
and
we'll
talk
about
multi-tenant.
Later,
it's
actually
pretty
simple,
but
since
this
is
a
single
tenant
app,
I
need
to
specify
which
tenant
and
so
the
directory
or
tenant
id
uniquely
identifies
this
tenant.
A
I've
also
set
up
authentication,
so
azure
ad
uses,
a
protocol
called
oauth
2.0
and
one
of
the
ways
of
authenticating,
specifically
to
a
web
browser
based
off,
is
to
redirect
the
user
over
to
azure
id,
where
maybe
they
log
in
maybe
they
provide
some
consents.
Maybe
they
do
two-factor
authentication
whatever
they
do.
A
Azure
id
if
they've
authenticated,
will
send
an
access
token
or
actually
an
auth
code
back
to
the
application
so
that
it
can
get
the
information
that
it
needs
to
call
the
graph
so
that
redirect
back
needs
to
be
registered
for
security
reasons,
and
this
is
the
special
magic
redirect
url
that's
used
by
postman.
This
postman
is
going
to
basically
pop
up
a
web
browser
for
me
to
do
my
login.
A
I
also
have
set
up
an
app
secret,
which
is
here-
and
you
can't
see
it
anymore,
but
when
you
first
create
one
of
these,
you
have
to
save
it
away
somewhere
safe,
because
you
can't
see
it
after
that,
and
I've
also
gone
in
and
set
up
some
api
permissions.
So
these
are
all
for
calling
the
microsoft
graph.
A
You
can
see
there's
a
number
of
them
here,
I'm
just
going
to
add
one,
and
specifically,
I'm
going
to
show
this
call
which
allows
you
to
show
what
microsoft
teams
a
user
is
a
member
of
the
logged
in
user
in
particular.
So
let
me
just
come
down
here.
I've
already
looked
up
this
call
and
team.readbasic.all
is
the
minimum
permission
to
get
that
information.
A
So
inside
of
the
graph
documentation,
they're
very
detailed
about
what
specific
permission
scopes
are
necessary
to
make
any
one
of
the
calls.
Now,
I'm
going
to
grant
consent,
see
where
it
says
on
the
right.
Admin
consent,
it's
kind
of
chopped
off,
but
that's
just
is
admin.
Consent
required,
that's
different
from
what
I'm
doing
here,
I'm
actually
just
granting
the
consent
on
behalf
of
all
users,
because
I
have
an
admin
all
right.
A
So
now
I've
done
that
let's
go
over
to
postman
and
I'm
actually
using
a
collection
here
called
the
microsoft
graph
collection
for
postman
and
you
can
download
it
here.
I'll
put
the
url
on
the
screen
and
there's
some
information
that
I
need
to
now
put
in
here,
specifically
that
client
id
and
the
tenant
id
that
I
had
copied
from
the
app
registration.
A
So
now,
let's
go
find
that
api
call
in
the
list
actually
before
I
do
that.
Let
me
come
down
and
show
you
that
I'm
going
to
be
authorizing
using
the
browser
using
what's
called
an
auth
code
flow
and
there's
the
auth
url
and
the
access
token
url.
Both
of
them
have
the
tenant
id
and
then
the
client
id
the
client
secret.
All
that
information
is
there
and
you
can
see
that
it's
actually
showing
up
underneath
of
these
special
tokens
inside
of
postman
and
I'm
gonna
go
ahead
now
and
get
that
access
token.
A
Here's
the
pop-up,
as
I
mentioned
it's
going
to
have
me
sign
in
and
because
I've
pre-consented
as
an
admin.
I
don't
really
need
to
ask
the
user
for
permission
and
now
postman
gives
me
this
access
token
and
we'll
look
at
one
of
those
in
more
detail
later.
But
for
now
let's
just
go
down
and
find
the
my
joint
teams.
A
A
Now,
in
a
few
minutes,
I'll
show
you
something
very
similar
using
a
single
page
application,
but
before
we
go
there,
I
want
to
try
to
clear
up
some
common
areas
of
confusion
that
people
have
when
they're
learning
about
azure,
ad
and
microsoft
365..
The
first
area
of
confusion
is
different.
Things
called
azure
id,
it's
really
a
naming
problem
inside
of
microsoft.
A
A
So,
if
you
see
azure
acs
on
an
article
or
some
documentation,
that's
not
the
one
you
want,
probably
more
confusing
is
over
on
the
right
side
of
the
chart.
Azure
adb
to
c
azure,
adb
to
c,
is
also
a
social
federation
protocol
that
allows
you
to
build
high
scale,
applications
that
have
people
logging
in
with
google,
facebook,
microsoft,
consumer
accounts
etc,
but
it's
a
completely
different
directory
service
than
azure
ad.
A
A
That
only
works
with
azure
ad,
where
the
new
v2
endpoint
is
quote,
unquote,
unified.
In
other
words,
your
application
can
work
with
both
azure
id
and
microsoft.
Consumer
accounts,
the
v1
endpoint
only
supports
static
consent,
meaning
that
people
will
consent
once
to
every
permission
that
the
app
needs,
whereas
v2
allows
dynamic
consent
so
that
the
app
can
ask
for
more
permission,
as
the
user
is
using
the
application
v1,
you
would
program
it
with
an
older
now,
deprecated
library
called
adol,
v2
program
that
with
the
mcel
library
and
really,
and
they
have
a
unified
registration
portal.
A
A
A
Every
microsoft
365
subscription
has
exactly
one
tenant,
one
azure
ad
domain
associated
with
it.
They
always
map
one
to
one,
whereas
many
azure
subscriptions
can
trust
the
same
azure
ad
domain.
So
you
could
decide
to
have
a
bunch
of
different
azure
subscriptions,
perhaps
with
different
administrators
different
billing.
What
have
you
and
connect
them
all
to
the
same
azure
ad
domain?
A
You
have
to
be
aware
that
it
might
be
pointing
to
a
different
azure
ad
domain
and
you
might
need
to
switch
that
now
I'll
put
a
link
here
to
an
article
that
explains
how
to
make
that
change.
But
I'll
tell
you
that
you
could
also
in
doing
this
break
other
things
that
are
already
inside
of
that
azure
subscription.
A
So
you
may
not
want
to
reuse
an
azure
subscription
if
it
requires
you
to
change
to
a
different
azure
ad
domain
and
if
it's
in
use
for
other
purposes,
another
area
of
confusion
and
the
ui
has
gotten
much
better
about
this-
is
that
there
are
different
names
for
the
same
thing
that
are
commonly
used
in
our
documentation
and
in
our
apps
and
even
in
the
user
interface.
A
tenant
id
and
a
directory
id
are
the
same
thing.
They're
the
same
good
same
globally,
unique
identifier,
client
ids,
are
often
referred
to
as
app
ids
or
application.
A
Ids
client
secrets
are
sometimes
referred
to
as
app
secrets
or
app
keys.
It's
basically
a
password
used
to
authenticate
the
application's
identity
and
there's
also
something
that
we'll
get
to
later
called
an
enterprise
application,
which
is
also
called
a
service
principle,
and
so
these
things
are,
you
know,
hopefully
less
confusing,
now
that
you
know
that
they're
that
they're
really
the
same.
The
final
concept
that
confuses
people-
and
this
is
super
important
to
understand-
is
the
idea
of
different
permission
types.
A
A
The
different
oauth
flows
lead
you
to
one
or
the
other
of
these
types
of
permissions,
so
user
delegated
is
what
I
used
in
my
web
browser.
My
postman
example
and
that's
how
I
was
able
to
see
which
teams
I
was
a
member
of
right
because
I
had
to
be
logged
in
your
effective
permissions
under
delegated
permissions
is
the
intersection
of
what
the
user
can
access
and
what
the
app
can
access,
for
instance,
suppose
that
alice
has
access
to
teams
one
two
and
three
and
the
app
has
files.read
permission.
A
When
the
app
is
running
under
alice's
login,
it's
going
to
be
able
to
read
the
files
in
teams,
one
two
and
three
makes
sense.
It's
just
the
intersection.
You
can't
write
the
files,
because
the
app
only
has
read
access
and
it
can't
access
the
files
in
team
four
in
any
way,
because
alice
doesn't
have
access.
A
The
other
option
is
app
permissions.
This
is
typically
used
in
background
services
and
also
to
elevate
permissions.
If
your
app
needs
to
do
something
that
the
user
doesn't
have
permission
to
do
like
write
to
an
audit
trail
or
something
like
that.
So
in
that
case
you
would
use
app
permissions
and
these
can
only
be
consented
by
admins,
there's
no
associated
user
and
typically
you're
going
to
get
access
to
everything
in
the
tenant.
So
if
I
had
files
dot,
read
app
permission
that
allows
me
to
read
every
single
file
inside
of
that
microsoft,
365
tenant.
A
A
You'll
still
see
it
in
some
of
our
documentation,
because
it
wasn't
that
long
ago
that
that
was
the
only
option
from
a
web
browser
in
azure
id.
But
we
now
support
auth
code.
Pkce,
that's
preferred
the
problem
with
that.
One
is
that
it
passes
the
access
token
back
to
the
application
in
the
url
of
a
redirect.
A
So
that
means
that
anyone
who
could
maybe
see
that
url
or
if
it's
getting
cached
somewhere,
that
that
might
be
able
to
be
reused
in
a
replay
attack.
Https
is
mostly
going
to
protect
you
from
that.
But
that's
why
we
now
avoid
the
implicit
flow
and
the
other
one
is
a
simple
username
password,
which
is
sometimes
called
user
credentials
flow
or
resource
owner
password
credentials,
because
we
have
to
have
fancy
names
for
everything
really
want
to
avoid
this.
A
A
So
inside
of
teams
we're
primarily
going
to
use
these
four
flows,
the
auth
code,
pkce
flow
is
going
to
be
used
in
side
of
the
commercial
marketplace.
So
if
you
are
programming
your
landing
page
for
a
user
who
has
just
purchased
your
application
in
the
marketplace,
this
is
actually
considered
sso
to
the
commercial
marketplace
people.
So
when
commercial
marketplace
says
you
need
sso
to
sell
in
the
team
store,
they
mean
you
must
support
the
off
code.
Pkce
flow
to
log,
the
user
in
to
the
landing
page
after
they've
made
a
purchase.
A
A
You'll
also
see
off
code
flow
without
pkce.
It's
a
subtle
difference.
The
bot
framework,
if
you're
logging
into
a
bot
is
going
to
use
the
off
code
flow
on
behalf
of
flow
is
used
in
teams
sso,
and
we
have
rabia
williams
and
I
recorded
a
whole
video
on
that.
So
I'm
going
to
talk
about
it
here,
but
we'll
go
into
the
code
and
the
details
in
that
other
video
and
then
we
have
the
client
credentials
flow.
So
these
are
the
ones
that
are
going
to
be
used.
The
most
frequently
inside
of
a
teams,
application.
A
I
want
to
take
a
moment
here
to
point
out
another
protocol
that
you
may
encounter
called
open
id
connect.
Openid
connect
is
based
on
oauth
2.0,
but
where
oauth
2.0
is
about
authorizing
applications
to
do
things,
so
you
get
an
access
token,
which
allows
you
to
call
a
backend
service
of
some
kind
web
service.
A
Open
id
connect
is
about
authentication
normally
with
teams
apps,
that
teams
app
is
going
to
have
to
call
the
microsoft
graph
or
some
other
back-end
api,
even
your
own
apps
api
that
is
secured
with
azure
id,
and
it's
going
to
use
oauth
2.0.
That's
why
I'm
mainly
focusing
on
that
in
this
video,
but
if
you
simply
want
to
authenticate
the
user
for
your
app's
own
purposes,
perhaps
to
grant
permission
to
certain
assets.
A
A
It
recognized
that
I
was
already
logged
in
and
it
continued
from
there
without
me
actually
being
prompted.
This
would
be
considered
single
sign-on
for
the
purposes
of
the
commercial
marketplace,
landing
page
that
you
need
to
get
into
the
team
store
it
works,
and
you
can
see
that
what
it's
doing
here
is
it's
showing
me
a
list
of
my
files
inside
of
the
my
onedrive,
and
I
can
come
in
here
and
download
one
of
the
files
and
take
a
look
at
it.
A
It's
my
favorite
cat
and
I
can
even
upload
a
file
if
I
want
to
so.
Let
me
do
that
and
show
how
that
works
and
that
all
works
fine.
So
let's
go
back
and
look
at
the
at
the
registration
for
this
app,
so
this
is
a
different,
app
id
same
tenant
id
under
authentication
instead
of
web.
I
said
single
page
app
with
my
app's.
Url
is
localhost
colon
8080,
which
is
correct,
and
it
says
here
my
redirect.
Uri
is
eligible
for
auth
code
with
pkce.
So
that's
what
I'm
using
in
the
code.
A
I
don't
have
a
client
secret.
Don't
really
need
one
for
this.
You
can't
actually
in
fact
in
postman,
I
didn't
need
it
either.
I
just
had
it
there,
so
I
could
try
other
things
in
this
case
of
a
single
page
app.
You
can't
really
trust
a
secret
in
the
web
browser
anyway,
so
you
really
just
don't
even
need
it
here
and
then
the
api
permissions-
all
I
have
is
user.read,
which
is
very
limited,
just
allows
me
to
sign
in
and
read
the
user
profile.
A
So
how
is
it
that
I
was
able
to
access
my
files
list
and
upload
and
download
files?
Well,
it
turns
out
that
there's
another
part
to
this
puzzle.
So
this
is
where
the
app
is
registered,
but
the
consent
of
permissions
is
actually
stored
under
enterprise
applications,
so
I
could
get
it.
I
could
navigate
there
here,
but
I'll.
A
A
A
I
also
have
down
here
the
get
token
function,
which
is
calling
this
sdk
another
sdk
called
microsoft,
authentication,
library,
2.0
or
msl
2.0,
and
it's
going
to
take
care
of
a
lot
of
the
details
for
me,
one
thing,
though,
that
is
specific
to
this
app.
Is
this
ensure
scope
function,
so
this
is
going
to
allow
me
to
dynamically
add
more
permissions
as
I'm
running
and
that's
called
dynamic
consent,
so
ensure
scope.
A
A
A
A
What
that's
about
is
it's
really
about
the
fact
that
you
need
to
initiate
any
kind
of
a
pop-up
in
a
web
browser
using
a
user
action
right,
so
that's
been
around
for
a
while.
Now
it's
a
standard
thing:
it's
not
a
microsoft
thing,
web
browsers,
just
to
avoid
filling
people's
screens
with
nefarious
pop-ups.
A
A
A
call
to
display
the
ui
not
by
pushing
the
button
right
now.
It
should
come
right
back
and
notice
that
I
saw
the
pop-up
momentarily,
but
I
didn't
actually
have
to
click
the
button.
Okay.
So
now,
let's
look
at
that
same
exact,
login
method,
inside
of
a
teams
app
and
it
does
work
it's
just.
The
user
is
going
to
see
a
pop-up,
so
I'm
going
to
use
teams
off
pop-up
with
azure
active
directory
and
msl
2.0,
as
the
libraries
that
I
use
inside
of
the
pop-up.
A
A
A
A
If
I
go
over
to
the
mobile
client,
it
looks
slightly
different,
but
I
still
see
the
pop-up
right,
and
so
this
is
sort
of
the
reality
of
this
method
of
log
on.
So
let's
take
a
look
at
the
code,
so
here
I
am,
this
is
a
react
app,
so
I'll
try
to
explain
the
react
bits
away
quickly,
because
I
want
to
really
focus
on
getting
the
access
token
to
call
the
graph
right.
This
is
the
tab
and
it's
going
to
call
a
service.
A
So,
in
this
case,
my
pop-up
code
is
under
slash,
pound
teams
off
pop-up
right
and
then,
if
it
succeeds,
I'll
grab
that
access
token
and
and
use
it
in
the
graph
call
here's
teams
off
pop-up
and
it's
going
to
call
its
own
another
little
service,
I've
written
here,
which
is
ultimately
going
to
call
m
cell.
Here's
that
m
cell
config
and
here's
where
it's
going
to
actually
go
in
and
and
get
that
access
token
from
msl
just
just
like
before
it's
just
the
code
is
kind
of
structured
differently.
A
So
yes,
this
works.
Yes,
this
is
the
shortest
path
to
happiness
for
a
application
that
is
not
using
azure
id.
You
could
get
your
app
into
the
team
store
using
this
technique.
The
mandatory
sso
is
on
the
commercial
marketplace
side
when
somebody
just
bought
your
app,
and
in
that
case
it's
just
going
to
use
normal
web-based
flow.
It's
not
going
to
do
any
of
this
teams
pop-up
stuff
to
do
it.
A
So
it's
much
more
like
the
first
example.
If
I'm
in
teams,
however-
and
I
use
this
technique-
and
particularly
if
I
don't
use
azure
active
directory,
there
are
some
usability
issues
that
come
up.
I
mean
okay,
you
can
publish
that
app
and
you
can
put
people
on
the
app
they're
gonna
always
see
the
pop-up
first
of
all
and
second
of
all,
and
possibly
more
importantly,
you're
going
to
create
a
challenge
for
anyone
who
uses
that
app,
particularly
for
any
owner
of
a
team
of
people
who
are
using
the
app
suppose.
A
I
adopt
an
app
that
uses
some
other
directory
system
and
I
want
to
bring
it
into
teams
right,
so
my
users
are
going
to
be
able
to
access
that
app
from
inside
of
teams.
So
the
first
thing
I
have
to
do
is
go
to
every
user
in
the
team
and
ask
them
to
sign
up
under
whatever
directory
service,
that
app
uses
and
then
tell
me:
what's
your
login
in
that
other
directory
service,
then
I
have
to
go.
A
A
Otherwise,
they're
going
to
click
the
tab
and
see
a
big
access
denied
from
your
app
right.
It
actually
gets
worse,
though.
What
if
somebody
leaves
the
team
right,
is
that
admin
going
to
remember
to
go,
find
that
matching
user
account
inside
of
the
other
directory
and
remove
them
inside
of
your
app
or
long
after
they've,
maybe
left
the
company.
Are
they
still
going
to
be
able
to
use
that
other
id
to
log
into
the
app
and
get
at
potentially
confidential
data
that
they
shouldn't
really
have?
A
This
all
becomes
administrative
burden
and
those
administrators
are
often
going
to
be
part
of
the
decision
factor
of
what
app
to
use.
So
I
will
tell
you
in
no
uncertain
terms
that
the
administrators
and
the
users
are
both
going
to
appreciate
it
if
you
integrate
with
azure
ad
and
don't
require
them
to
maintain
two
sets
of
user
accounts
for
you,
one
for
using
your
app
and
one
for
using
the
rest
of
m365
okay.
So
now,
let's
look
at
what
teams
engineering
calls
sso?
A
This
is
teams
tab,
sso,
the
user
never
has
to
sign
in
they
don't
see
a
pop-up,
nothing.
The
user
identities,
of
course,
are
the
same
as
they
would
be
in
teams
itself.
So
there's
no
coordination
that
the
administrator
needs
to
do
between
the
two
and
you
don't
need
to
write
a
login
pop-up
page
at
all,
and
the
user
is
never
going
to
see
one
the
limitation
is
well.
It
does
require
you
to
write
some
server
side
code
to
do
a
token
exchange,
as
well
as
the
client
side
code.
That
is
your
user
interface.
A
A
A
A
First,
we're
going
to
get
an
auth
token
from
microsoft
teams,
so
we're
just
going
to
call
this
function
called
get
off
token,
using
the
teams
javascript,
sdk
and
magically
through
the
use
of
that
exposed
api,
which
is
noted
in
the
manifest
it
will
give
us
an
access
token.
However,
this
token
has
very
very
little
permission.
A
It
has
to
really
be
exchanged
for
a
better
token,
a
more
privileged
token
on
the
server
side.
So
the
next
step
is
we're
going
to
send
this
off
to
our
very
own
server
side
code,
to
exchange
it
for
a
more
privileged
token,
and
when
I
get
that
back,
I'm
going
to
use
that
more
privilege
token
to
call
the
microsoft
graph
here.
You
can
see
that
that
it
gets
passed
in
to
as
data
in
the
authorization,
header
bearer
space
and
then
the
token.
That's
just
the
way
that
all
these
tokens
get
passed
in.
A
If
we
take
a
quick
look
at
the
server
side
code,
here's
that
slash
off
slash
token
call
and
what
it's
going
to
do
is
it's
going
to
call
azure
ad
using
what's
called
an
on
behalf
of
flow
to
exchange
our
weak
token.
For
a
stronger
token,
that
has
permission
that
we
want
in
the
microsoft
graph
with
all
those
scopes
in
it.
So
that's
again
I'll
refer
you
to
the
video
for
more
details,
but
that's
what's
involved
in
building
one
of
these.
A
A
A
The
advantage
of
that
is
that
you
don't
have
to
host
the
solution
at
all.
You
can
host
it
in
sharepoint,
which
is
part
of
your
customers
m365
subscription,
so
you
don't
have
to
pay
to
host
it.
This
is
going
to
work
great
for
some
applications
and
not
so
much
for
others.
There's
no
multi-tenant
story
here
so
for
a
typical
isv.
A
It's
not
going
to
make
sense,
but
I
still
wanted
to
show
it
to
you,
because
it's
the
same
as
the
sso
case
from
a
user
experience
point
of
view,
because
guess
what
under
the
covers
sharepoint
is
using
that
sso
mechanism,
so
you
don't
need
a
login
page.
It
works
with
any
azure
id
secured
service,
including
the
microsoft
graph,
and
the
downsides
are
that
the
admin
always
has
to
consent
and
that
consent
is
often
going
to
be
shared
with
other
web
parts
in
the
tenant.
So
so
let
me
show
what
that
looks
like
that.
A
Was
it
it's
a
really
quick
demo
right
if
I
leave
and
go
and
come
back,
you'll
see
that
it's
going
to
just
come
up
immediately.
So
that's
great,
and
even
if
I
go
over
to
my
mobile
client,
you'll
see
the
same
result.
It's
just
going
to
immediately
come
up
for
me
and
click
it
and
okay,
just
a
sec.
There
we
go
beautiful.
So
let's
take
a
look
at
the
code
for
that
this.
Is
it
there's
not
a
lot,
the
sharepoint
framework,
which
is
how
you
write
a
sharepoint
web
part?
A
It's
written
in
this
framework
called
a
the
sharepoint
framework.
It
has
a
graph
client
factory
that
will
hand
you
a
microsoft
graph
client.
It
also
has
an
object.
You
can
use
to
call
arbitrary
other
azure
id
services,
maybe
some
that
you've
written
yourself
and
you
can
call
that
and
it
takes
care
of
the
authorization
for
you
automatically.
A
I
need
to
declare
that
I
need
these
permissions,
so
microsoft
graph,
mail.read
right
and
then
my
admin
needs
to
go
in
and
consent
to
that
permission
and
notice
that
all
these
permissions,
because
these
are
web
parts
that
could
share
the
page
with
other
web
parts.
They
are
actually
organization-wide.
A
So
that's
kind
of
a
limitation
right
now
is
that
we
have
sharepoint
has
something
called
isolated
web
parts
that
will
run
the
web
part
in
an
iframe
with
its
own
identity,
so
that
it
doesn't
have
to
share
permissions
with
all
the
other
web
parts,
but
currently
that
doesn't
work
in
microsoft
teams.
Therefore,
you're
going
to
have
to
share
the
permissions
with
all
of
the
third-party
web
parts
in
the
tenant.
A
Now,
of
course,
teams
apps
can
have
more
than
just
tabs,
so
the
methods
that
I've
showed
you
so
far.
They
work
in
any
browser-based
or
iframe
based
teams
app
feature,
so
they
would
work
for
a
tab,
a
configuration
page
or
a
task
module
where
a
task
module
is
really
a
pop-up
dialog
box.
All
this
is
explained
in
another
video
that
I
did
with
rabia
williams,
which
I'll
point
you
to
here.
A
So
the
need
for
sso
is
not
quite
as
severe
in
the
case
of
a
bot,
because
the
login
prompt
is
only
shown
every
few
months
there.
The
bot
framework
will
maintain
a
refresh
token
for
us.
It
will
hide
that
auth
dialog
until
the
refresh
token
expires.
So
let's
see
what
that
looks
like
for
a
user
here,
I
am
in
my
bot
and
I'm
just
going
to
say
log
in
and
it's
going
to
come
in
and
say
please
log
in
okay.
A
So
now
I
have
to
click
the
button
and
yeah
I
have
to
log
in,
but
I
only
have
to
do
this
when
the
refresh
token
expires.
So
now
I
can
show
my
email.
What
have
you
and
the
nice
thing
is
that
if
I
leave
it
and
come
back
later,
even
if
I
come
back
on
a
different
client
in
this
case,
the
refresh
token
is
in
the
bot
service.
A
A
A
A
Here's
the
client
id
once
again
and
add
that
as
an
azure,
ed
oauth
setting
to
your
bot,
then
inside
the
code-
and
this
is
the
main
dialog-
there
is
going
to
be
a
child
dialog,
which
is
an
oauth
prompt
dialogue.
And
here
you
can
see
the
text
please
sign
in
that.
You
saw
come
up
on
the
screen
and
then
this
is
I'm
not
going
to
get
into
the
way
that
the
bot
works.
A
While
these
are
the
most
common
scenarios,
microsoft
teams
also
allows
its
applications
to
authenticate
in
messaging
extensions
and
other
scenarios,
and
that's
all
detailed
here
in
the
documentation
and
hoping
to
make
future
videos
to
cover
some
of
those
other
scenarios.
So
I
want
to
close
with
a
troubleshooting
checklist
to
help
you
debug
the
situation.
If
you
have
any
problem
with
this,
the
first
thing
that
I
always
like
to
do
is
to
start
in
postman.
A
Sometimes
you'll
see
a
url
like
this
other
times,
you'll
see
a
globally
unique
id
or
good.
That
represents
that
same
application,
either
way
it
needs
to
be
that
same
application
that
you're
granting
authority
to
access,
in
this
case
the
microsoft
graph,
and
if
I
go
down
here
a
little
bit
you'll
see
some
other
useful
things
for
me
to
check.
First
of
all
make
sure
that
the
app
id
matches
the
app
id
that
you
expect
make
sure
that
the
username
is
the
one
that
you
expect.
A
A
Another
thing
to
look
at
is
the
scope
so
make
sure
that
you've
got
the
scopes
that
you
expect
and
the
tenant
id
make
sure
that
that's
right
and
then
you
can
also
check
the
signature,
and
you
can
see
here
that
it's
saying
that
it
is
issued
by
azure
id
and
the
signature
is
checking
out
here.
It's
green,
so
just
so
that
we
know
that
the
signature
part
was
successful,
so
that
can
just
kind
of
help.
You
maybe
troubleshoot
a
little
bit
of.
A
A
A
Make
sure
the
permissions
are
correct.
Are
you
using
the
right
kind
of
permission,
app
permissions
for
client
credentials
flow
or
delegated
permissions
for
any
other
kind
of
a
flow?
Were
there
any
admin
consents
that
were
required.
So
if
I
go
back
to
an
azure
id
registration,
the
permissions
that
are
here
you
can
see.
These
have
all
been
granted
and
they're
checked
off.
You
can
also
see
this
column.
Admin
consent
required.
A
So
there
are
some
permissions.
Let's
go
find
one
that
are
so
sensitive
that
you
need
the
you
need
the
admin
to
consent.
Users
just
aren't
allowed
to
consent
to
some
of
these.
So,
for
instance,
if
I
go
to
sites.fullcontrol.all,
this
gives
access
to
all
the
sharepoint
sites
in
the
tenant,
possibly
limited
by
what
the
user
has
access
to,
but
it's
still
full
control.
A
This
requires
an
admin
to
consent,
no
matter
what,
and
so
that's
something
to
be
aware
of.
When
you're
building
your
application
that
you
take
those
into
account,
another
thing
to
note
by
the
way
is
that
these
permissions
that
are
in
the
registration
these
become
the
default
permissions
for
the
app.
A
So
if
you,
if
you
request
an
access
token
from
azure
id
with
dot
default
as
the
scopes
you'll
get
these
permissions,
if
you
request
specific
named
scopes
and
you're
in
the
v2
endpoint,
it
will
actually
go
in
and
try
to
get
more
permissions,
potentially
than
what's
listed
here
anyway.
You're
going
to
want
to
make
sure
that
all
of
those
consents
have
been
granted
is
the
off
url
that
you're
referencing,
the
right
one
for
your
resource
and,
if
you're,
using
the
implicit
flow
is
that
enabled
in
your
app
registration.
A
A
You
would
use
this
first
one
here.
The
implicit
flow
setting
is
down
here
under
authentication,
and
it's
here
so
these
ones
are
checked
off.
As
I
mentioned,
we
don't
recommend
using
this
anymore,
but
if
you
need
it
for
some
reason
it's
here
you
just
have
to
be
aware
that
these
would
need
to
be
checked
off.
A
So
just
some
troubleshooting
tips,
because
I
know
this
can
a
lot
of
times
you're
not
going
to
get
a
ton
of
information.
You
might
just
get
an
access
denied
message,
they're,
trying
to
not
give
the
hackers
too
many
clues
as
to
what's
going
on,
perhaps
so
having
these
troubleshooting
steps.
Handy
can
be
a
time
saver
and
I
will
say
that
I
myself
go
back
to
this
checklist
when
I
get
stuck
and
just
kind
of
use
it.
As
did
I
check
this.
Did
I
check
this?
A
Did
I
check
this,
and
usually
I
can
find
my
my
issue
that
way.
So
thanks
very
much
for
watching
this
video.
I
hope
it
was
helpful
to
you
in
understanding
the
single
sign-on
system,
that's
used
by
microsoft
teams,
developers
getting
the
concepts
please
if
you
like
the
video,
please
give
us
a
like,
and
if
you
want
to
see
more
videos
like
this,
please
subscribe
to
the
channel
and
feel
free
to
leave
a
comment
with
any
special
requests
that
you
might
have
thanks.
Very
much
and
I'll
see
you
in
the
next
video.