►
From YouTube: Microsoft Teams developer community call-February 2020
Description
In this month's call, Loki Meyburg, Program Manager for Microsoft Teams discusses single sign-on (SS0) in Microsoft Teams, including:
-What is single sign-on (SSO)
-Authentication in 2019
-Single sign-on for Teams tabs today!
-Getting starting with SSO
More about today’s topics:
https://aka.ms/teams-sso
https://aka.ms/teams-sso-sample
https://myapplications.microsoft.com/
Deck from the community call can be viewed here - https://www.slideshare.net/OfficeDev/microsoft-teams-community-call-february-2020
A
Good
morning,
good
evening,
everyone
thanks
for
joining
I
know
it
can
be
early
or
late,
depending
over
you're.
Joining
from
thank
you
for
coming
today
to
listen
to
another
teams,
developer
community
call.
My
name
is
Loki,
may
Berg
I'm
one
of
the
platform
PM's
on
the
platform
team
of
myself
teams,
I'm
working
on
single
sign-on
for
the
last
few
months,
so
I'm
super
excited
to
show
this
off
to
everyone
on
the
call
and
then
leave
everyone
with
some
resources
so
that
everyone
can
get
started
so
just
quickly.
What
are
we
going
to
talk
about
today?
A
I'm
also
gonna
take
a
little
trip
down
memory
lane
to
just
about
two
months
ago,
and
we
can
talk
a
little
bit
about
how
authentication
worked
inside
of
teams
and
last
year
or
up
until
this
point,
and
we
can
talk
a
little
bit
about
some
of
the
problems
that
developers
and
users
are
experiencing
with
our
current
solution
and
then
finally,
third
bullet
point.
The
one
that
we're
all
here
for
today
is
I'm.
Gonna
talk
a
little
bit
about
single
sign-on.
A
What
the
story
is
today
and
how
you
can
basically
get
started
and
I'm
gonna
run
you
through
a
sample
application
at
the
end.
I
have
made
sacrifices
to
the
demo
gods
this
morning,
so
we're
gonna
try
to
do
a
live
demo
and
the
demo
is
basically
going
to
take
you
through
our
sample
code,
how
to
set
it
up
how
to
register
your
application
with
Azure
ad
and
basically
start
kicking
the
tires
and
then
at
the
end,
I'm
gonna,
just
open
it
up
for
some
Q&A.
So
about
me
my
name
is
Loki
main
burg.
A
You
can
follow
me
on
twitter
at
loki,
maybre
and
yeah
I'm
on
the
platform
team
I
spent
a
lot
of
time
talking
to
developers
and
thinking
about
how
we
can
improve
our
development
story
at
Microsoft
teams
on
the
platform
team
at
Microsoft
teams,
specifically
I
own,
the
tabs
capability
of
apps,
so
apps
at
Microsoft
teams
are
divided
up
into
different
capabilities.
They
range
from
box
to
messaging
extensions
and
then
the
one
that
we're
gonna
be
talking
about
today
is
tabs.
A
Another
word
we
use
for
tabs
is
hosted
experiences,
so
that
is
whenever
you
want
to
host
your
app
experience
inside
of
teams.
So
let's
talk
about
what's
new
for
developers
today.
So
today,
as
your
eighty
single
sign-on
is
supported
for
teams
tabs,
we
are
in
Developer
Preview.
Although
I
think
by
the
time
that
this
video
gets
put
onto
YouTube,
we
might
actually
have
the
feature
generally
available
for
everyone.
So
what
is
single
sign-on?
It
lets
you
basically
sign
in
your
users,
with
the
same
account
that
they're
using
in
teams.
A
So
the
experience
today
is
that
there's
no
way
for
you
to
use
the
same
identity
that
the
user
is
using
when
they've
signed
into
teams
and
oftentimes
the
user
is,
then
you
know
they
they
get
shown
a
sign-in
screen,
thankfully,
with
SSO
users
never
have
to
sign
in
again
no
more
fumbling
around
for
your
password.
The
best
part
I
think
about
this
feature
is
no
more
sign-in
on
mobile,
which
is
a
huge
pain.
A
So
if
you
ever
have
to
do
it,
you
you're
trying
to
type
in
with
your
little
stubby
five
fingers
and
you're
making
mistakes.
You
don't
have
to
do
that
anymore.
Sign-In
is
taken
care
of
and
then
I
think
the
one
that's
that's
most
exciting
for
developers
is
the
development
experience
is
greatly
improved
when
it
comes
to
single
sign-on.
It
really
is
the
the
recommended
approach
moving
forward
for
developers
whenever
they
think
about
authentication
or
building
authentication
into
their
application.
A
Let's
talk
about
SSO,
so
little
trip
down
memory
lane.
Let's
look
at
what
the
story
was
like
last
year,
so
we
we've
always
supported
the
authentication
where
developers
inside
of
Microsoft
teams,
but
the
the
biggest
constraint
I
would
say
was
that
all
of
our
authentication
was
cookie
based.
So
one
of
the
good
things
about
cookie
based
authentication
is
it's
well
understood,
it's
often
implemented
already
and
a
lot
of
the
applications
today
or
the
web
applications
today,
but
along
with
cookie
based
authentication,
you
get
the
usual
caveats.
Cookies
expire
cookies.
A
Don't
move
from
your
browser
to
your
desktop
to
your
mobile
device,
so
just
because
you're
sign-in
on
teams
in
the
desktop
client
doesn't
mean
you're
necessarily
gonna,
be
sign
in
on
your
phone.
We've
supported
this.
This
thing
we
called
its
silent
SSO.
If
you
remember
the
the
old
documentation,
I
think
we
still
call
it
silent
off.
We
kind
of
called
it
foe,
SSO,
it's
still
cookie
based
what
this
provided
us
was
it
provided
us
with
the
ability
to
make
the
user
experience
better,
but
I
don't
know
if
it
necessarily
improved
the
developer.
A
Experience
silent
off
basically
allowed
a
azure
ad
application
inside
of
teams
the
ability
to
quickly
pop
up
a
sign
in
sign
up
window.
Do
the
auth
exchange
drops
a
cookie,
and
then
it
quickly
closes
the
window
so
from
the
user's
experience
what
they
would
have
seen
was
they
go
to
your
application,
they're
not
signed
in?
Sometimes
they
have
to
click
a
button.
You
could
invoke
that
yourself.
Then
the
user
is
presented
with
a
quick
little
pop-up
window.
A
The
window
appears
for
maybe
one
to
two
two,
maybe
three
seconds
and
then
the
windows
closed
down
and
and
and
all
of
that
exchanged
it
was
generated
a
tenth
occasion
hooky
for
the
user.
We
have
a
really
good
sample
code
available.
For
this.
My
opinion
is:
is
that
it's
quite
heavy-handed
for
a
developer
to
get
silent,
authentication
working
tried
it
out.
A
few
weeks
ago
and
I
remember
it
being
quite
cumbersome
to
get
working
properly
and
the
in
the
experience
to
the
end
user
was
just
a
small
little
improvement
for
quite
a
lot
of
work.
A
I
think
you
know,
all
of
this
can
be
summed
up.
As
you
know,
we
listen
to
our
developers
quite
a
lot.
We
talk
to
our
MVPs
talk
to
them
at
conferences.
Authentication
is
definitely
one
of
the
top
top
top,
maybe
top
three
complaints
we
hear
from
developers
all
the
time
is
that
not
only
is
authentication
difficult
to
get
working
properly,
but
once
you
get
it
working
the
experience
to
the
end
user
is
still.
A
You
know
it's
it's
it's
not
it's
a
little
lackluster,
it's
not
the
best
experience
to
the
end
user,
so
you
know
for
the
visual
people
out
there.
This
is
kind
of
what
the
experience
would
look
like
to
the
user.
The
user
comes
in,
they
see
the
Start
screen,
they
click
Sign,
In
they're
then
asked
to
consent
and
provide
permission
for
that
access
and
then
they're
signed
in
now.
That
experience
seems
fine.
That
experience
has
to
change
too
much
with
SSO,
but
really
it's
the
some
time
later
part
of
the
slide
that
really
sucks
for
users.
A
A
Either
teams
just
toss
the
cookie
out
and
you
have
to
generate
a
new
cookie
or
the
cookie
expired,
and
this
application
hadn't
done
anything
to
get
a
new
cookie
generated
for
the
user,
and
then
you
know,
as
for
some
of
the
developers,
who've
been
following,
you
know:
we've
only
rolling
out
apps
onto
mobile
and
for
any
developers
who
are
serving
users
who
are
mobile.
First,
this
experience
is
just
terrible.
A
So
not
only
are
they
signing
on
a
desktop
that
are
not
sign-in
on
their
phone,
they
have
to
then
go
back
to
their
phone
sign
in
again,
and
you
can
imagine
fumbling
through
your
username,
your
password.
If
you
have
two-factor
authentication,
you
have
to
go
through
that
additional
step
as
well,
and
then
sure
enough
that
that
person
is
going
to
come
back
to
their
phone
in
a
few
days,
go
back
to
their
favorite
app
and
they're
gonna
find
that
they're
no
longer
sign-in.
So
all
in
all
it's
a
passable
solution.
A
It
wasn't
great,
it's
definitely
something
that
we
wanted
to
improve,
and
so
I
guess,
yeah
we've
heard
loud
and
clear.
Single
sign-on
couldn't
come
fast
enough,
you're
working
on
it
in
conjunction
with
the
azure
ad
team,
to
provide
you
guys
with
a
solution
that
not
only
makes
this
whole
experience
better.
It
improves
it
predominantly.
This
experience
here
is
greatly
improved
and
the
developer
experience
is
improved
too.
Let's
just
look
through
some,
you
know
what
would
be
the
common
needs
of
the
personas
for
a
single
sign-on.
A
Well,
for
the
end
user
is
pretty
simple:
they
just
want
to
skip
sign-in.
They
don't
want
to
do
it
anymore,
they've
already
signed
into
teams.
Why
do
they
have
to
sign
into
their
app
as
well?
And
why
do
they
have
to
keep
doing
it
over
and
over
and
over
again?
The
chief
complaint
of
Ella
pers
is
building.
Authentication
is
just
a
terribly
difficult
ordeal
to
go
through.
It's
really
difficult
to
get
right.
It's
very
brittle
anything
that
we
can
do
to
improve
the
developer.
Experience
would
be
great
from
IT
admins.
A
We
hear
a
lot
of
complaints
around
conditional
access
policies
so
specifically
I'm
talking
about
conditional
access
policies
that
are
device
specific.
So
if,
if
users
are
only
allowed
to
access
an
app
through
a
specific
device
or
their
device
has
to
be
domain,
joined
or
Intune
enrolled,
our
current
solution
today
gets
you
some
of
the
conditional
access
policies,
but
on
all
of
them.
So
you
know
we
hear
frequently
from
IT
admins
that
they
won't.
They
just
want
better
security
controls
over
the
line
of
business
applications
that
run
inside
of
teams,
so
incomes
teams
and
Azure
ad.
A
This
is
kind
of
being
a
partnership
between
the
two
orgs
of
Microsoft
to
provide
you
guys
with
an
SSO
solutions.
So
what
that
looks
like
today
is
that
developers
are
able
to
build
a
fend
occation
using
Azure
ad
as
a
bonus
they're
going
to
get
faster
load
times
as
well.
Someone
is
the
user
clicks
on
the
application
and
they
navigate
to
that
tab
before
the
tab
is
finished.
Loading
we've
already
gone
to
Azure
ad
and
asked
them
to
give
us
an
authentication
token.
A
A
It's
going
to
be
a
little
slow,
the
very
first
time
you
access
a
brand
new
application,
but
those
cookies,
those
tokens
are
cached,
so
we're
gonna
be
providing
it
to
you
right
off
right
from
cash
and
we're
gonna
be
getting
that
token
before
they
use
it
even
before
the
tab
is
even
finished,
loading
much
easier
development,
it's
only
about
five,
maybe
seven
lines
of
code
for
basic
authentication.
It
works
on
desktop
and
mobile,
and
finally,
it
supports
all
the
conditional
access
policies
as
well.
A
So,
finally,
what
that
experience
is
looks
like
is
that
the
user
only
has
to
consent
once
so.
Here
you
you're
seeing
the
sample
that
I'm
gonna
run
you
through.
We
present
you
with
a
nice
color,
the
speedbump
page,
just
to
let
the
user
know
that
they're
almost
there,
they
just
have
to
click.
Continue.
We
pop
up
a
window,
the
user
consents
once
to
these
permissions
and
that's
it.
The
user
won't
have
to
consent
ever
again.
Every
time
the
user
comes
back
to
this
tab,
they're
going
to
be
automatically
signed
in.
A
Let's
just
quickly
take
a
look
at
that.
We've
got
my
lovely
sample,
app
called
task
now,
which
is
one
of
the
little
sample
apps
that
me
and
my
team
work
on
quite
frequently
when
go
to
my
tasks
and
give
it
a
second
and
there
you
go.
This
is
the
first
experience.
You're
gonna
see
you're
basically
being
asked
for
consent,
and
that's
it.
That's
the
the
consent,
experience
I'm,
gonna,
just
quickly,
consent
to
this
and
accept
and
you'll
see
it's
just
asking
for
basic
profile
information.
A
An
Ebola
now
I'm
signing
to
you
into
the
application.
What
I'm
gonna
do
is
I'm
gonna
go
to
my
planner
and
a
half
I'm
gonna
go
back
to
task.
Meow
I,
go
to
my
tasks
and
voila.
You
see
I'm
instantly
in
I.
Didn't
have
to
do
anything
extra
after
that
step.
Just
one
more
time,
quick,
I'm
gonna
go
to
chat
back
to
the
box
back
to
the
app
and
voila
I
mean
instantly.
It's
a
it's
a
really
really
nice
experience.
A
Now,
if
I
were
to
go
and
use
tasks
me
out
on
my
phone,
because
I've
already
consented
on
my
desktop
machine
I'm,
going
to
get
the
exact
same
experience,
I'm
gonna
be
immediately
signed
in
I'm,
not
going
to
see
that
consent
screen,
because
I've
already
consented
once
for
tasks
me
out
to
have
access
to
my
email,
address
and
name
and
then
also
for
tasks
now
to
get
a
authentication
token.
For
me,
one
of
the
other
things
as
well
that
I
just
want
to
talk
about
you'll
see
this
task.
Vo
needs
your
consent.
A
In
order
to
do
this
work,
the
first
part
of
the
experience
where
I
consented
and
I
was
able
to
sign
in
that's
for
an
authentication,
so
the
solution
that
I'm
gonna
be
showing
you
today
is
great
for
authentication.
It's
not
so
good
for
authorization.
So
we
can
authorize
you
for
some
very
basic
permissions
enough
to
authenticate
the
user.
If
you
want
additional
permissions
in
this
case,
what
with
this-
but
this
is
going
to
ask
for-
is
it
just
wants
permission
at
to
show
my
profile
photo?
A
If
you
want
access
to
the
profile
to
the
users
profile
photo
or
you
want
access
to
the
users,
mail
or
calendar
or
any
of
those
other
graph
scopes,
you
are
going
to
have
to
do
a
little
bit
of
extra
work.
Well,
it's
the
same
work
you
would
have
done
before,
but
you
need
to
then
present
another
screen
to
the
user,
and
then
in
this
screen
there
they're
gonna,
say
hey
this
app
wants
access
to
you
to
mail
or
to
calendar,
or
in
this
case
your
profile
photo
now.
A
Most
applications
will
find
that
or
most
of
their
needs
authentication
is
exactly
what
they
want.
They
just
want
to
attenti
kate,
the
user
get
a
token
get
them
in
and
then
once
they
were
attenti
cated.
You
know
they
handle
all
of
the
UI
and
the
rest
of
the
experience
from
there.
So
that'll
be
fine
for
them.
Now
there
are
some
other
applications
that
do
you
need
access
to
calendar
or
May
read
some
of
these
other
graphs
copes
most
of
those
applications.
A
We've
found
our
line
of
business
applications
and
you
can
actually
circumvent
all
of
that
by
having
a
tenant
admin.
Just
pre
approve
the
application,
especially
if
it's
a
line
of
business
app,
just
pre
approve
the
app
and
then
that
that
experience
that
that
I
just
went
through
you
you're,
never
gonna
have
to
do
that.
Experience
to
your
users,
because
your
users
will
already
be
pre
consented.
A
So
you
here
you
see
my
profile
photo
just
showed
up,
so
those
users
will
just
those
users
will
be
pre
consented
for
those
permissions,
but
in
the
very,
very
rare
chance
that
you're
looking
at
ship
an
application
and
you
don't
want
tenant
admin
consent.
In
other
words,
it's
not
a
line
of
business
application
and
you
want
access
to
calendar
or
mail
dot
read
you
know
we
do
provide
you
with
the
workaround
on
how
to
get
those
permissions.
So
you
know
you
just
saw
in
this
example.
A
I
didn't
have
my
profile
photo
at
first
and
that
second
flow
was
for
me
to
just
get
my
profile
photo
so
again
for
for
authentication,
SSO
is
fantastic
for
authorization.
We
could
be
doing
a
little
bit
of
improvement
in
the
authentication
experience.
However,
I'm
gonna
walk
you
through
what
that
workaround
looks
like
it's
very
similar
to
what
we
already
do
today
or
recommend
for
users
today.
So
let's
just
quickly
talk
about
the
song
and
dance
for
anyone
who's
familiar
with
OAuth
that
you
should
be
pretty
familiar
with
this
experience.
A
The
what's
not
shown
in
this
in
this
diagram
is,
is
that
the
tab
app
has
to
go
into
Azure
ad
and
approve
the
team's
app
as
a
trusted
client
to
get
a
token
essentially
on
their
behalf.
So
the
tab
app
is
gonna.
Ask
teams,
say:
teams,
hey,
please,
can
you
go
get
me
a
token
teams
is
then
gonna
go
and
probably
have
to
consent
at
first
right,
so
the
user
hasn't
consented,
and
so
that's
going
to
be.
A
The
first
experience
is,
the
user
has
to
consent
once
the
users
consented
and
the
tab
app
asks
team's
app
for
a
token
teams
is
gonna,
go
just
straight
to
Azure
ad,
it's
gonna
get
the
token
from
Azure
ad
return,
it
back
to
teams,
and
then
we
are
gonna
pass
that
back
to
you.
That
token,
in
this
exchange
is
going
to
be
your
authentication
token,
it's
going
to
come
with
your
with
email
address
and
a
token
you
can
use
to
authenticate
that
user.
A
If
you
need
additional
graph
permissions,
this
is
for
the
authorization
part
of
the
experience.
It's
going
to
be
your
responsibility
to
take
that
token,
that
we
passed
back
to
you
and
pass
it
back
to
your
server
and
do
something
called
an
on
behalf
of
exchange,
basically
you're
going
to
exchange
that
token
server-side
for
additional
graph
permissions.
A
And
if
you
remember
back
to
the
example
that
I
just
showed
you,
if
you
try
to
go
and
exchange
it
and
ad
says
none
other,
that
the
user
hasn't
consented
yet
to
say,
mail
access
or
to
the
avatar
photo
your
server
side.
App
should
tell
your
client
app
to
you,
know
present
a
little
banner
to
the
user
and
say
hey.
We
just
need
some
further
permissions
before
you
can
fully
use
the
application.
A
So,
let's
just
quickly
talk
about
some
of
the
steps
that
you
would
go
through.
One
of
the
first
steps
is
you're
going
to
have
to
go
to
Azure,
ad
and
you're,
going
to
go
to
the
app
registration
portal
and
just
register
your
application
in
that
register.
Registration
experience
you're
going
to
register
your
app.
You
know
the
example
and
I'm
gonna
show
you
is
going
to
be
the
full
registered
application
type
where
it'll
accept
any
ad
user,
as
well
as
anyone
using
a
consumer
Microsoft
account.
A
However,
there,
for
those
of
you
familiar
SSO,
does
work
with
the
other
two
options
as
well,
once
you're
done
that
you're
gonna
get
an
app
ID
store
that
somewhere,
because
you're
gonna
need
that
when
you
come
back
to
teams,
you
need
to
expose
an
API.
So
we
need
to
have
some
API
that
we
can
talk
to
your
application
or
and
the
way
that
that
works
is
you're.
A
Gonna
have
to
put
your
fully
qualified
domain
name
and
your
app
ID,
like
you
got
in
this
step
here,
oh
and
you
need
at
escape
so
it'll,
be
your
fully
qualified
that
my
name
slash
whatever
your
app
ID
is
slash
accesses
user,
that's
gonna,
be
your
scope.
Finally,
you
want
to
just
authorize
the
team's
application.
We
have
two
apps
or
two
app
IDs.
We
have
the
client
ID
for
the
desktop
and
mobile
apps,
and
then
we
also
have
another
client
ID
for
the
actual
team's
web
app.
A
So
you
need
a
towel
as
your
ad
that
you
give
team's
permission
to
get
a
token
for
your
application
back
into
teams
with
those
properties
that
you
got
from
the
first
step.
You
need
to
go
and
update
your
manifest
in
the
manifest
we
provide
a
property
called
the
web
application
info
section
and
in
here,
is
where
you're
going.
To
put
all
of
your.
You
know
your
web
app
information
that
you
got
from
as
your
ad.
The
first
one
is
going
to
be
your
app
ID
and
then
the
second
one
is
going
to
be
the
resource.
A
So
if
I'm
going
to
go
back
to
the
previous
slide,
this
whole
piece
here
is
going
to
be
your
resource.
That
tells
us
where
you
know
what
resources
we're
gonna
be
asking
permission
for,
and
that
has
to
go
here.
I'll
show
you
how
to
do
that
and
then.
Finally,
from
a
developer
perspective,
it's
quite
nice!
Actually,
you
you
just
call,
you
just
call
get
off
token
and
we
have
a
success
and
a
failure
call
back
and
that's
that's
it
for
the
most
part.
Actually,
that's
a
that'll
give
you
a
token.
A
The
tricky
part
is
going
to
be.
If
you
get
the
token
back
and
you
want
to
do
more
stuff
with
that
token,
so
I'll
show
you
how
how
you
can
do
more
stuff
with
that
token,
as
well,
but
yeah.
Basically
this
this
will
be
the
development
experience
for
a
developer.
It's
quite
nice,
it's
much
simpler,
and
that
gives
you
a
token
that
you
can
use
right
away
and
we'll
we'll
take
care
of
this
UI
experience
for
you
as
well.
So
you
don't
have
to
you.
Don't
have
to
do
that
so
yeah,
let's
quickly.
A
B
A
B
B
A
B
A
A
A
A
good
question
authorization
consent
is
done
once
it's,
the
cache
is
a
maybe
a
misnomer
here.
Essentially
what's
happening.
Is
we're
writing
a
record
of
consent
to
Azure
ad?
That
record
of
consent
basically,
is
a
record
stating
that
the
user
has
consented
and
therefore
the
user
will
never
have
to
consent
for
those
permissions
again
now,
if
you
change
those
permissions,
the
user
is
going
to
have
to
consent
again
because
those
permissions
are
different,
but
as
long
as
you
keep
the
permissions
the
same,
the
user
won't
have
to
consent
a
second
time
and.
B
Then
just
we'll
do
a
couple
more
and
then
we'll
move
on
to
the
demo
and
then
just
and
then
we
can
answer
some
more
questions
so
I
have
ohed.
Does
anyone
ever
notice
that
if
you
make
a
team's
app
and
you
load
a
website
into
a
tab
within
the
app,
not
adding
a
site
tab
to
a
team
SSO
fails
to
load
properly
as
an.
A
A
Is
a
really
really
good
question
in
and
as
I'm
hearing
the
question
I'm
I'm
realizing
I,
probably
should've
at
all,
in
a
slide
about
that,
because,
yes,
that
is
a
really
big
problem
today,
when
you
just
you
just
load
a
website,
and
you
expect
it
to
work
the
same
way
that
it
would
if
it
were
just
a
browser
tab
and
unfortunately,
this
solution
does
not
address
that
problem
or
that
yeah
it
doesn't.
It
doesn't
address
that
problem
so
for
those
of
you
on
the
call
run
familiar
with
it.
A
If
I
go
and
take
a
regular
website,
let's
say
it's:
Pinterest
comm
and
I,
just
I
just
load
Pinterest
comm
as
a
tab.
Maybe
I
go
and
create
my
own
manifest
and
I
just
take
the
Pinterest
comm
you
are
and
I
put
it
right
in
will
this
solution
mean
that
I
don't
have
to
sign
in
to
to
Pinterest
pretend
Pinterest
had
as
your
ad
support
and
they
not
just
use
my
as
your
ad
account.
The
answer
to
that,
unfortunately
is
no.
A
The
reason
for
that
is
is
that
Pinterest
has
to
do
work
to
integrate
with
our
SDK.
So,
there's
no
guarantee
that
Pinterest
is
use
their
SDK
to
get
a
token,
and
secondly,
if
you're
just
doing
this
as
a
generic
website
tab,
in
other
words,
you're,
not
building
a
custom
app,
we
are
actually
not
allowed
to
communicate
with
that
website
for
both
security
and
privacy
reasons.
A
So
when
you
use
the
website
tab,
that
will
always
be
a
really
funky
sign-in
experience
where
your
sign-in
cookie
is
only
really
remembered
for
the
session,
for
while
you
have
teams
open.
So
no
the
this
solution
that
I'm
talking
about
is
not
about
generic
website
tabs
or
specifically,
websites
that
you
do
not
own.
What
I'm
talking
about
today
is
for
applications
that
you're
developing
they
you
own.
We
can
provide
you
with
a
better
authentication
story
for
your
users,
so
that
was
a
really
good
question.
That's.
B
A
A
Good
question,
unfortunately,
not
so
this
single
sign-on
solution,
I,
guess
this
is
kind
of
jumping
to
one
of
my
last
slides,
which
talks
a
little
bit
about
constraints.
This
single
sign-on
solution
is
just
with
Azure
ad.
This
is
not
for
other
providers
like
Google
or
Facebook.
This
is
just
about
as
your
ad
SS,
oh
okay,.
B
B
A
So,
let's
get
started
with
a
demo
actually
before
I
start
just
you
know
some
of
some
of
the
resources
I'm
going
to
be
using.
These
are
the
actual.
These
are
the
docs
that
I
will
be
referencing
from
time
to
time.
These
are
our
SSO
Docs
and
then
this
is
just
the
sample
that
I
will
be
using.
So
for
those
of
you
are
unfamiliar.
We
have
documentation
on
how
to
use
SSO
and
I'll
be
coming
back
to
this
page
a
few
times
just
to
get
some
of
this
information.
A
While
we're
setting
this
up
so
yeah,
let's
go.
Let's
get
started
with
the
demo
one
of
the
first
things
before
we
get
started
just
a
little
bit
of
housekeeping
in
order
for
you
to
do
any
kind
of
local
development
when
it
comes
to
authentication
you're
going
to
need
to
publicly
expose
URL.
So,
unfortunately,
localhost
is
not
going
to
work.
We
recommend
that
developers
sign
up
for
and
rock
and
rock
is
a
local
tunneling
service
and
it'll.
A
Give
you
a
public
domain
name
that
you
can
use
for
this
type
of
testing,
so
for
today's
demo,
I've
gone
and
created
contoso
or
contoso
auth
and
graph
dot,
dot,
IO,
so
I'm
just
going
to
take
this
and
I'm
gonna.
Just
save
us
up
here.
We're
gonna
we're
gonna!
Just
come
back
to
this
little
document
here,
as
we
were
collecting
information
as
we
go
so
first
things.
First,
let's
just
go
back
to
the
home
screen
you're
wanting
to
go
to
as
your
active
directory,
and
you
want
to
go
to
app
registrations.
A
New
app
contoso
team's
off
and
we're
gonna
choose
the
most
feature,
full
account
type
and
over
here
we're
going
to
just
put
our
and
Rock
accounts
by
the
way.
All
of
these
steps
are
pretty
well
documented
in
the
actual
sample
itself.
So
if
you
go
look
at
the
sample,
all
of
the
steps
that
I'm
going
through
are
pretty
well
documented.
You
just
follow
those
steps
in
the
readme,
and
that
should
be
enough.
Let
me
just
double
check
this
URL
off
and
off-off
end
it
perfect.
A
So
yeah
you
see
the
center
redirect
your
URI,
you
don't
have
to
do
it
in
this
step.
You
can
always
do
it
in
in
the
next
step.
This
is
the
the
URL
that,
as
your
ad
will
redirect
to
you
after
the
user
has
authenticated.
So
one
of
the
first
things
want
to
do
is
just
copy.
Your
app
ID
over
here
got
the
app
ID
and,
let's
just
go
through
each
of
these
little
little
ones
down.
Here
we
can
skip
branding.
A
Let's
go
straight
to
do
authentication
so
we've
already
set
our
redirect
URI
make
sure
to
set
implicit
grant
to
both
access
tokens
and
ID
tokens.
Save
that
certificates
and
secrets,
you
don't
need
to
do
this
step
if
all
we
were
looking
for
is
just
to
authenticate
the
user.
But
if
you
want
to
do
additional
authorization,
workflows
like
getting
access
to
that
to
the
users
calendar
or
the
users,
mail,
you're
gonna
need
a
secret
for
this
little
step.
So
this
team's
developer
community
call
secret.
A
A
Now
we're
gonna
give
you
access
to
a
few
of
these
and
then
I've
included
one
extra
one
to
get
the
user's
profile
photo.
You'll
see
what
that
looks
like
in
this
sample
an
expose,
an
API,
I'm
gonna,
add
a
scope.
Okay,
so
let's
not
screw
this
part
up.
Let's
go
here
this
slash!
So
if
you
remember
back
to
my
slides,
you
always
want
to
put
your
fully
qualified
domain
name
out
here
and
I.
Think
that's
gonna,
be
my
application.
A
A
And
make
sure
that
it's
enabled
so
add
the
scope,
so
this
is
going
to
be
the
endpoint
that
we're
going
to
be
pinging
to
get
access
to
some
of
those
permissions
that
we
configured
in
the
previous
step.
Okay,
so
all
of
this
is
fine
and
dandy,
but
we
need
a
laser
that
we
are
going
to
give
permission
to
the
team's
applications.
A
B
A
Great
and
that's
it
I
think
as
far
as
setting
up
your
as
your
ad
app
was
concerned,
so
just
to
recap
make
sure
you
have
a
redirect
URI
set
up
and
you've
enabled
these
two
implicit
grant
checkboxes
make
sure
you've
generated
a
secret
copy
paste
that
secret
somewhere
into
a
file
because
you're
gonna
need
it
again.
If
you
have
permissions
and
they
will
set
all
of
the
graphs
scopes
that
you
want
access
to
over
here,
the
ones
that
I
picked
for
this
demo
is
email,
offline
access,
open,
ID
profile
and
user
data
feed.
A
A
So
now
with
all
of
that
information,
first
thing
we
want
to
do
is
go
to
the
manifest
and
in
the
manifest
everywhere,
where
it
says,
angriff
subdomain.
Remember:
that's
the
subdomain!
You
got
from
end
rock
over
here
little
subdomains
and
I-I-I
just
set
up
for
this
demo
I'm,
going
to
replace
that
with
the
subdomain.
That
I've
got,
which
is
yep
place
all
and
then
go
all
the
way
down
to
the
web
application
info
section
and
take
your
app
ID,
which
you
got
here
in
this
step
and
just
set
your
app
ID
and.
B
A
Over
here,
okay
thing:
you
need
to
get
set
up
for
your
manifest,
but
there's
one
more
file
in
the
sample
where
we
have
some
environment
variables
that
we
need
a
set
and
I'm
just
going
to
set
my
app
ID
here
and
then.
Finally,
we
have
that
secret
that
we
generated
that
I'm
gonna
just
take
here
and
throw
into
here.
A
Now
fingers
crossed
first
thing
we
want
to
do.
Is
we
want
to
start
up
and
rock
so
you'll
notice,
that
for
in
Gronk,
what
I'm
doing
is
a
binding
to
port
33,
33
and
I'm
binding
to
the
subdomain
contoso
off,
which
is
that
subdomain
that
I
set
up
in
the
very
beginning
and
that's
going
to
set
up
a
local
tunnel
for
me,
the
next
thing
you
want
to
do
is
just
make
sure
you
run
gulp
generate
manifest.
A
This
is
going
to
take
all
of
this
manifest
changes
that
you
made,
and
it's
just
gonna
bundle
them
into
this
little
zip
file
that
we're
gonna
upload,
two
teams-
perfect,
okay,
I
said
we
want
to
do.
Is
we
want
to
go
two
teams?
Let's
see
where
is
it
here?
I'm
gonna
go
to
the
app
store,
upload,
a
custom
app
for
myself.
Oh,
that's
that
manifest
that
we
just
created
upload,
add
and
this
shouldn't
work
because
I
haven't
started
the
server
yet,
but
let's
see
if
we
get
the
end
rock
inner
page
perfect.
A
A
Okay,
so
in
this
little
sample,
there's
a
bunch
of
debug
code,
that'll
get
spat
out,
and
one
of
the
first
things
we're
gonna
do
is
we're
gonna
call
that
get
off
token
call
and
present
a
user
with
a
little
speed
bump
page
just
letting
them
know
that
hey
in
the
next
step,
we're
gonna
ask
you
for
permission.
Part
of
the
reason
we
decided
to
do
this
step
was
before
we
have
this
step.
A
What
what
happened
is
the
app
of
called
get
off
token,
and
if
the
user
hadn't
consented,
the
app
would
just
pop
open
a
consent
screen
for
the
user.
So
not
only
is
that
scary,
sometimes
because
if
you've
seen
the
ad
consent
screen,
it
could
be
quite
formal,
but
also
we
notice
that
a
lot
of
users
would
end
up
not
being
able
to
find
the
window,
because
the
winner
would
just
pop
up
on
some
random
screen
somewhere.
So
this
is
a
nice
way
to
let
the
user
know.
A
You
know
once
you
could
continue,
something's
gonna
happen
and
you're
probably
gonna
have
to
consent.
So
let's
do
this
quick
and
wait
for
the
consent
screen
to
pop
up
okay,
so
asking
for
some
basic
info
and
role
lot
I'm
in
so,
let's
just
pause
here
for
a
second
that
was
the
entire
step
for
the
user
to
be
able
to
authenticate
the
user,
and
this
is
the
token
that
we
got
back.
Let's
just
explode
this
token
open
inside
of
by
the
way.
A
This
is
great,
URL,
JWT
IO,
if
you
want
to
just
take
a
peek
at
your
tokens,
so
I
just
copied
and
pasted
the
token
out
there.
It's
gonna
decode
the
token
for
me,
and
in
here
you
can
see
you
see
my
name
see
my
email
address.
You
can
see
that
scope
that
we
were
asking
for
access
as
user
and
so
yeah.
So
this
this
token
here
is
all
that
you're
going
to
need
to
authenticate
the
user
now
for
most
apps.
A
That's
all
you
need
you
just
needed
to
go
through
that
little
experience
get
this
token
and
that'll
be
all
you
need
to
authenticate
the
user,
and
that
would
be
it.
That's
that
would
be
me
closing
up
the
demo
saying
SSO
is
done.
However,
we
do
know
that
other
developers
want
access
to
additional
graph
scopes.
A
So,
if
I
go
back
to
here,
if
I
were
to
go
to
API
permissions
and
I
wanted
access
to
more
stuff,
like
I
really
wanted
access
to
the
users,
mail
I,
you
know,
I
might
want
to
be
able
to
I
might
want
access
to
mail
dot
read/write.
So
how
can
I
take
this
token
and
exchange
it
so
that
I
can
get
access
to
these
elevated
permissions?
Well
in
the
sample
we
once
we
notice
that
that
happens.
We
then
show
this
grant
for
the
permissions
button
in
your
UI
it'll
be
very
similar
to
that
task.
A
Meow
example
that
I
showed
earlier,
you
just
put
a
soft
banner
into
your
application.
That
says:
hey.
We
need
additional
permissions
from
you
once
you've
grant
these
for
the
permissions.
The
screen
is
gonna.
Ask
for
those
additional
permissions
I'm
going
to
accept,
and
here
I
get
a
much
more
complete
token
back.
That
now
gives
me
access
in
this
case,
to
the
users
profile
photo
I
know,
there's
a
pretty
contrived
example,
but
you
can
imagine
that
this
token
can
also
give
you
a
librated
permissions
for
mail
access
or
calendar
access.
A
Please
keep
in
mind
that
most
enterprises
have
actually
blocked
access
to
those
types
of
permissions.
So,
if
that's
the
case
be
sure
to
handle
those
experiences
inside
of
your
UI
or
consider
something
called
a
tenant
admin
consent
where
you
essentially
ask
the
nted
admins
to
pre
consent
that
application
for
all
of
their
users,
let's
just
quickly
go
back
to
chat
and
go
back
to
off
tab.
A
You
see
how
quickly
that
was
for
me
to
authenticate
the
user
I
quickly,
send
the
token
back
for
exchange
and
I
get
back
a
new
token.
The
elevated
permissions.
So
this
one
here
is
gonna,
be
what
90%
of
all
developers
are
going
to
want.
This
is
the
one
that's
going
to
authenticate
the
user
once
I
got
this
token
back
I,
send
it
back
for
exchange
and
I
get
back
another
token.
That
gives
me
much
greater
permission
in
this
case
to
access
the
users
profile
photo.
That's
it!
That's
it
for
the
demo
I
wish.
A
I
could
show
you
guys
the
mobile
experience
for
this,
but
I
hook
up
my
phone
to
be
able
to
show
you
guys.
I
wasn't
able
to
do
that
in
time
this
morning,
but
if
I
were
to
visit
my
authentication
sample
on
my
phone,
all
of
this
will
just
be
taken
care
of
for
me.
I,
don't
I,
don't
see
a
consent
screen
I,
don't
have
to
sign-in
anymore
I'm,
basically
just
automatically
signed
in
and
I.
A
So
in
the
sample
there
is
this
off
J's
file
that
I've
created
the
off
J's
file,
really
the
bulk
of
the
work,
the
one
that
most
people
are
gonna
be
interested
in
is
gonna,
be
this
function
right
here,
get
off
token,
this
one
calls
get
off
token.
It
has
a
success
callback
and
a
failed
all
that
callback.
The
success
callback
in
this
case,
because
I
want
extra
permissions.
A
Most
applications
are
not
going
to
send
their
token
to
the
backend
for
exchange,
but
in
this
case
I
am
and
I've
just
outlined
for
anyone
who's
done
this
before
the
this
should
be
pretty
familiar
I'm,
basically
just
sending
the
token
to
the
backend
for
exchange.
If,
for
whatever
reason,
the
user
hasn't
consented
to
these
additional
permissions,
the
third
step
is
basically
just
to
initialize
a
consent.
Button
in
your
case
it'll
be
a
soft
little
banner
that
tells
the
user
hey.
You
please
consent
to
these
additional
permissions
on
the
actual
server
side.
A
If
you
were
to
do
this,
exchange
work
for
this
step
over
here,
where
you're
doing
the
backend
exchange.
There's
a
file
called
tabs
a
s,
and
you
can
see
what
that
server-side
token
exchange
looks
like
it's
pretty
gnarly,
but
this
basically
will
do
the
exchange
and
get
back
a
elevated
token.
For
you
again,
most
people
will
not
be
worried
about
this
additional
work.
This
first
function
over
here
is
all
that
you're
going
to
need
to
be
able
to
authenticate
your
users
and
that's
it
as
far
as
the
demo
goes.
A
B
A
I
don't
have
to
do
any
of
that
work
so
for
that
SSO
bought
SSO,
we're
actively
working
on
right
now
and
I
can't
really
talk
too
much
about
timelines
or
details.
But
true
bot
SSO
is
something
that
we're
working
on
today.
However,
if
you
wanted
to
use
this
for
some
authentication
experience
for
box,
you
could
have
a
bot
present,
a
card
that
says
sign
in
the
user
click
sign
in
and
when
you
sign
in
that
sign.
A
In
experience
opens
up
this,
it
just
opens
up
this
screen,
and
this
screen
will
be
the
screen
that
handles
all
of
the
token
exchange
for
that
specific
box,
and
you
know
once
you
get
this
token
back,
you
could
pass
this
token
back
to
the
bot.
It's
not
true
bond
SSO,
because
the
user
still
has
to
largely
interact
with
that
experience.
However,
you
could
get
pretty
close
using
this
for
BOTS.
A
B
A
A
It
is
possible,
I
haven't
published
the
sample
yet,
but
you
will
be
calling
notify
success
and
passing
that
token
back.
That
is
correct,
so
I'm,
probably
not
gonna,
find
this
in
time
on
this
call.
So
yeah.
Just
trust
me
on
that.
One
call
notified
its
success
and
then
you
pass
that
token
back
to
the
lot.
B
A
B
A
However,
by
the
end
of
this
month,
fully
rolled
out
on
desktop
but
it'll
only
then
be
in
Developer
Preview
on
move
out,
so
we
will
be
making
a
formal
announcement
to
say:
hey
SSO
is
generally
available,
and
what
that
would
mean
is
that
SSO
is
generally
available
on
both
desktop
and
on
mobile.
But
in
the
interim,
what
we're
going
to
do
is
we're
going
to
fully
roll
this
out
on
desktop
over
the
next
two
to
three
weeks.
A
It'll
be
fully
available
on
desktops
or
your
users
can
use
this
end-to-end
on
desktop
and
then
during
that
rollouts
it'll
then
be
available
as
Developer
Preview
on
mobile.
So,
while
some
of
your
people
can
start
testing
it
on
mobile,
however,
we
don't
expect
it
to
be
fully
release
on
mobile
until
the
end
of
this
quarter.
So.
B
A
B
Okay,
great
and
then
yes,
these
slides
will
be
published,
including
the
recording
and
I'm
posting
the
link
again
to
the
YouTube
channel.
You
can
also
subscribe
to
that
channel
and
you'll
get
updates
to
recordings
that
are
being
posted.
You
can
see.
Other
community
calls,
as
well
as
the
team's
calls
and
there's
training,
videos
and
a
whole
bunch
of
other
stuff
for
developers
on
that
channel.
B
So
I
think
it's
it's
great,
and
then
you
can
also
follow
us
on
our
Microsoft
365
Twitter
handle
and
I'll
put
that
in
the
IM
chat
as
well,
and
that's
where
we
post
all
of
our
announcements
reminders
about
calls
when
recordings
are
available
and
all
you
can
kind
of
get
everything
through
that
as
well.
So
I'll
put
both
of
those
links
in
the
IM
chat
in
just
a
second.
B
A
A
good
question
I'll
have
to
get
back
to
that
person
and
dig
into
that
a
little
bit
more
I
know
that
we're
working
on
something
at
the
moment
on
two
fronts:
to
make
it
so
that
IT
admins
have
a
much
better
experience
when
they're
deploying
applications
throughout
Microsoft
teams,
but
I'm
not
sure
if
that
will
directly
be
the
answer
that
this
person
is
looking
for,
and
it's
also
not
my
area
of
expertise.
So
maybe
we
can.
We
can
follow
up
with
that
person.
Offline,
yep.
B
A
A
However,
I
wouldn't
I
would
imagine
that
thatis
that
that
code
doesn't
change
dramatically
from
the
samples
that
we
have
today
so
I'm
sure,
if
that
individual
just
went
looking
through
some
of
our
indication,
samples
I
believe
that
there's
a
c-sharp
example
out
there
and
in
there
they
can
go
spelunking
and
find
the
backend
code
for
what
that's
server-side
on
behalf
of
exchange
should
look
like.
Okay,
okay,.
B
A
All
the
questions,
everyone
that
those
are
those
are
really
good
questions,
yeah
I-
think
one
of
the
key
things
just
to
take
that
I'm.
Thinking
about
the
questions
this
SSO
experience
is
just
four
tabs
and
it's
specifically
focused
on
azure
ad.
So
that's
don't
expect
it
to
work
for
Google
auth,
but
don't
expect
it
to
work
for
any
random
website
that
you
just
start
pinning.
A
This
is
specifically
for
developers
or
building
apps
or
have
an
existing
app
that
they're
looking
to
integrate
into
teams
and
they're
looking
to
build
the
authentic
piece
to
their
application
and
the
way
that
we
recommend
they
do.
That
is
in
conjunction
with
Azure
ad,
by
registering
an
application
and
going
through
that
whole
flow
that
you
saw
me
doing
earlier.
Just
a
few
closing
points.
I
want
to
talk
a
little
bit
about
some
of
the
constraints,
some
of
the
architectural
constraints.
These
are
pretty
important
to
know
about.
A
Some
of
them
are
temporary,
but
they
will
probably
affect
you
for
the
next
few
weeks,
so
I
just
wanted
to
call
them
out
again.
It's
probably
a
good
thing
to
sound
like
a
broken
record
on
this
one,
but
this
only
works
for
Azure
Active
Directory.
So
we
don't
support
Google
auth
for
this
specific
workflow,
we
do
have
samples
on
how
to
make
Google
off
LinkedIn
off
and
all
the
other
off
providers
work.
A
However,
those
will
not
be
true
single
sign-on
experiences
inside
of
teams,
so
this
is
specifically
about
taking
the
user
account
that
the
user
is
logged
into
teams
with
so
they're
if
they're
logged
into
teams
as
a
student
using
their
campus
email
address.
That's
the
identity
that
we're
going
to
be
using
to
sign
the
user
into
your
application
with
another
important
constraint.
Is
you
notice
needed
a
setting
up
and
rock
and
using
that
as
the
domain
name,
that
I
was
running
my
application
off
of,
but
I
had
to
do
two
things?
A
I
have
to
provide
my
domain
name
in
both
my
manifest
down
here,
but
I
also
had
to
serve
my
application.
Where's
my
static
test
I
had
to
serve
the
application
from
that
very
same
domain
name.
So
it's
very
important
that
your
domain
names
match.
You
know
if
I
have
an
app
called
contoso
comm
I
need
to
make
sure
that
I'm,
calling
that
off
token
from
contoso,
comm
and
I
need
to
make
sure
that
I've
registered
that
domain
name
inside
of
Azure
ad
and
the
reason
we
do.
A
That
is
because
we
need
to
make
sure
that
you
own
that
domain.
Obviously,
if
you're
able
to
start
making
SDK
calls
from
that
domain,
that's
proof
that
you
own
it,
but
it
is
important
because
some
people
have
some
people's
applications
exist
at
a
domain
name,
that's
separate
from
their
URI
that
their
ad
apps
running
at
so
that's
a
very
important
constraint.
Something
to
keep
aware
of
the
third
one.
I
think
this
is
mostly
for
a
line
of
business
developers,
but
today
we
don't
currently
support
the
azure
website's
net
domain.
A
The
azure
ad
team
explained
us
that
this
was
for
security
purposes.
However,
we
are
working
with
the
a
B
team
to
have
this
specific
restriction
removed,
so
in
the
short
term,
don't
use
as
your
website's
net.
Their
reason
for
that
is
because
you,
you
might
be
registered
at
a
domain
name
like
contoso
as
your
website's
net,
and
since
it's
free,
you
probably
only
use
it
for
a
few
weeks
or
a
few
months,
and
then
you
no
longer
use
it
anymore.
Someone
else
comes
in
as
your
website's.
A
They
see
that
contoso
is
now
available,
the
domain
they
take
it
and
they've.
Essentially
through
this,
so
this
entire
exchange
they
could
take
an
ownership
of
your
ad
app
ID
or
your
your
app
in
this
case.
So
for
security
reasons,
as
your
website
has
been
blacklisted,
however,
we
are
working
with
them
on
getting
that
specific
restriction
removed.
A
Finally,
SSO
is
is
great
for
authentication
like
if
you
want
to
authenticate
your
user,
it's
just
a
few
lines
of
JavaScript
after
you've
registered
your
application
and
as
your
ad
and
you're
off
to
the
races
to
get
authorization
working,
it
is
a
little
bit
of
extra
work.
You
need
to
do
a
token
exchange
server
side
for
anyone.
Who's
done
this
before
it's-
hopefully
old
hats
at
this
point,
but
it
is
going
to
be
your
responsibility
to
exchange
that
token
to
get
downstream
resources.
A
Basically,
and
that's
it-
we
don't
provide
you
with
mail
access
or
calendar
access
with
that
token
and
then
finally
mobile,
it's
not
supported
yet
as
soon
as
mobile
rolls
out
into
Developer
Preview,
we
will
be
rolling
the
desktop
code
out
to
the
general
public
and
then
once
mobile
is
available
to
the
general
public
will
be
making
a
general
availability
announcement.
So
we're
we're
staggering
mobile
and
desktop
by
about
a
month,
but
just
something
to
keep
in
mind.
Mobile
sound
supported,
yet
I
tested
it
out
the
other
day
on
mobile.
A
It
worked
great
in
the
Alpha
build,
but
just
something
to
keep
in
mind.
I.
Think
I
think
you
know,
since
we
have
everyone
here,
I
think
today
the
get
off
token
call
will
work
on
mobile.
It
just
won't
ask
for
consent.
So
as
long
as
the
user
has
consented
on
desktop,
then
the
get
off
token
call
will
provide
a
token
back
for
them
on
mobile,
but
if
the
user
hasn't
consented
yet,
then
that
experience
might
be
a
little
bit
broken.
A
You
can
imagine
that
what
you
would
do
in
that
case
is
provide
the
old-school
consent
experience
where
you're
getting
the
user
to
consent
using
a
cookie
based
approach.
So
some
of
the
resources
I've
already
showed
you
the
first
two,
it's
the
SSO
Docs
and
then
the
SSO
sample
go
to
these.
You
watch
this
video
try
to
do
what
I
did
and
get
it
set
up
on
you
on
your
machine
and
I.
Should
let
you
get
you
a
really
nice
sample,
set
up
to
show
you
how
it
works.
A
I
also
just
wanted
to
talk
about
this
URL
I
keep
coming
back
to
it
when
you're
doing
development.
Actually,
you
get
it,
so
you
can
imagine
I've
just
consented
now
and
I
I
want
to
rerun
this
experience,
but
I
don't
want
to
be
consented
anymore.
Where
do
I
go
for
that,
so
there
is
a
URL
called
my
application.
Stop
Microsoft
comm,
and
in
here
you
can
see
all
of
the
apps
that
you
have
consented
to.
Since
we
just
went
through
this
together.
A
I
should
be
able
to
go
and
find
that
contoso
app,
that
I
created
and
be
able
to
revoke
its
access,
because
I
think
this
is
something
that,
when
you're
developing
this
you're
probably
going
to
want
to
know
how
do
I
find
the
apps
that
I've
consented
to
and
how
do
I
revoke
that
consent.
So
go
here.
Oh
so!
Oh
there
you
go.
So
this
is
the
app
we
use
today.
If
I
wanted
to
revoke
permissions,
I
go
to
manage
the
application,
and
these
are
the
permissions
that
I've
consented
to
I.
A
Just
click
revoke
permissions
and
it'll
revoke
all
the
permissions.
For
me,
it
takes
a
bit
of
a
while.
It
takes
maybe
20
minutes
sometimes
for
your
permissions
to
be
fully
revoked,
but
once
that's
revoked
you
can.
Then
we
run
through
this
experience
as
if,
though,
you've
never
consented
before.
Finally,
just
a
little
plug
for
all
of
the
other
developer
community
calls
we
have
ones
for
adaptive
cards
graph
identity.
A
Today's
one
is
for
team's
office,
add-ins
power,
apps,
sharepoint
and
then
just
general
development
as
well
for
sharepoint,
probably
very
familiar
with
basa
and
the
sharepoint
community
I.
Think
for
this
specific
hall
for
the
people
who
are
here
definitely
the
graph
of
the
identity
calls
are
pretty
close
to
the
material
that
I
presented
today.
So
if
you
want
to
know
more
about
identity
and
graph
permissions,
highly
recommend
you
check
these
two
out
and
that's
it
recording
will
be
available.
The
next
mall
will
be
on
March
17.
So
thank
you.
A
B
A
This
I
know
that's
a
really
good
question.
I
would
imagine
in
this
experience.
No,
you
don't
need
to
sign
out
no,
but
that
is
something
that
I
will
run
up.
A
flagpole
I
will
go
talk
to
our
app
validation
team
and
make
sure
that
they're,
aware
of
that,
you
don't
need
to
provide
that
logout
experience.
A
I,
don't
believe
so
anyway,
at
least
some
of
the
internal
apps
that
we've
been
piloting,
haven't
provided
one,
but
you
know
I'd
always
treat
the
validation
documentation
as
the
source
of
truth,
so
until
those
have
been
updated
and
until
I
have
checked
with
a
validation
team
for
now,
let's
just
treat
it
like
you're
supposed
to
have
some
logout
experience
of
some
kind
inside
of
your
application.
I
will
ask
them
to
check
on
that
and
if
any
changes
are
made,
the
documentation
will
be
updated.
For
that.
That's
a
good
question.