►
From YouTube: Authentication in collaborative apps with Microsoft Teams and Microsoft Identity – June 2022
Description
This month’s in-depth topic: Authentication in collaborative apps with Microsoft Teams and Microsoft Identity – Attend this session to learn how to provide users with the best user experience in your collaborative app. We will deep dive into how your app can build on Teams SSO and the Microsoft identity platform. We will also discuss how you can connect the Microsoft Identity of a user to your own user store. Presenter: Kyle Marsh - Principal Program Manager, Microsoft Entra - App Dev Architecture | @kylemar. Recorded June 16, 2022.
Learn more
• See the full blog post for this call in the Microsoft 365 platform community blog - https://aka.ms/m365pnp/blog
• Download the recurrent invite for this call | https://aka.ms/IDDevCommunityCalendar
• 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
A
As
always,
this
call
is
recorded.
We
keep
recording
of
all
the
calls
you
can
go
to
our
youtube
channel,
which
is
m365,
pnp,
slash
videos
where
you'll
have
all
the
videos
from
the
previous
calls
as
well.
You
can
follow
us
on
twitter
at
microsoft,
365,
dev
and
azure
ad,
where
you'll
get
updates
about
the
upcoming
calls.
We
have
a
lot
of
interesting
calls
lined
up,
and
this
is
a
monthly
call.
It
is
on
the
third
thursday
of
every
month.
The
next
call
is
happening
on
july
21st.
A
B
Okay,
so,
let's
jump
into
what's
going
on
under
the
covers
when
we're
looking
at
building
authentication
in
these
collaborative
apps,
I'm
talking
about
microsoft
teams,
primarily
here,
but
actually
with
our
conversation
that
build.
We
actually
are
enabling
this
capability
in
much
more
than
just
microsoft
teams.
Now,
so
what
I'm
going
to
talk
about
will
apply
to
to
the
new
outlook,
as
well
as
things
like,
office.com
and
so
on.
So
these
collaborative
apps
are
allowing
our
applications
or
you
to
create
applications
that
plug
into
where
the
user
already
is.
B
B
Now,
what's
the
environment
in
which
these
collaborative
apps
run
well,
so
the
key
part
is
that
the
user
is
already
authenticated
into
one
of
these
collaborative
host
application
or
hub
application.
If
you
will
so
the
user's
already
signed
into
teams,
they've
already
signed
it
outlook
or
office.com,
so
the
application
has
already
performed
that
initial
authentication.
B
So
this
could
be
a
native
user
of
azure
ad.
For
that
team
it
could
be
a
guest
user
from
our
b2b
business
to
business
scenario,
where
someone
is
a
guest
in
that
tenant,
there's
native
federation
now
as
well
as
well
as
they
might
now
with
our
or
their
reach
up
with
teams
into
personal
accounts.
I
might
have
signed
into
that
team's
instance
with
a
microsoft
personal
account,
a
consumer
account
like
outlook.com
or
skype.com
or
xbox.com,
something
like
that.
So
an
application,
that's
running
inside
of
this
environment.
B
Instead
of
going
and
asking
the
user
directly
and
saying,
go
ahead
and
authenticate
to
some
system,
they
can
actually
ask
the
microsoft
teams
or
outlook
etc.
Who
is
this
user?
Since?
Could
you
get
the
authentication
information
for
me
so
that
I
don't
have
to
have
the
user
go
back
to
the
original
identity
provider
and
attempt
to
do
an
authentication
again,
so
the
environment
here
is
these
collaborative
apps
are
running
inside
of
an
application
that
already
knows
who
the
user
is.
So,
let's
get
that
application
to
help
us
to
help?
B
B
We
would
have
windows
know
who
the
user
is,
because
I
signed
into
windows
with
my
corporate
identity
and
then
my
application
could
have
just
gone
ahead
and
asked
windows
who
the
user
is.
I
didn't
need
the
user
to
authenticate
again
well
this.
These
collaborative
apps
can
do
the
same
thing,
whether
they're
running
in
any
of
these
post
processes
or
applications
in
any
of
these.
They
can
go
ahead
and
ask
that
container.
Who
is
the
user
and
not
have
to
do
that
work
themselves?
B
Let's
start
with
the
process
here,
so
I'm
I've
got.
Let's
say:
microsoft.
Teams,
that's
running
the
first
thing
that
teams
needs
to
do
is
they
need
to
authenticate
the
user,
so
they
go
off
to
azure
active
directory
in
order
to
make
that
authentication
request
now
what's
key
here,
is
that
it's
the
team's
web
service?
B
The
whole
point
of
whether
an
application
and
azure
id
can
determine
if
the
user
is
already
authenticated
relies
on
the
fact
that
we're
using
the
same
web
surface
in
order
to
make
the
request
right,
there's
state,
cookies,
etc
that
are
left
as
artifacts
of
the
actual
authentication.
So
let's
say
the
user
does
need
to
do
an
authentication
here,
they're
typing
in
their
password
they're,
doing
a
password
and
authentication
password.
B
This
authentication,
maybe
but
whatever
they're
doing
the
state
of
that
authentication
lives
in
the
web
service
that
microsoft
teams
is
controlling
here,
because
it's
inside
of
the
team's
app
or
inside
the
browser
where
teams
is
running
so
the
user
does
whatever
gestures
they
need
to
do,
and
now
microsoft
teams
knows
who
this
user
is.
That
happened
because
azure
active
directory
returned
something
referred
to
as
an
id
token
back
to
microsoft.
Teams
that
says
here
is
who
the
user
is.
B
B
B
Now
this
is
not
open
id
connect,
it's
not
saml!
It's
just
an
api
call.
The
team's
sdk
is
there.
I
can
run
it
when
I'm
running
in
one
of
these
applications
that
support
a
collaborative
app.
I
can
make
a
call
to
say
get
off
token
now
what
happens
under
the
covers
there
is
that
teams
is
going
to
go
back
to
azure
ad
and
specifically
ask
for
a
token,
so
that
teams
can
access
your
application
as
a
resource,
so
teams
is
still
the
primary
client
here.
B
B
All
of
that
is
already
in
that
shared
surface.
In
fact,
it's
not
really
sharing
the
surface.
In
this
case,
teams
is
just
reusing.
The
same
surface
it
used
before
so
all
of
the
artifacts
from
its
initial
authentication
are
still
in
the
team's
surface
web
surface.
So
this
will
be
a
very
smooth
authentication.
B
B
So
what
this
token
tells
your
application
is
that
teams
is
allowed
to
call
your
application
that
the
user
is
also
with
any
conditional
access
policies
having
been
checked
and
applied
and
approved,
etc,
that
everything
is
fine,
with
respect
to
the
user
being
allowed
to
use
your
application
at
this
particular
point
in
time.
So
anytime,
we
issue
one
of
these
json
web
tokens.
B
So
we
always
have
that
opportunity
and
what
we
have
now
is
a
json
web
token,
with
all
of
the
same
claims
in
it
that
you
would
have
received
if
your
application
had
gone
directly
to
azure
et
to
authenticate
the
user,
it's
just
wrapped
up
in
a
slightly
different
container
in
that
it's
an
access
token,
instead
of
an
id
token
now
what
has
to
happen
in
order
to
be
able
to
issue
that
access
token
that's
issued
to
microsoft
teams
to
be
given
to
your
resource
is.
We
need
a
very
specific
set
of
application
registrations.
B
I
should
mention
before
we
talk
about
the
registration
that
json
web
token
you're
getting
from
teams
can't
just
be
trusted
right.
It's
a
json
web
token,
that's
issued
by
azure
ad,
but
it's
gone
through
a
third
party,
your
you're,
the
first
party
azure
id
is
the
other
party.
It's
gone
through
microsoft
teams
and
you
can't
trust
a
token
if
you
don't
get
it
directly
from
the
issuer.
So
it's
important
that
your
application
actually
validates
that
this
token
is
legitimate.
B
So
it's
going
to
do
things
like
check
the
signature
of
the
token
to
make
sure
that
it
isn't
tampered
with
make
sure
that
the
issuer
comes
from
azure
ad.
Make
sure
that
the
expiration
time
is
correct.
All
of
that
has
to
happen
before
your
application
should
accept
this
token.
As
now
I
know
who
the
user
is.
B
B
I
don't
actually
have
to
implement
an
api.
I
don't
have
to
go
off
and
create
a
server
and
and
implement
some
apis,
but
I
do
have
to
register
through
as
an
exposing
api,
because
I'm
effectively
registering
this
application
to
be
a
resource
to
teams
or
outlook
itself,
so
we're
going
to
expose
an
api
in
our
application
registration.
B
B
The
application
id
uri
is
really
just
the
string.
We
use
to
uniquely
identify
your
application
so
by
default,
whenever
you
first
say
I
want
to
expose
an
api
in
your
application,
azure
id
will
suggest
an
application
id
uri.
That
would
look
something
like
api,
colon
slash
and
then
the
application,
id
or
client
id
of
your
application,
because
we
know
that
to
be
unique
across
all
of
azure
active
directory,
because
obviously
the
identifier
for
your
api
has
to
be
unique.
B
So,
but
that's
really
not
good
enough
for
the
team's
sso
implementation
teams
does
an
additional
set
of
checks.
They
can
check
the
location
where
the
the
request
is
coming
from
to
their
sdk,
so
that
they
can
then
make
sure
that
the
right
entity
is
really
asking
for
to
get
this
off
token.
So
teams
requires
you
to
put
the
domain
where
the
application
is
running
from
as
part
of
your
application
id
uri.
B
So
here,
for
example,
since
I'm
running
for
my
kylemar.dev
domain,
I
had
to
add
that,
as
part
of
my
application
id
uri
just
to
identify
that
this,
which
domain
my
application
is
running
from,
and
that
gives
teams
the
opportunity
to
do
an
additional
check
before
they
go
ahead
and
get
that
token
for
your
teams
app.
So
this
is
a
requirement
that
is
put
in
by
teams
so
that
they
can
do
that
additional
check.
B
We
know
that,
because
you
checked
the
signature
earlier
on
so
the
way
that
your
application
finds
out,
who
the
user
is,
is,
with
a
delegated
permission,
access
token
that
teams
acquires
for
in
order
to
call
to
access
your
application
as
this
resource.
So
we
expose
this
access
as
user
scope
so
that
the
teams
app
can
go
ahead
and
call-
and
this
is
what
they're
going
to
use
to
say.
B
I
need
a
token
to
this
particular
api,
or
this
particular
app
and
the
actual
address
or
the
actual
id
of
that
scope
is
the
full
qualified
name
here.
So
it's
api
colon.
You
know,
teams,
auth,
sso,
etc
all
the
way
through
to
the
accesses
user
value
as
well.
That's
one
big
long
string
that
identifies
the
scope,
the
ability
of
that
token.
That
teams
is
going
to
ask
for
and
eventually
pass
to,
your
application.
B
There's
one
other
thing:
we
need
in
the
application
registration,
and
that
is
we're
going
to
pre-consent,
if
you
will
to
the
microsoft
teams
app.
So
this
means
that
since
it's
a
pre-authorized
client
application
or
an
authorized
client
application
you
as
the
developer
of
the
resource,
in
this
case,
the
resource,
is
your
teams
app
as
the
developer
of
that
resource
you're
saying
these
applications
do
not
need
to
be
consented
in
order
to
get
this
token
right,
so
just
to
get
the
the
identity
token.
B
We
we
pre-authorized
that
app
and
what
you
see
here
are
the
application
or
client
ids
of
microsoft
teams,
which
has
two
different
implementations.
One
is
a
pure
browser-based
implementation.
That's
one
of
these
ids
and
the
other
one
is
the
native
client
implementation
and
that's
the
other
id
so
you're
pre-authorizing.
B
These
client
applications
to
be
able
to
work
with
your
resource,
which
is
your
team's
app
now
starting
from
build
this
year,
we're
actually
expanding
that
list
to
additional
applications.
That
also
might
need
that
your
application,
your
collaborative
app,
might
run
in.
So
this
is
the
expansion
into
outlook
and
office.com
etc.
So
these
are
additional
client
ids
that
are
also
allowed
to
call
and
get
access
tokens
to
your
client
without
necessarily
always
requiring
consent.
B
B
B
So
what
I
need
to
do
is
locate
this
user
in
my
own
system,
using
the
identifiers
they're
effectively
their
microsoft
identity.
Now
what
you
want
to
do
there
is,
you
could
use
the
subject
claim.
The
subject
claim
is
unique
to
your
application,
so
the
subject
claim
that
you
get
in
your
token,
will
not
match
up
for
this
user
to
any
other
application.
It's
based
on
client
id,
so
that's
one
identity
that
you
could
use
more
commonly.
B
B
The
token
will
also
have
things
like
the
user's
display
name.
So
if
all
I
wanted
there,
I
would
I'd
be
able
to.
You
know
just
get
that
right
out
of
the
token.
But
if
I
have
a
store
that
I'm
connecting
to
the
user
of
my
service
or
application,
then
I
need
to
to
find
that
user.
Based
on
these,
these
keys,
whether
the
object
id
tenant,
I
key,
maybe
the
subject
to
yellow
it's
like
likely
to
be
the
tenant
id
and
object
id.
B
If
I
find
that
user,
then
I
can
say
great,
my
user
is
authenticated.
Authentication
is
a
state
that
your
application
respects.
It
says.
Okay,
now
that
I
went
off
and
called
and
got
an
access
token
or
an
id
token
from
azure
id.
My
application
considers
this
user
authenticated
and
can
now
go
ahead
and
proceed.
B
Now
we
strongly
suggest
that
you
cause
the
need
to
go
through
an
actual
authentication.
I
see
lots
of
developers
who
say
well.
I
can
just
look
at
this
email
claim
because
I've
used
email.
So
if
I
use
the
same
email
claim,
that
should
be
enough.
Our
concern
there
is
that
email
is,
is
not
an
immutable
claim.
B
Different
users
may
have
the
same.
Email
across
time
depends
how
fast,
for
example,
a
company
may
recycle
their
emails
sure
in
some
cases
I
might
look
at
a
line
of
business
app
and
and
their
on-premise
it
pros
will
insist
that
they
never
ever
ever
hard
and
fast
rule
of
never
reusing
an
email,
then
maybe
I
could
use
it,
but
in
general,
especially
for
isvs,
you
have
no
idea
if
there's
a
good
process
here.
B
Now,
once
you've
done
that
connection.
Of
course,
the
user's
there
they've
they've
gone
ahead
and
signed
into
your
system,
so
that
now
you
have
an
opportunity
to
link
those
two
identity
systems
together
at
least
be
able
to
cross-reference
by
providing
that
link
through
something
like
the
tenant
id
and
object
id
combination
depending
upon
so
just
a
final
warning.
You
know
you
shouldn't
try
to
match
on
values.
It
could
be
spoofed
or
changed
in
any
way.
B
But
now
I
have
to
think
about.
Where
are
my
users
coming
from,
because
as
an
individual,
I
might
have
a
number
of
different
identities
within
the
microsoft
identity
system.
So
I
could
have
a
personal
account
and
I,
as
an
individual,
might
also
have
a
corporate
account.
So,
for
example,
I
have
kylemar
outlook.com.
B
I
also
have
kyle.marsh
at
microsoft.com,
because
I
work
at
microsoft,
but
I'm
also
a
guest
in
a
number
of
other
tenants
that
still
use
my
kylmar
microsoft.com
account.
It
could
be
either
my
corporate
one
there
or
even
I
could
be
a
guest,
an
attendant
using
my
kylemart
outlook.com
identity
as
well.
So
there's
a
number
of
different
identities
that
I,
as
an
individual,
might
have
within
the
microsoft
system
now,
depending
upon
the
nature
of
the
resource
that
you're
providing.
B
Similarly,
your
application
may
have
lots
of
different
places
where
the
user
might
be
as
well
right.
So
am
I
accessing
this
as
a
guest
in
a
particular
tenant?
You
know
what
how
what
what
of
your
resources
am
I
trying
to
get
to
so,
for
example,
on
the
left.
I
have
worked
with
one
company,
where
I
ended
up
with
accounts
in
their
directory
with
all
three
of
these
different
scenarios,
where
I
set
up
a
personal
account
with
a
personal
email.
B
I
set
up
a
corporate
account
because
my
company
started
licensing
some
of
their
software
and
I
also
had
a
previously
set
up
a
another
personal
account
that
had
used
my
corporate
email
address.
So
I
had
three
different
accounts
in
their
system,
all
of
which
needing
to
map
to
identities
in
azure
id
and
even
there
I
might
have
additional
identities
as
well.
I
could
be
a
guest
in
a
tenant.
I
could
be
a
native
user
in
the
tenant
etc.
B
Now,
if
all
I
need
to
know
is
who
the
user
is,
I'm
just
going
to
authenticate
the
user,
say
I'm
not
going
to
call
microsoft
graph,
I'm
not
going
to
call
any
other
resources
that
are
protected
with
with
microsoft,
ontra
any
other
api.
I'm
really
ready
to
stop
here.
I
now
know
who
the
user
is.
I
got
a
valid
token
from
the
from
the
user's
identity
provider
I'm
good
to
go,
but
if
I
do
need
to
make
calls
to
additional
resources,
the
token
that
I
was
given
from
that
get
off
call
in
the
teams.
B
Sdk
isn't
any
use
to
me
at
all.
I
can't
do
anything
with
that
token.
It's
an
access
token
to
my
application,
so
it
doesn't
allow
me
to
access
any
other
resources,
so
I'm
going
to
have
to
go
get
a
different
token
in
order
to
call
microsoft
graph
or
a
sql
or
any
other
service
or
resource
that's
protected
with
azure
ad.
B
B
Our
preferred
solution
is
that
I'm
going
to
do
an
on
behalf
of
flow
and
on
behalf
of
grant,
but
for
that
I
do
require
a
secure
backend
in
order
to
ask
azure
ad,
to
take
the
token
that
I
got
that
allowed
teams
to
access
my
application
and
say
now,
I
in
turn
would
like
to
access
a
microsoft
graph
on
behalf
of
the
user.
I
can
only
do
that
with
something
called
a
confidential
client,
and
in
order
to
for
that
to
happen,
it
has
to
be
from
a
secured
backend.
B
If
I
don't
have
a
secure
backend,
then
I'll
have
to
go
ahead
and
make
a
regular
oauth
2
call
from
my
client
from
my
from
that
javascript
client
in
order
to
get
that
additional
token.
Let's
take
a
look
at
the
on
behalf
of
scenario.
First,
so
we've
gone
ahead
and
gotten
our
token
from
our
get
out
call
to
microsoft
teams
and
now,
because
it's
a
confidential
client,
I
can
have
client
credentials.
B
B
The
first
thing
my
app
is
going
to
provide
this
secure.
Backend
is
the
json
web
token,
the
jot
token
that
I
got
from
that
get
off
call
to
the
microsoft
teams
sdk,
because
that
identifies
the
application,
in
this
case
the
your
team's
app
and
it
also
identify
who
the
user
is
for
which
this
motion
is
taking
place.
So
you're,
acting
on
behalf
of
a
particular
user,
the
identity
of
that
user
is
embedded
in
this
json
web
token.
B
This
access
token
you
got
for
microsoft
teams,
so
you
provide
that
to
azure
ad,
with
the
request
of,
for
example,
I
would
like
to
call
microsoft
graph
now
and
you
need
to
make
sure
that
that
call
to
microsoft
graph
is
bounded
by
what
this
individual
user
is
allowed
to.
Do
right
so
that
user's
identity
is
in
that
token,
so
I
also
I
I
provide
that
token
to
azure
id.
B
I
also
provide
the
client
credentials.
That
shows
that
I
am
the
entity
to
whom
this
token
was
issued.
So
one
part
of
my
client
credential
is
that
client
or
application
id
that's
part
of
my
credentials
and
that
application
id
is
inside
of
this
jw
key
as
well.
So
azure
id
knows
that
you
are
the
entity
to
whom
this
token
was
issued.
It
can
check
permissions,
or
maybe
it
may
have
to
turn
your
application
down.
Not
give
you
a
token
if
permission
hasn't
been
granted.
B
You'll
get
an
error
in
that
case,
and
you'll
have
to
go
back
and
ask
for
permission
for
whatever
additional
scope
that
it
is
you're
asking
conditional
access
can
be
checked,
etc,
but
if
all
of
those
checks
work
out
there'll
be
an
additional
access
token
minted
by
azure
id.
In
this
case,
your
application
is
the
client.
So
you
would
never
look
inside
this
access
token,
but
inside
the
access
token
does
identify
your
application.
But
now
the
audience
of
this
token
might
be
something
like
microsoft
graph.
B
So
now
on
my
secure
backend,
because
I
could
keep
a
secret,
I
exchange
the
access
token
teams
acquired
from
azure
ad
to
access
my
application
and,
let's
identify
the
user
to
my
application.
I'm
exchanging
that
token
in
a
secure
way
to
get
a
token
where
my
backend
now
or
my
application
can
call
microsoft
graph.
But
this
access
token
is
still
on
behalf
of
the
user
who
signed
into
teams.
So
I
don't
need
to
worry
when
I
call
microsoft
graph.
B
So
that's
a
great
way
to
accomplish
the
ability
for
your
application
to
call
any
microsoft
api,
primarily
microsoft,
graph
here,
but
any
api
that's
protected
by
azure
ad.
It
could
be
another
microsoft
api.
It
could
be
a
an
api
within
your
application
or
your
line
of
business
or
inside
of
your
enterprise.
B
B
B
Sdk
has
an
authentication
ui
that
I
can
use
to
drive
this
experience,
but
I
can't
be
certain
that
all
of
the
sort
of
most
seamless
sso
experience
will
happen
here,
because
I
don't
know
if
exactly
all
of
the
state,
all
of
the
cookies
everything
got
set
up
between
this
new
shared
web
surface.
So
I
may
find
that,
especially
in
the
native
applications,
I
have
to
go
ahead
and
re-authenticate
the
user,
because
I
didn't
rely
on
that
authentication
that
teams
had
done
in
the
first
place.
So
this
will
work.
B
I
can
acquire
this
token,
but
I
can't
be
certain
that
I'll
get
that
seamless,
sso
experience
because
effectively
I'm
using
a
different
web
surface
and
that's
again
really
the
key
here.
If
I
want
to
have
a
truly
seamless
single
sign-on
experience,
it
all
revolves
around
the
various
apps
and
windows
and
and
and
collaborative
app
components
all
end
up,
sharing
that
same
web
surface,
so
that
the
user's
signed
in
state
is
shared.
B
So
anytime
we
have
a
situation
like
this,
where
we
have
to
go
off
and
use
a
not
the
same
surface.
It
presents
an
opportunity
where
an
additional
authentication
could
come
into
play
and
you'll
see
this
most
often
inside
of
the
native
teams.
Experiences
when
we're
all
running
in
the
same
browser.
Everything
is
shared
by
the
browser
when
we're
not
running
in
the
browser,
it
has
to
be
shared
a
different
way
and
that's
where
these
opportunities
to
not
get
full
sharing
pop
up.
B
There
may
be
a
consent
prompt
depending
upon
the
the
state
of
whether
the
the
access
you're
requesting
has
been
granted
or
not,
but
I
should
never
have
to
re-prompt
the
user
for
their
user
id
and
password
or
their
password,
this
etc,
because
I
know
for
certain
that
all
of
these
requests
have
either
gone
through
the
same
web
surface.
That
teams
used
team
signed
in
the
user
on
their
web
service.
They
asked
for
my
token
that
the
token
to
call
my
my
application
on
that.
A
B
Surface
and
then,
when
I
do
my
on
behalf
of
a
request,
it
doesn't
require
a
web
surface
at
all.
It
works
off
those
client
credentials.
So
I
don't
I'm
quite
confident
I
don't
have
to
have
the
user
go
through
authentication
again,
if
I
can't
do
that,
there's
always
a
risk
that
the
user
may
have
to
authenticate.
B
So
that's
why
we
strongly
suggest
building
off
of
the
teams
that
the
teams
sdk
and
using
that
team's
sso
call
get
off
token,
so
that
my
user
will
not
have
to
do
their
credentials
a
second
time.
Oh
before
I
open
the
questions,
I
did
have
one
question.
I
don't
know
if
anyone
on
the
call
has
used
or
looked
at
any
of
our
samples.
B
B
Other
feedback
we'd
love
to
hear
any
feedback
if
you've
used
any
of
our
samples
to
do
this
so
far.
Outside
of
that
any
questions
or
comments
about
this
process.
I
know
it
sounds
a
little
convoluted
we're,
certainly
looking
at
ways
we
can
make
this
more
straightforward,
a
simpler
implementation
for
you.
That's
certainly
something
we're
looking
at.
It
is
a
little
bit
convoluted
in
that
you're,
exposing
an
api,
but
never
actually
implementing
one,
but
this
is
the
mechanics
of
how
our
team's,
sso
and
and
the
collaborate
apps
can
move
forward.
B
I
should
mention
that
the
teams
folks
are
also
building
tools.
There's
the
teams
toolkit,
there's
a
teams
sdk,
there's
also
a
teams
toolkit
which
has
got
plugins
that
that
work
with
both
visual
studio
and
visual
studio
code
and
they're
great,
because
they'll
even
do
the
application
registration
for
you,
those
slides.
I
showed
you
about
all
those
various
application
ids
you
had
to
put
in
well.
C
Good
morning,
hey
kyle
and
at
ignite
2019,
you
gave
a
deck,
microsoft,
identity,
platform,
best
practices
for
developers,
and
you
had
a
slide
on
golden
rules
for
tokens,
and
I've
used
this
quite
a
bit
since
then
with
with
customers.
But
two
of
the
golden
rules
were
identity.
Tokens
id
tokens
are
used
for
identification,
authentication,
access
tokens
for
authorization,
and
it
looks
like
right
now,
based
on
what
you
just
described.
B
Not
really
so
there
is
the
rule
that
an
id
token
should
only
be
used
for
identification.
My
biggest
issue
there
is
simply
folks
start
trying
to
use
id
tokens
for
something
else
right,
so
you
know
using
it
instead
of
an
access
token.
The
second
part
of
that
you
know
tokens
should
only
be
used
for
what
their
their
intended
is.
That
access
token.
B
Now
it's
a
little
bit
of
a
skirt
of
the
law
here,
but
the
token
is
being
used
exactly
for
its
intended
purpose,
which
is
allowing
teams
to
access
your
app
right.
So
I
could,
for
example,
provide
a
conditional
access
policy
that,
for
whatever
reason,
didn't
allow
the
user
to
access
your
team's
app
from
inside
of
teams
or
in
fact,
as
we
move
forward
outlook
and
and
so
on,
because
I
am
effectively
at
the
moment
access
you
know
authorizing
that
access.
B
So
the
resource
in
this
case
is
your
team's
application,
so
as
a
resource
it'll
get
an
access
token.
So
as
a
resource,
your
so
again,
it's
a
little
convoluted.
So
we
do
agree
with
that
and
that's
why
we're
looking
to
simplify
this,
but
even
though
this
feels
a
little
different,
I
I
still
feel
it
falls
within
the
golden
rules.
In
this
case,
your
application
is
being
registered
as
a
resource
to
teams
which
it
kind
of
is
right.
B
It
is
something
that
teams
is
making
a
call
to
in
order
to
tell
you
who
the
user
is,
and
the
access
in
this
case
is
simply
I'm
going
to
go
ahead
and
work
there.
But
I
agree
that
we
we're
going
to
tighten
this
up
as
we
look
at
how
we
can
clean
this
up,
moving
forward
to
make
it
a
little
clearer
so
that
we're
not
doing
this,
I'm
getting
an
access
token,
my
team's
application.
B
Yes,
it
allows
me
to
do
conditional
access
and
and
treat
my
application
as
a
resource,
but
in
the
end
my
application
was
only
trying
to
find
out
who
the
user
was.
So
that
probably
would
have
been
better
served
by
an
id
token,
but
I
will
admit
it's
a
fine
splitting
of
the
the
hair
of
that
best
best
practices.
If
you
will.
D
B
B
In
this
case,
my
app
may
never
get
id
tokens
because
if
I'm
just
running
inside
of
teams-
and
I
just
want
to
authenticate
the
user
I'll-
get
that
through
teams
sso
so
I'll
get
that
access
token
only,
but
I
would
still
need
to
register
any
apis
that
I
do
intend
to
call
from
inside
of
that
on
behalf
of
flow
or
if
I
went
to
get
at
the
token,
because
I
don't
have
a
secure
backend,
then
so,
for
example,
if
I
don't
have
a
secure
backend,
I
have
to
register
the
proper
authentication
flow.
In
this
case.
B
C
B
A
Okay,
if
we
do
not
have
any
questions,
then
thanks
a
lot
kyle.
It
was
a
great
session.
We
have
recorded
this
call
and
this
will
be
out
on
our
youtube
channel.
We
will
be
sending
out
a
note.
One
thing
I
want
to
point
out:
our
dial
in
info
has
changed.
As
you
see,
the
old
invites
are
not
working,
you
will
have
to
re-download
the
invite.
Please
go
ahead
and
re-download
the
invite
I'll
be
putting
the
new
invite
in
the
chat.
The
next
call
is
scheduled
on
july.
21..