►
From YouTube: Single sign-on support for bots - Demo
Description
Ojasvi Choudhary and Tatiana Cristea share information about single sign-on for Microsoft Teams Bots. Learn what's new.
Resources:
SSO for Bots Docs https://aka.ms/AAaeizy
This demo is taken from the November Microsoft Teams community call.
To join future calls, please download the series at https://aka.ms/microsoftteamscommunitycall
Stay connected
Twitter https://twitter.com/microsoft365dev
YouTube https://aka.ms/M365DevYouTube
Blogs https://aka.ms/M365DevBlog
A
So
let
me
start
by
just
giving
an
overview
of
like
the
odd
story
for
bots
today
prior
to
prior
to
single
sign-on.
Obviously
so
why
why
exactly
would
you
require
authentication
inside
a
board?
Well,
typically,
it
would
be
that
you
know
to
a
user
might
send
you
a
request,
or
you
understand
that,
in
order
to
complete
certain
workflows,
you
need
access
to
certain
privileged
information
of
or
from
a
particular
user.
It
could
be
their
email
address,
it
could
be,
or
some
other
protected
part
of
their
microsoft
graph
token.
A
A
So,
in
order
to
do
that,
you
need
some
sort
of
authentication.
So,
typically,
what
that
involves
in
teams
is,
if
you've
done
this
before
there
are
some
things
called
sign-in
cards.
So
the
way
this
flow
will
typically
work
is
a
user
was
will
send
a
message
to
your
bot.
At
that
point,
your
board
determines
okay
to
complete
this
particular
workflow.
I
actually
do
need
the
user
to
sign
in
maybe
it's
asking
for
some
level
of
privileged
information
or
org
charts
or
something
like
that,
and
then
you
send
a
sign-in
card
back.
A
Then
the
user
sees
the
sign-in
card.
It's
you
know.
The
messages
stand
amount
to
something
like
hey
in
order
to
proceed.
Further,
please
sign
in
the
user.
Goes
ahead,
clicks
the
sign
in
button.
You
know
you.
We
just
saw
karthik's
example,
there's
a
little
sso
pop-up
and
then
that
takes
us
to
the
azure
a80
sign-in.
So
it's
very
similar
from
there
from
this
point
on
to
for
bots
as
well,
whether
it's
spots
or
tabs
and
we
take-
we
take
the
user
through
the
auth
provider.
They
do
the
necessary
checks.
Then
they
approve.
A
Now
all
this
is
well
like
one,
for
example,
it
works
right
and
there
are
two
key
pieces
over
here:
the
sign-in
card,
and
then
you
haven't
registered
your
application
with
azure
active
directory,
the
sign-in
card
being
a
means
to
authenticate
the
user
and
you
having
registered
your
application
with
azure
active
directory,
means
being
roughly
of
a
means
of
authorizing
your
application
to
talk
with
our
azure
active
directory
now,
okay,
so
this
works
all
well
and
good.
Everything
just
seems
fine
right,
but
there
are
a
few
limitations
with
this
approach.
A
Even
these
applications
that
we
think
like
operate
with
a
higher
degree
of
trust,
especially
the
ones
authorized
by
the
tenant
admin,
they
also
need
a
sign
in
and
secondly,
in
certain
cases
the
bot
framework
store
will
not
refresh
the
tokens,
which
means
that
the
user
will
have
to
keep
on
signing
again
and
again
and
again
until
we
exhaust
them.
And
you
know
this
can
be
bad
for
your
app's
retention.
A
A
So
here
is
the
who
bot
and
what
is
demonstrated
is
basically,
if
you
are,
let's
assume
that
I
signed
in
once,
and
I'm
asking
about
like
hey.
Who
are
these
people
that
I
work
with
and
effectively?
If
the
tokens
expire,
then
the
bot
is
just
going
to
be
like
hey.
I
really
need
you
to
give
me
permissions
before
I
can
perform
searches
on
your
behalf.
I'm
not
going
to
be
able
to
do
this
unless
you
sign
me
and
authenticate,
and
we
move
forward.
A
A
Is
this
is
a
demo
board
over
here
and
if
all
it
does
is
just
send
us
authentication
tokens
when
you
say
hey,
so
you
know
a
pretty
savvy
bot,
but
I
go
to
the
board,
I'm
like
like
say,
hey,
and
then
you
see
this
small
little
fml
message
come
over
here.
That
says
that
we
need
to
ask
additional
permissions
on
your
behalf,
like
you
would
only
have
to
do
this
once
and
then
you
continue
with
it.
A
So
it
keeps
the
bar
chat,
consistent
and
clear,
and
only
you
know
keeps
things
more
clear
and
relevant
to
the
actual
information
and
the
actual
workflows
that
your
bots
wants
to
accomplish,
rather
than
some
cards
sitting
there
with
silent
content
two,
since
our
tokens
are
refreshed
right
and
you
send
us
a
request
for
sign
in
since
this
message
is
ephemeral
on
the
the
first
thing
that
teams
is
gonna.
Do
is
we're
gonna,
silently
try
and
acquire
the
token
and
see
if,
like
the
tokens,
are
available
in
the
in
the
bot
framework
in
small
store?
A
If
they
are
available,
then
we'll
just
pass
the
token
back
to
you.
So
the
user
won't
see
a
prompt
and
if
they
aren't,
then
they
will
see
the
prompt.
So
this
is
one
of
the
reasons
why
we
had
to
make
this
ephemeral
and
what
you
see
and
the
reason
why
you
see
this
over
here
so
then
you
go
ahead
and
the
user
completes
the
flow
and
that's
it
they're
signed
in
now
now
we're
just
going
to
create
an
event
and
yeah.
So
there
we
just
created,
like
some.
A
You
know
a
calendar
event
for
a
particular
meeting
and
now
with
single
sign-on
you'll,
be
able
to
see
that
the
bot
is
just
able
to
grab
the
event
without
without
having
to
prompt
the
users
to
assign
and
flow
again
right.
So
there
we
go.
So
this
is
an
event
right.
So
let's
move
on
to
scenario
number
two
now
over
here
in
this.
This
is
I've
got
a
so
this
is
another.
This
is
a
totally
different
user.
It's
a
different
tenant
and
this
user
has
a
bunch
of
very
important
meetings
over
here.
A
As
you
can
see,
and
we
want
to
visualize
these
meetings
because
you
know,
presumably
we
can
run
some
sort
of
analytics
and
try
to
understand
like
how
busy
work,
how
busy
the
employees
are
and
what's
happening
over
there.
So
in
this
case
importantly,
I
grabbed
this
bot
from
the
tenant
admin
store
right,
my
it
admin
has
authorized
this
particular
board
to
be
enabled
for
sso
and
he's
opted
in
the
entire
tenant
on
their
behalf,
because
this
is
presumably
like
it's
a
trusted
board.
A
The
admins
think
that's
valuable
enough,
and
so
they've
been
able
sso
for
this
one
now
what's
gonna
happen
is
when
you
try
to
figure
out
like
what
the
bot
can
do.
It
straight
up
is
able
to
like
access
all
of
your
meetings
without
the
user,
having
decided
even
once,
how
of
which
we
think
is
a
very
powerful
scenario
because,
like
for
a
certain
subset
of
applications
for
a
certain
subset
of
parts
which
you've
developed
yourself
or
you,
you've
worked
with
their
isvs
to
customize.
A
So
that's
it.
So
both
of
these
features
together
will
be
part
of
sso4bots,
the
first
one
being
the
ability
to
refresh
tokens
which
eliminates
the
needs
for
users
having
to
sign
in
again
and
again,
that's
that's
the
first
core
scenario,
the
second
core
scenario
being
the
id
admin
approving
a
particular
application
and
opting
in
on
behalf
of
users
inside
that
tenant.
A
Teams
receives
that
message
and
for
the
first
time,
for
first
time
users.
It
creates
an
fml
message,
much
like
you
saw
over
here
and
underneath
the
word
and
you're
seeing
underneath
over
here
and
prompts
the
user
to
sign
in
and
makes
a
call
to
azure
active
directory
to
grab
the
users
tokens
and
credentials
so
once
all
the
all
of
that
is
done
once
all
so
so
it
signs
a
prompt
sign
in
and
then
requests
the
credentials
from
azure
active
directory
on
behalf
of
the
user,
then
azure
ad
says.
Okay,
here
are
the
credentials.
A
A
In
this
particular
case,
the
various
meanings
that
were
part
of
the
user's
calendar
and
then
or
or
for
example,
it
could
have
been
the
email
address
or
the
or
chart
in
the
case
of
the
who
board
and
use
that
to
move
on
further
and
complete
the
move,
and
that's
basically
it
that's
sso
for
runtime
from
time.
The
core
feature
being
that
point
number
two,
which
is
the
cause
of
major
major
user
friction,
is
going
to
be
taken
away
because
the
user
will
only
have
to
do
this
once
or
you
will
have
the
id
admin
approve.