►
Description
Kyle Marsh, Principal Program Manager, kicked off the 2020 developer community call series with an in-depth discussion on best practices for developers on the Microsoft identity platform.
For more information, please visit https://developer.microsoft.com/en-us/identity
A
Practices
that
we've
come
across
and
that
we
suggest
for
developers
who
are
building
on
top
of
the
Microsoft
identity
platform,
so
the
practices
we're
gonna
go
through
first
off
I
have
some
golden
rules
for
tokens
said
everyone
should
be
following.
As
you
know,
it's
all
about
tokens
as
a
developer.
So
what
are
the
rules
that
you
should
follow
with
respect
to
tokens?
A
What
are
some
of
your
options
available
for
creating
a
great
user
experience
by
how
to
use
scopes,
we're
going
to
talk
about
using
roles
and
groups
for
authorization
enabling
provisioning
so
that
you
also
some
some
best
practices
around
protecting
api's
and
services,
as
well
as
protecting
your
apps?
All
of
these
things
are
things
that
you
should
be
thinking
about
as
you
go
through
with
your
application
development.
A
So,
let's
start
with
the
golden
rules
for
tokens.
This
is
a
real
interesting
point,
because
we
get
we
get
a
lot
of
questions
about
tokens
you
know
can
I
do
this,
can
I
do
that?
Where
can
I
get
them
and
so
on
and
while
I'm
not
going
to
talk
about
how
you
acquire
a
token,
the
easiest
thing
is
simply
use.
One
of
our
MSL
libraries,
or
perhaps
a
middle
tier
library
like
asp.net
or
asp.net
core
but
I
do
want
to
go
through
is
the
nature
of
what
you're
trying
to
do
with
the
tokens.
A
How
can
you
use
them
and
so
forth?
So
the
transaction
for
all
of
us
on
occasion
and
authorization
is
relatively
straightforward.
You
ask
for
a
token
you
go
to
the
identity
provider
in
this
case.
Microsoft
identity
and
you
say,
can
have
a
token
to
identify
the
user
or
can
I
have
a
token
to
to
call
an
API
with
a
particular
range
of
operation.
So
that's
the
mechanics.
Those
are
the
transactions,
if
you
will,
but
what
kinds
of
things
should
you
be
thinking
about
with
respect
to
how
you
use
and
and
and
work
with
these
tokens?
A
The
first
off
is
that
you
should
only
use
tokens
for
their
intended
function.
So
if
you
ask
someone
I
need
to
identify
the
user,
please
give
me
an
ID
token.
You
shouldn't
be
saying:
oh
I'm
gonna
use
this
for
something
else.
Our
most
common
breakage
here
is
people
who
say
well.
I
have
an
ID
token.
That
should
be
enough
I'm
going
to
use
this
ID
token
for
something
else.
The
only
purpose
of
an
ID
token
is
to
simply
identify
who
the
user
is
to
that
application,
and
it
shouldn't
be
used
for
any
other
purposes.
A
Similarly,
an
access
token
is
used
for
also
only
one
thing
you
can
acquire
an
access
token
in
order
to
allow
the
application
access
to
the
data
on
behalf
of
the
user
or
possibly,
if
you're
working
as
a
client
credential
app
on
behalf
of
the
application
itself.
Alright.
So
this
is
what's
authorizing
or
allowing
the
developer
of
the
application.
A
The
next
rule
is,
is
the
one
that
I
think
it's
broken
most
often,
which
is
never
mess
with
someone
else's
token.
Tokens
are
issued
to
a
particular
audience
if
you
will,
inside
of
ever
every
token
is
an
audience
and
when
you
acquire
a
token,
you
know
whether
you're
acquiring
a
token
for
yourself
or
acquiring
a
token
for
an
API
you're
about
to
call.
So
it's
a
pretty
easy
rule
that
you
should
never
mess
with
someone
else's
tokens.
Well,
how
do
we
see
these
this
rule
being
broken?
A
A
First,
off
at
any
point
in
time,
it's
possible
that
you'll
lose
access
to
that
access
token
they
might
become
encrypted.
We
might
change
to
a
different
format,
there's
nothing
saying
in
the
standards
what
we
have
to
do
with
respect
to
the
format
of
that
token,
so
you
can't
rely
on
that.
The
second
thing
you
can't
rely
on
what's
in
the
token,
because
at
any
point
in
time
the
API
designer
might
say,
hey,
I,
don't
need
that
anymore
or
I'm
gonna
change,
whatever
the
claims
I
expect
to
see.
A
In
my
token,
since
you
have
no
information
about
that,
their
desire
to
do
so
or
when
they
take
that
change.
Your
application
is
quite
likely
to
break
so
it's
it's
absolutely
a
best
practice
and
when
we
see
broken
way
too
often
applications
trying
to
look
inside
those
access
tokens
I.
Also
by
that
mean
validating
or
doing
anything
else
with
the
access
token.
A
It
has
one
purpose:
one
intended
function
back
to
rule
number
one
which
is
to
give
it
to
an
API
as
part
of
my
API
call,
and
that's
it
another
way
that
people
mess
with
someone
else's
tokens
is
api's
that
take
an
ID
token
instead
of
an
access
token.
Well
that
I,
that
token
was
not
issued
for
the
API.
So
it
should
always
always
fail
token
validation
from
the
API,
because
the
audience
will
not
be
the
api's
audience,
it
will
be
the
applications
audience.
So
it
should
absolutely
always
fail
that
that
that's
straightforward
validation.
A
It
also
the
reason
one
of
the
main
reasons
we
we
want
to
harp
on
this
particular
thing.
As
we
see
developers
all
the
time
saying
well,
all
I
want
to
really
know
is
if
the
user
signed
in
well.
But
what
you're
taking
away
here
is
first
off
you're
saying
my
API
is
not
going
to
be
secure
all
right,
so
there's
no
way
to
secure
my
specific
API.
So
if
a
customer
or
user
said
you
know,
given
some
particular
situation,
we've
had,
we
need
to
restrict
access
to
this
API.
A
Well,
they
can't
do
it
because
there's
nothing
to
control
your
API
with,
because
it
doesn't
have
an
access,
token
you're,
taking
any
ID
token.
That
comes
your
way
all
right,
so
it
you're
effectively
saying
well:
I,
don't
want
on
any
protection
domain
API,
in
which
case
you
might
as
well
not
implement
any
another
common
way.
Somebody
messes
with
someone
else's
token
is
they'll,
take
an
access
token,
but
from
some
other
API
most
commonly
folks
will
save
things
like
well.
If
they
have
a
token
to
Microsoft
graph,
that's
enough
for
me!
A
Well,
it
still
comes
down
to
you're,
not
protecting
your
API
at
all,
you're,
hoping
that
maybe
there's
some
difficulty
or
some
security
bar.
You
have
to
reach
to
get
an
access
token
to
Microsoft
graph,
some
of
which
are
really
easy
to
get
because
they're
very
limited
scope,
limited
capability
token
so
another.
So
this
is
a
common
way
that
this
rule
gets
broken,
but
it
is
a
simple
rule:
never
mess
with
someone
else's
tokens,
and
if
you
follow
that,
there's
lots
of
places
you
would
have
these,
we
sometimes
get
question
hey.
A
Would
it
be
alright
if
I
used
an
ID
token,
instead
of
an
access
token?
Well
frankly,
if,
since
it
breaks
golden
rule
number
two?
No,
so
if
you
follow
these
these
two
golden
rules,
you
often
will
answer
the
questions
you
might
have
of.
Is
it
okay?
If
I
do
something?
That's
not
quite
what
I
think
it
is
supposed
to
be
another
behavior
we
see
applications
doing
and
falling
into.
If
you
will
is,
they
will
often
or
sometimes
not
cash
tokens
appropriately.
A
All
of
our
tokens
are
issued
in
the
jock
format
today
which
JSON
web
token,
which
means
that
they're
good
until
they
expire.
So
if
we
give
you
a
job
token,
that's
good
for
an
hour,
you
shouldn't
be
asking
us
for
the
same
job
token,
if
you
will
the
same
nature
of
token
to
call
say
the
same
API
a
minute
later.
It's
just
not
the
appropriate
use
of
the
tokens
that
we
issue.
It
also
could
lead
your
application
to
being
throttled
because
you
continuously
ask
for
the
something
that
you
have
already
acquired.
A
So
there's
no
way
for
us
to
determine
whether
that
was
intentional,
behavior
unintentional,
behavior,
a
bug
or
anything
else.
So
we
issue
tokens
with
a
particular
range
of
time
frame
that
they're
allowed
in
and
when
they
expire,
and
you
need
to
catch
those
tokens
to
make
sure
you're
not
putting
additional
load
on
the
system.
Both
our
system
and
yours,
there's
no
point
in
you.
Making
a
bunch
of
round-trip
calls
to
get
tokens
that
you
didn't
need
to
do,
because
you
already
had
a
perfectly
valid
token.
A
So,
for
example,
don't
code
for
something
that
says
I
need
to
have
the
user
hasn't
consented
to
this
attitude.
To
this
request,
which
is
a
particular
interaction
you
go
to
ask
ask
for
an
access.
Token
consent
has
not
been
granted,
so
we
would
come
back
and
say
well.
We
need
to
talk
to
the
user
about
consent.
We
also
have
a
class
which
says
user
interaction
required,
so
the
number
of
four
or
five
different
ways
that
that
we
might
need
to
speak
to
the
user.
Their
password
expired
that
hasn't
been
consented,
etc.
A
I'll
wrap
up
into
one
block
of
code.
You
have
to
actually
implement,
which
is,
is
user
interaction
required.
So
we
have
a
Golden
Path
if
you
will
acquire
token
silently
if
user
interaction
is
required,
which
is
really
a
class
of
errors,
then
acquiring
our
token
interactively.
That's
a
golden
pattern
and
M
solve
for
s
and
and
and
the
key
there
is
that
we're
checking
for
an
error
class
and
our
code.
A
So
they're
they're
not
a
whole
lot
of
rules
here.
But
if
you
follow
the
rules,
you'll
find
you
you'll,
find
yourself
staying
on
the
right
path
and
not
necessarily
doing
things
that
that
could
be
opening
up
vulnerabilities
that
you
you're
not
aware
of
so
one
of
the
things
that
I
often
get
back
from
is
don't
know.
I
have
to
look
in
the
access
token,
it's
absolutely
required,
because
how
also
am
I
going
to
know
why
I'm
getting
an
access
denied
when
I
call
the
API
right.
So
you
know,
hey
is
a
debugging
technique.
A
We
should
all
learn
how
to
look
into
access
tokens.
The
real
problem
with
that
is
at
some
point.
In
time,
if
we
start
encrypting
these
tokens
you're
not
going
to
have
access
to
that
token,
you
won't
be
able
to
look
at
it
to
debug
right.
So
there's
no
point:
building
a
whole
skillset
and
and
and
and
getting
used
to
the
pattern
of
the
way
I
debug
is
I,
go
off
and
I
look
inside
the
access
token
to
figure
it
out.
A
You
need
to
find
a
better
way,
and
frankly,
we
have
one
already
built
in
I'm,
going
to
switch
over
to
a
little
app
I.
Have
that
lets
me
look
at
tokens
and
such
let
me
go
ahead
and
I'll
sign
in
I'm,
spying,
Network
catches
up
to
me
so
I'll,
just
sign
in
as
myself
in
this
demo
tenant.
We
have
sure
if
I
look
at
the
ID
token
I'll
get
all
of
the
information
I
expect
out
of
an
ID
token,
though,
specifically
my
audience
is
my
application.
A
So
I
know
it's
my
token
I'm
allowed
to
mess
with
this
here's
my
preferred
username
as
well
as
things
like
my
object,
ID,
which
tells
me
exactly
which
user
this
is
now.
That's
not
helping
me
if
I
need
to
call
the
profile.
Api
and
I
get
an
access
denied,
but
if
I
look
at
the
token
response,
this
is
the
actual
HTTP
transaction
response
that
we
got
from
that
web
request.
To
get
the
token
in
the
first
place,
you'll
see
a
lot
of
interesting
information
that
not
only
can
help
me
debug,
but
help
me
understand.
A
What's
going
on
a
little
bit
more,
so
the
first
thing
we
tell
folks
is
well
here's
the
user
by
the
way.
This
is
where
the
user
is
natively
home.
If
you
will
so
I
have.
If
this
was
a
guest
user,
I
could
see
information
about
where
which
Active
Directory
or
whether
a
consumer
or
not,
where
this
user
actually
came
from
the
key
element.
People
want
for
their
debugging
is
what
scopes
are
this
token?
A
Well,
we
tell
you
what
scopes
are
in
the
token,
without
you
having
to
open
the
token
to
find
out
similarly
that
another
key
element
is
when
does
this
token
expire,
so
by
looking
at
the
token
response,
instead
of
trying
to
dissect
into
the
token,
you
really
have
all
the
information
you
need
in
order
to
try
to
figure
out.
Why
are
you
getting
that
excess
tonight
when
you've
supplied,
say
this
access
token
to
an
API
I
will
point
out
another
reason
you
really
want
to
look
inside
the
token
response
is
this
correlation
ID?
A
This
is
something
you
should
absolutely
be:
logging
and
tracking.
If
you
ever
thought
well,
I
really
can't
figure
out
why
this
operation
isn't
occurring,
justified
to
open
a
support
ticket
or
try
to
contact
us
that
to
help.
If
we
have
the
correlation
ID,
we
have
a
chance
of
going
back
and
finding
out
what
happened
during
that
authentication
or
authorization
request.
A
If
all
you
say
is
well
when
the
user
types
this
this
doesn't
come
back,
we
don't
really
have
anything
to
really
work
with
that
much
so
the
correlation
ID,
which
is
not
in
a
token
it's
only
in
the
token
response,
is
something
you
absolutely
want
to
keep
track
of,
and
log,
for
example,
as
you
move
through.
So
there
isn't
a
need
to
crack
open
an
access
token.
If
all
you
need
to
do
is
get
information
like
what
spills
are
in
the
token,
so
you
could
go
ahead
and
continue
your
debugging
process
so
permission
and
consent.
A
This
is
a
an
area.
What
that
really
is
a
key
there's
two
key
factors
for
me
as
a
developer
as
I
look
at
using
the
Microsoft
identity
platform.
One
is
all
of
my
transactions
are
about
I,
ask
for
token
and
I
deal
with
either
getting
a
response
or
not
getting
a
response.
So
that's
my
transactional
process
throughout
everything.
I
do
with
the
Microsoft
identity
platform.
The
second
thing
is:
I
control.
A
The
experience
by
how
I
use
the
permission
and
consent
framework
now
one
first
item
here
is
remember:
permissions
are
only
about
the
app
or
the
developer
or
the
app
code
or
whatever
you
want
to
say
they
have
nothing
to
do
with
a
user.
So
don't
try
to
be
thinking
well,
I
have
if
I
get
a
permission.
That
means
my
app
can
be
used
for
this.
If
you
get
a
delegated
permission,
then
it
doesn't
mean
the
app
will
work
for
that.
It
only
means
that
if
the
user
can
your
app
can
be
used
for
that.
A
So
remember
that
permissions
and
consent
are
always
about
just
the
user
or
sorry
the
application
developer
and
never
the
user,
and
that
is
in
in
absolutely
true,
even
if
you're
asking
for
on
behalf
of
permission,
the
delegated
permission
is,
we
refer
to
them.
So
all
that
they
do
is
permissions.
They
authorize
your
API
to
to
call
a
particularly
authorized
your
app
to
call
a
particular
API
with
a
particular
range
of
operation,
which
was
referred
to
as
the
scope
parameter
right.
So
I
like
to
call
it
a
range
of
operation
than
a
particular
limitation.
A
In
that
it,
depending
upon
the
nature
of
the
scope
it
can,
it
can
broaden
your
capabilities
it
could
it
could
restrict
them.
It
could
give
you
some
very
specific
functionality.
For
example,
our
user
dot
read
basic
than
all
lets.
You
read
all
of
the
users
in
the
tenant,
but
not
all
of
the
information
about
all
of
the
user
users.
This
restricted
only
seven
or
so
properties
of
the
user
that
you
can
have
given
the
fact
that
the
API
designer
has
said
I
wanted
to
design
this
by
having
a
scope
for
my
permission
model.
A
What
the
API
designer
is
saying
is
I
want
to
have
the
permission
and
consent
experience
or
approval
process
if
you
prefer
attached
to
the
ability
for
application
developer
to
have
access
to
this
information.
So
if
we
look
at
Microsoft
graph,
we
have
made
the
decision
that,
before
an
application,
developer
is
allowed
to
say,
see
the
full
users
profile.
A
Of
course,
you
should
only
ask
for
a
scope
or
a
permission
or
a
range
of
operation
for
code
that
you
have
implemented.
If
you
haven't
implemented
the
ability
to
write
shouldn't
be
asking
for
read/write.
If
you
haven't
written
anything
about
groups,
you
certainly
shouldn't
be
asking
for
any
group
permission
etc.
Again.
This
is
all
about
approving
the
developers
access
to
this
information.
So
it's
important.
You
only
ask
for
things
that
you
have
add
that
you're
actually
implemented.
A
So
if
you
haven't
implemented
the
functionality
you
shouldn't
be
asking
for
that
permission
right
and
that's
what
we
refer
to
as
a
least
privileged
permission.
If
all
I'm
going
to
do
is
read,
I
should
only
ask
for
read
this
allows
two
things.
First
off
it
lets
the
or
user
trusted
a
that
you
you've
done
a
good
job
of
implementation.
It
also
allows
a
90
Pro
to
to
manage
who
gets
access
to
what
and
so
on
right.
So
it
is
also
one
other
thing.
A
It
also
means
that
if
somehow
your
application
was
compromised,
no
one
can
use
the
you
know
your
applications
identity
to
do
something
you
didn't
intend
to
write.
So
if
I
found
a
way
to
exploit
your
application
to
say,
hey
I
should
be
able
to
do
rights
with
this
code.
If
your
application
hasn't
asked
permission
to
write
it
can't
be,
it
can't
be
altered
to
camp
these
hijacks
in
a
way
that
would
allow
it
to
do
something
the
developer
didn't
intend.
A
So
this
is
where
you
as
a
developer,
request
that
act
that
that
permission
now,
some
of
the
new
things
that
are
coming
in
permission
and
are
changing
the
user
experience.
One
of
them
is
we're
having
much
more
granular
consent
available
to
tenant
admins.
So,
as
we
move
forward
today,
they
have
a
very
hard
and
fast
switch.
Either
user
consent
is
allowed
or
user
consent
is
not
allowed,
but
going
forward
they'll
be
able
to
make
those
decisions
on
a
more
permission
by
permission
basis.
A
The
tenant
admins
have
the
ability,
even
today,
although
they
can
only
do
all
to
say
these
permissions
are
okay
for
a
user
to
consent
to,
and
these
permissions
are
not
so.
You
have
to
develop
your
code
under
the
assumption
that,
given
any
particular
consent
request
any
permission,
scope
on
an
access,
token
request
could
be
denied
because
admin
permission
is
is
required.
A
It
also
means
that
they
could
turn
around
and
turn
off
admin
consent
at
some
point
as
well.
So
you
as
a
developer,
can't
really
always
know
ahead
of
time
if
any
scope,
you're
using,
is
really
going
to
be
admin
consent
or
not.
So
it's
always
important,
therefore,
that
you
handle
not
getting
that
access.
Token
gracefully
all
right.
A
If
you
have
an
access
token
that
you
absolutely
have
to
have
in
order
for
your
front
of
your
application
to
function
at
all
and
that
that's
tonight
then
you're
going
to
have
to
tell
the
user
that
they
can't
use
this
application
for
that
capability,
because
the
consent
was
not
applied.
So
the
simple
transaction
you
ask
for
a
token,
you
always
have
to
be
ready
for
the
response
being.
No,
you
can't
have
that
token.
Another
thing
that
is
coming
is
there's
now
an
admin
consent
workflow,
that's
in
public
preview.
Today.
A
What
that
allows
to
happen
is
instead
of
the
users
seeing
something
that
used
to
say
admin
required.
So
I
would
ask
for
permission.
That
say
it
was
always
a
an
admin
consent
required
permission
like
user
dot.
All
if
my
application
asks
for
usually
not
read
at
all
any
tenant,
any
user
who
wasn't
an
admin
would
get
this
relatively
harsh
dialogue
that
says
admin
required
and
they
may
not
know
who
their
admin
is.
They
don't
know
how
to
get
past
that
and
that
can
be
difficult.
A
So,
instead,
what
we're
adding
to
in
probably
preview
today
is
the
ability
for
this
to
actually
start
a
workflow
instead,
so
instead
of
the
user,
just
seeing
admin
required,
they
would
say
well,
I'll
show
you
it
requests.
What
can
what
can
happen
now?
One
of
the
other
things
I
really
want
to
stress
here
is
that
you
as
a
developer,
are
completely
in
charge
and
one
aspect
of
the
user
experience
and
that's
when
is
the
developer,
going
to
be
prompted
for
what
consent
items?
A
So,
let's
start
by
going
ahead
here
and
we'll
sign
this
user
out
and
let's
look
at
the
code
behind
this
application.
So
it's
a
very
straightforward
process
for
me
as
a
developer,
to
figure
out
that
how
I'm
gonna
make
these
API
calls
to
Microsoft
graph.
So
what
I've
done,
because
I'm
very
simple,
simple
developer
is
I've
just
said:
well,
here's
the
API,
I'm
gonna
call
I'm,
gonna,
call
the
standard
user
profile,
API
the
sort
of
heart
and
soul
of
Microsoft
graph.
A
The
me
API
and
I
know
for
what
I
hear
is
user
dot
read
because
all
I'm
gonna
do
is
read
the
current
user's
profile,
so
I
go
off
and
call
that
API
with
our
standard
acquire
token
silent.
If
interaction
is
required,
go
ahead
and
acquire
token
interactively.
The
key
element
here
is
Scopes
which
I'm
just
passing
into
this
application.
So
this
is
the
range
of
operation
I
want.
A
So
what
I'm
relying
here
on
is
the
emcell
libraries
to
figure
out
at
any
point
in
time
if
I
have
to
acquire
another
permission
or
not
so
I'll
start
with
user
dot
read
and
then,
if
I
want
to
go
ahead
and
call
the
people
API,
here's
the
people
of
API
me
slash
people,
the
consent,
I'll
need
will
be
people,
people,
don't
read
the
scope
and
so
on.
So
this
makes
it
very
easy,
as
an
application
developer
to
to
figure
out
to
keep
my
scopes.
A
If
you
will
closely
associated
with
the
API
call
I'm
gonna
make
now
if
I
go
ahead
and
run
this
application,
which
is
the
state
I'm
in
now,
I
get
the
ability
so
we'll
go
ahead
and
sign
the
user
in
and
I'll
sign
in
as
Microsoft
identity,
I
should
have
signed
them
in
first,
so
that
me
dude
could
have
anyway.
So
here's
I
have
my
ID
token.
It's
Kyle
from
this.
This
demo,
tenant
I,
can
check
my
tenant
response.
I've
got
my
user
dot
read
profile
and,
of
course,
I
get
the
profile
information
from
the
user.
A
If
go
mental
consent
can
be
very
powerful
and
that
it
allows
you
to
be
able
to
do
this
kind
of
user
interface,
but
it's
more
targeted
at
you
should
do
it
only
when
you
really
need
to
as
opposed
to
sort
of
a
default
choice.
So,
let's
sign
Kyle
out
here,
I
didn't
grant
that
permissions.
Let's
go
sign
Kyle
out
and
one
of
the
things
I
can
do
with
this
little
app
is
I
can
change
my
my
startup
profile
consent.
So
one
option
here
will
be
looking
back
at
the
code.
A
Is
I
just
do
an
incremental
consent.
If
you
will,
every
time
I
need
a
permission
and
I'll,
let
em
self
figure
out
if
there's
any
actual
thing
under
the
covers
that
needs
to
happen
there.
So
my
alternative
is
to
run
this
application
and
I
can
set
what
I
want
to
see
the
user
to
see
during
sign-in
time.
So
one
great
choice
of
when
you
sign
the
user,
in
is
to
say:
well
what
should
they
consent
to
as
soon
as
they
start
the
application?
A
So
I
could,
for
example,
do
what
I'm
doing
now,
which
is
just
the
user
profile
user,
dot,
read
or
I,
could
ask
for
only
the
permissions
that
this
app
has
only
require
user
consent,
so
that
would
be
user
dot.
Read
and
people
don't
read.
I
could
say:
I
want
everything
everything
I
know,
for
example,
if
I
know
all
of
the
permit,
all
the
permissions
I
might
use.
I
could
ask
for
everything
this
way.
A
An
alternative
spin
on
that
is
to
use
something
called
static,
consent,
static,
consent,
says,
go
to
the
application
registration
and
whatever
is
listed
under
the
application
registration
under
API
permissions
that
the
application
could
use,
use
that
instead
and
the
way
I
specify
that
as
a
developer
is
I,
give
it
my
application,
ID,
slash
dot
default
and
that
tell
Elsie
Microsoft
identity
platform
to
go
and
figure
out
what
all
the
permissions
have
been
declared
for
this
application
and
use
those.
Let's
change
that
we'll
go
ahead
here
and
we'll
go
to
our
user
consent
items.
A
So
when
the
user
signs
in
they'll
be
prompted
for
a
user
dot,
read
and
people
don't
read
so
we'll
go
back
here
in
here,
we'll
sign
in
Kyle
again
from
this
demo
tenant
now,
I
still
get
a
different
permission
requested,
because
the
last
time
Kyle
ran
it.
He
only
saw
I
only
consented
to
reading
the
user
profile.
A
Not
this
read
relevant
people
list,
so
I
will
go
ahead
and
accept
that
and
now,
if
I
were
to
sign
out
again
and
sign
into
you
sign
Kyle
back
in
again
I've
already
pre
consented
I've
already
consented
to
those
two,
so
I
won't
get
an
additional
prompt.
I
shouldn't
have
like
oh
I
need
to
accept,
did
last
time,
I'll
go
ahead
and
call
the
people
API
and
I
get
a
function.
A
So
if
I
call
the
profile
API
things
work,
if
I
call
the
people
API
things
work
without
an
additional
consent
grant,
but
if
I
call
the
group's
API
I
will
get
an
additional
prompt
because
of
course,
in
this
case,
I'm
asking
for
something
for
both
admin
consent
and
that
I
haven't
actually
pre
could
wasn't
given
to
me
in
my
initial
sign-in
experience.
So
here
I'll
go
ahead,
and
this
is
the
new
workflow.
A
Instead
of
it
saying
admin
required
up
top,
it
now
says:
approval
is
required,
and
here
I
could
type
in
a
justification
about
what
I
need
and
I
can
send
that
request
off
for
approval.
So
now,
instead
of
the
user
being
stuck
going,
I
don't
know
how
to
get
past
this.
They
can
start,
they
could
launch
a
workflow
and
then
that
word
request
will
be
sent
off
to
the
people
who
who
can
grant
that
permission
and
head
back
now.
A
My
particular
application
at
this
point
is
still
gonna
get
a
result
of
the
fact
that
says
you
don't
have
user
consent
here,
but
at
least
the
process
is
underway
and
the
user
isn't
stuck.
So
if
the
user
come
back
later,
they
granted
that
consent
and
we
can
move
on.
So,
as
you
can
see,
a
developer
is
in
charge
of
what
the
user
experience
is
by
how
they
use
things
like
what
what's
the
signing
scope,
what
will
the
user
see
up
front
and
well?
A
So
you
are
completely
in
charge
of
what
the
user
experience
is
with
respect
to
when
they
see
consent
prompts
and
what
they
could
expect
to
see
there
and
it's
a
key
area
for
you
to
pay
attention
to
to
develop
a
great
user
experience
for
your
users.
So
one
of
the
other
things
that
we
can
do
in
tokens
is
that
we
can
provide
information
to
you
as
a
developer
about
things
we
refer
to
as
roles
in
groups
right.
A
So
one
option
is
that
you're
all
integrate
deeply
with
Microsoft
graph
in
order
to
determine
who
should
be
what
another
thing
that
you
can
do
is
simply
ask
the
identity
platform
to
say:
can
you
tell
me
the
users
roles
or
groups
are
both
in
the
tokens
you
provide
me
now.
I'm
not
saying
ID
are
access
tokens
here,
because
this
information,
this
capability
applies
to
both
kinds
of
tokens,
so
I
could
be
doing
access
tokens
with
this
information
or
it
could
be.
I
doing
ID
tokens
within
for
this
information.
A
So
a
developer
can
request
that
information
and
it's
available
to
both
types
of
tokens.
So
let's
go
back
into
our
our
demo
app
here
and
we'll
go
ahead,
and
actually
just
not
do
that
one
I'm
going
to
change
my
initial
one
just
to
the
user
consent
items
again
and
we'll
sign
in
Kyle,
and
here
you
can
see
that
Kyle
has
correct
when
I
tokens
claims
here
that
I
have
the
group
information
for
Kyle
here.
In
the
token,
so
these
are
all
of
the
groups
that
Kyle,
who
is
a
member
of
this
Tennant?
You
can
see.
A
There's
no
IDP
group
claim
here.
Rather
so,
I
can
see
that
this
is
a
user
locally
to
this
little
demo
tenant
and
in
this
demo,
tenant
Kyle
is
a
member
of
apparently
four
groups.
So
that's
great
now
the
way
that
that
this
happened
is
because,
when
I
go
to
my
application,
registration
I
can
look
here.
This
is
for
the
best
practices
demo.
I
can
go
here
to
the
mitts
manifest
and
see
that
there's
a
claim.
There's
a
property
in
here
called
group
membership
claims
and
I've
set
that
here
on
my
application,
registration
to
all.
A
So
when
the
user
signs
in
and
I
get
an
ID
token
for
them
or
when
an
application
asks
for
an
access
token,
on
behalf
of
this
user,
for
a
particular
API
I
could
change
the
group
membership
claims
for
an
API
registration
as
well.
I'll
see
that
group
information
right
inside
the
token,
so
that
can
be
very
handy.
A
The
downsides
here
for
for
group
usage
is
I,
don't
know
how
many
of
you
know
your
group,
the
group
name
that
you
want,
but
all
we
give
you
is
to
do
it
so
you'll
have
to
provide
the
mapping
between
that.
The
other
thing
is:
how
do
you
know
which
group
is
interesting
and
which
is
not
well?
You'll
also
have
to
provide
some
UI
in
your
application
to
say:
hey.
If
you
want
submitters
tell
me
which
group
you
want
the
user
to
be
in.
A
If
he's
a
submitter
you'll
have
to
provide
that
UI
functionality,
because
we
don't
provide
anything
like
that
today,
the
alternative
would
be.
If
you
were
closely
associated
with
your
IT
department.
You
could
say:
well,
we
made
up
a
group,
here's
its
ID,
and
they
put
anybody
in
that
group.
We'd
want
to
have
this
functionality
so
that
might
work
for
line-of-business.
It
certainly
worked
what
won't
work
for
an
enterprise
or
for
an
AIA
as
we'd,
rather
so
I'm
going
to
sign
out
Kyle.
A
So
what
we
just
signed
in
was
we
signed
in
Kyle
from
a
local
tenant,
so
I'm
gonna
sign
in
again
here,
I'm
gonna
do
something
interesting.
Actually,
then
he
back
this
off
we're
gonna
not
do
that
I'm
gonna
sign
in
specific
users
to
this
tenant.
So
this
is
the
tenant
that
I
want
the
users
from
it
happens
to
be
the
tenant
where
this
application
is
registered
and
I'm
going
to
say
so.
A
I'm
gonna
sign
in
users
and
instead
of
using
the
common
endpoint
I'm,
going
to
use
this
specific
tenant,
ID
endpoint,
because
what
I
want
to
do
here
is
I'm
going
to
sign
in
a
user,
but
this
time
I'm
going
to
sign
in
guess
no
one
who
signed
in
here
yet
before
we're
going
to
sign
in
Kyle
from
the
Microsoft
tenant.
So
these
are
my
corporate
credentials.
If
you
will,
instead
of
my
credentials
in
that
little
test
tenet
that
we
were
looking
at,
of
course,
I
have
a
by
default
a
password.
A
A
A
Hopefully,
I'll
get
enough
of
a
notification
for
my
MFA
to
work
on
this
network,
so
here
again
so
notice
that
I'm
getting
a
permission
and
consent
prompt.
This
is
for
the
ability
to
use
this
app
from
the
Microsoft
tenant
I'm
likely
to
get
this
rejected.
This
gives
us
a
try.
Oh
I'm,
sorry,
I'm,
exciting
sorry,
I,
apologize,
I'm
sliding
in
Kyle
for
Microsoft,
specifically
to
this
demo
tenant,
so
Kyle
from
Microsoft
is
allowed
to
sign
in
to
this
tenant
because
he
is
a
guest
in
this
tenant.
A
Also
Kyle
for
Microsoft
happens
to
be
attended
admin
in
this
tenant.
So
here
you
can
see
I
I
as
the
guest
in
this
tenant
I'm
a
guest
administrator
I
can
consent
for
this.
On
behalf
of
my
whole
organization
and
if
I
were
to
click
that
nobody
will
see
these,
these
permissions
needed
to
be
prompted
again
for
anyone
in
this
tenant,
so
I'll
go
ahead
and
accept
that.
A
So
if
I
look
at
the
ID
token
that
we'll
get
from
here
well,
let
that
come
up
notice
that
I'm
only
in
one
group
in
this
tenant,
so
there's
Kyle
from
Microsoft
and
he's
only
a
member
of
one
group
right
because
he's
I'm
only
a
tenant
admin
I
can
decide
into
this
thing.
One
more
time,
then
we
switch
back
to
profile.
I'm
gonna
go
back
to
the
common
endpoint,
so
though,
all
users
and
that
signed
up
Kyle
out
of
this
test
tenant
will
go
ahead.
A
We're
gonna,
sign
Kyle
in
again,
I've
fought
with
my
Microsoft
identity.
So
there's
my
corporate
identity
I'm
effectively
now
signing
in
to
the
corporate
tenant.
To
do
this
authentication
and
now,
when
I
look
at
the
ID
token
notice,
what
I
get
back
for
groups
I,
don't
get
any
groups
so
apparently
Kyle's,
not
a
member
of
any
groups
in
the
Microsoft
tenant.
Well,
that's
unlikely
in
fact
I'm
a
member
of
so
many
groups
that
it
won't
fit
into
a
token.
So
instead,
what
I
get
here
is
hey
this.
A
This
under
store
claim
underscore
names
claim
says
if
you're
looking
for
a
claim
named
groups,
go
to
claim
sources
and
look
for
a
claim
and
called
SRC
one.
So
that
tells
me
I
have
to
go
to
claim
sources,
which
is
this
claim,
find
the
SRC,
the
SRC
one
claim,
and
there
it
will
give
me
an
end
point
that
I
can
use
to
call
graph
to
find
out
what
groups
Kyle's
a
member
of
so
a
couple
of
things
here.
A
First
off
this
will
require
admin
consent
in
order
to
access
it
as
an
is
because
it's
all
I
need
group
read
all
or
directory
read
all
this.
For
this
permission,
and
the
second
thing
is
notice,
I
have
to
fall
back
to
calling
Microsoft
graph
in
order
to
actually
find
all
all
the
groups
that
Kyle's
a
member
of.
So
that's
not
really
a
great
way
to
do
this
functionality.
So,
let's
go
and
so
groups
work.
A
They
certainly
are
there,
but
they
are
bounded
by
this
limitation
if
you're
using
implicit
flow,
which
is
not
you'd,
be
limited
to
only
six
groups
before
this,
an
overage
occurs
if
you're
using
sam'l
it's
a
hundred
and
fifty
groups
and
200
groups,
if
you
are
a
regular,
open,
ID
connect
application.
So
you
can
see
there
is
this
sort
of
downside
if
you
will
to
do
in
groups?
So
if
I
go
back
to
my
application,
registration
I
can
also
see
that
I
have
this
thing
here.
A
The
property
called
a
paroles,
and
here
my
allowed
user
type
is
user.
So
what
this
is
saying
is
this
application
has
defined
two
roles:
it's
defined
a
submitter
role
and
an
approval
role,
so
what
I
can
actually
do
two
another
way
I
could
control
this
application
is,
then
we
go
back
up
to
I'll,
go
to
this
applications,
enterprise,
app
entry
or
service
principle.
A
If
you
will-
and
here
this
is
where
an
IT
prova
would
be
able
to
manage
how
this
application
works
in
the
tenant
I'm
going
to
go
to
users
and
groups
and
I'm
going
to
take
Kyle.
That
will
be
this
one.
Let
me
find
out,
if
is
this
one
or
not,
so
this
is
Kyle
from
that
Microsoft
test
tenant,
so
I've
got
an
icon
here.
So
let
me
come
here:
I'm
gonna,
edit
Kyle,
oh
I'm,
sorry
I-
have
to
in
order
to
edit
this
I
have
to
be
a
tenant
admin.
A
A
Well,
edit
Kyle
I
could
assign
a
new
user
as
well,
but
I'll
come
in
here
and
now.
I
have
the
ability
to
select
a
role
for
Kyle,
and
you
see
I
have
both
approver
and
submitter.
It's
important
that
you
define
both
because
even
though
submitter
might
be
the
default
for
this
tenet,
everybody
gets
to
submit
and
only
a
few
get
to
approve.
If
I
turned
on
that
users
have
to
be
assigned
in
order
to
be
able
to
use
this
app
today,
any
user
can
use
the
app.
A
A
A
Sorry
about
that.
So
I've
got
a
sales
group.
If
I
pick
the
sales
I
got
Salesforce
users
I
could
see
anyone
at
sales.
I
can
I
can
pick
that
user
is
in
fact
an
approver
and
I'm
sure
they'd
love
to
be
approvers,
but
I
can
make
these
work.
These
assignments
now
I
do
need
a
subscription
level
of
p1
in
order
to
do
these
groups.
If
I
wanted
to
do
this
with
dynamic
groups,
I
would
do
a
Pete
subscription,
but
it
does
allow
me
to
do
that
functionality.
A
So,
let's
go
back
to
the
app
and
we'll
go
ahead
and
sign
Kyle
out
and
and
we're
gonna
come
back
in
and
sign
in,
and
this
was
Kyle
from
the
local
tenant
and
now
I
should
know.
Are
we
see
that
Kyle
gets
a
roll
claim
of
submitters
roles?
Is
I
could
get
lots
of
them?
I
could
be
submitter
and
you
know
different
ones,
but
there's
two
things
here:
your
application,
even
though
I
had
to
find
the
roles
in
my
manifest
notice.
The
first
time
I
ran
this
app
or
I
didn't
get
a
role.
A
The
reason
I
didn't
get
a
role
is
I
was
never
assigned
one
by
the
IT
pro.
So
it's
a
it's
a
valid
case
for
you
to
always
deal
with
what,
if
the
rolls
I'm
looking
for
aren't
there
I
have
to
say
well,
if
no
rolls
are
here,
here's
the
default
functionality
for
a
user,
but
if
there
are
a
roll,
if
there
are
roles
defined,
then
I
would
add
in
whatever
capability
that
role
brings
in
for
them.
So
this
lets
me
do
that
through
the
rolls
the
nice
thing
there.
A
Is
you
notice
that
that
ability
to
assign
users
to
rolls
this
UI,
you
don't
have
to
write
that
it's
part
of
our
portal
is
therefore
we
also
have
api's
that
you
can
use
in
powershell
or
in
in
microsoft
graph
to
make
those
assignments
as
well.
So
it's
you
don't
have
to
do
any
of
that
work
to
make
your
application
be
able
to
work
with
that,
because
we
do
that
part
as
well.
So
for
that
reason,
I
tend
to
suggest
rolls
a
little
bit
more
than
then
groups
because
of
these.
A
These
items
that
we
saw
already
looked
at
but
I
want
to
reiterate.
We
only
use
group
IDs
unless
the
group
is
synced
from
on-premise.
You
also
have
to
do
that.
Ui
that
says:
ok,
given
this
group
submitter,
here's
the
group
ID
I'm,
going
to
use
for
that,
so
you'd
have
to
have
groups
that
read
that
all
in
order
to
provide
that
functionality
and
if
you
are
using
groups,
we
limit
how
many
groups
can
show
up.
A
Okay,
so
provisioning
is
very
important
part
of
what
a
lot
of
of
our
customers
are
looking
for
today,
oh
I
see
there's
a
question
in
the
chat.
What
would
be
the
scope
if
I
use
static
consent?
I
mean
quickly
go
back
to
the
app
here
if
I
wanted
to
static
consent
for
this
application,
the
scope
is
the
applications
ID.
So
in
this
case
it's
this
skillet,
eight
to
nine
etc,
followed
by
the
flash
and
then
dot
default.
That
scope
says:
I
want
static
consent.
A
Okay,
so
going
back
to
the
presentation,
the
idea
of
provisioning
is
that
you
need
to
rely
on
the
directory
even
lie
to
business.
Apps
that
are
relying
on
the
directory
can
often
say
well.
I'm,
just
gonna
use
Microsoft
graph,
because
I
know
a
lot
about
this
directory.
I'm
just
gonna
go
ahead
and
and
and
and
find
the
information
I
need
out
of
the
directory
and
that's
a
great
choice.
It
does.
There
was
one
issue
there.
A
We
often
refer
to
this
as
sort
of
just-in-time
provisioning
and
that
as
soon
as
the
user
shows
up
you
go
and
learn
enough
about
them
through
something
like
the
Microsoft
graph
api's,
to
figure
out
your
profile
of
the
user.
For
your
application,
one
tricky
bit
there
is,
you
will
have
to
figure
out
when
a
user
disappears
from
the
organization
on
how
to
do
that,
so
that
you
can
do
that
with
something
like
say.
A
A
web
hook
and
Delta
query
on
users
so
that
you
can
see
that
the
user
changed
or
left
or
something,
but
it
does
require
more
consent
to
hire.
Consent
group
read
all
and
access
to
all
of
the
users
full
profile
and
so
on,
but
it
is
an
option,
especially
a
good
one,
for
line
of
business
apps
often
have
everything
pre
consented
for
them.
A
The
problem
is,
if
you
require
a
complex
onboarding
of
a
user,
it
can
be
a
little
irritating
the
first
time
I
saw
it
in
if
it
takes
a
bunch
of
time,
while
I'm
waiting
around
watching
something
spin
on
the
screen.
While
you
are
setting
up
that
that
that
ID,
that
additional
user
profile
for
me,
similarly
for
is
feeds
you
might
want
to
support,
not
just
Microsoft
identity,
but
also
identity
providers,
from
whatever
your
customer
may
be
running.
So
one
of
the
great
things
that
you
can
use,
therefore,
is
something
called
Azure
ad
automatic
provisioning.
A
So
what
will
happen?
Is
the
IT
firm
will
be
able
to
set
up
rules
that
say
as
soon
as
the
user
appears
in
this
tenant
I
want
you
to
tell
this
application
about
the
user
all
right,
so
that
all
of
that
can
happen
automatically
and
if
I
did
take
a
quick
look
inside
of
my
Tana
and
we
go
in
as
a
tenant
admin
I'll
go
to
enterprise
applications.
We
have
setup
in
this
particular
tenant.
A
The
the
Salesforce
application
for
automatic
provisioning,
so
here
is
one
of
the
items
here
is
I,
can
look
at
provisioning
and
see
that
Salesforce
is
set
to
automatic
instead
of
manual.
Wait
for
the
network
to
show
up
here
for
a
second
and
we
we
configured
how
what
credentials?
What
how
we
talk
to
Salesforce
that's
question
of
setting
up
how
we
can
make
that
connection.
We
also
configured
mappings
that
say
well,
given
that
Salesforce
is
looking
for
a
that's
says:
username
well,
take
that
from
you,
our
user,
principal
main
and
so
on.
A
So
we
set
up
default
mappings
for
you,
so
we
can
easily
determine
what
to
tell
Salesforce
or
what
to
tell
any
application
and
for
things
like
hey,
do
you
want
to
watch
when
users
are
created
or
updated
deleted?
You
know
what
what
operations
do
you
want
me
to
tell
this
application
about,
and
what
can
happen
here
is
for
things
like
hey.
When
does
this
user
leave
the
company?
It's
a
bunch
of
work
for
you
to
do
with
Microsoft
graphs,
certainly
doable,
but
work.
They
would
need
to
do
or
you
could
say
why?
A
Don't
you
tell
me
when
a
user
leaves
the
company
or
why
don't
you
tell
me
when
a
user
changes,
this
we're
also
lady
shouldn't,
have
this
functionality
anymore
and
the
simple
way
you
do
that
is
by
implementing
what
we
refer
to
as
a
skin
endpoint
skin
is
a
standard.
It's
not
our
standard,
it's
being
picked
up
across
identity,
so
not
only.
We
support
this
functionality
for
Microsoft
identities,
but
you
also
supported
it
across
the
board
for
everybody
else
as
well,
when
you
are
protecting
an
API.
A
Unlike
an
application,
api's
are
all
about
actually
looking
inside
and
inspecting
the
access
token,
we
do
use
jot
tokens
for
any
access
token
we
give
to
a
third
party
API
today.
So
if
you
develop
an
API,
you
can
expect
to
get
a
jot
token
from
us.
These
are
good
until
they
expire
unless
you
as
an
API
developer,
don't
implement
that
check,
in
which
case
they're
good
forever.
A
So
the
enforcement
of
protecting
an
API
all
relies
on
the
API
implementer,
looking
at
the
job
token
validating
at
first
for
its
signature,
etc,
and
then
looking
at
things
like,
when
does
the
the
token
expire
and
and
making
sure
that
that
is
honored
all
right,
so
you
can
validate
the
token
valid,
actually
calling
us.
In
fact,
it's
an
interesting
thing.
Api
is
that
are
protected
by
Microsoft
identity,
never
make
a
call
to
Microsoft
identity
right,
but
it's
important
that
you
do
the
token
validation
for
signing
make
sure
it's
to
your
API.
A
B
A
A
delegated
permission,
what
we're
going
to
tell
you
is:
who
is
the
user
we're
going
to
say
here
the
Scopes
that
the
app
has
been
authorized?
These
are
the
range
of
operation
as
the
application
has
been
authorized
to
perform,
and
if
it
has
a
user
role
or
groups,
we'll
have
those
defined
for
you
in
that.
In
that
token,
as
well,
if
it's
an
app
permission,
it
has
no
user
identity.
A
It
just
has
the
roles
for
the
app
which
represent
your
app
permissions
and
then,
of
course,
it
would
have
any
groups
or
user
roles
there,
as
well
so
for
services
that
just
the
app
permission
rules
for
services
make
sure
you
always
use
a
client,
credential
and
move
away
from
service
accounts.
We
did
a
lot
of
stuff
with
service
accounts
in
the
past
they're
very
troublesome
nowadays,
and
that
you
can't
turn
on
MFA.
You
can't
get
become
a
more
secure
environment
without
special
casing.
A
Every
application
that's
being
used
as
a
service
instead
of
a
user
now
I
do
know
that
there
are
some
older
API.
Is
that
don't
yet
support
app
permissions?
But
you
can
certainly
hopefully
work
around
that
and
move
toward
app
permissions
as
soon
as
you
can,
I
will
find
out
that
exchange
does
have
an
ability
for
you
to
run
a
PowerShell
script
so
that,
instead
of
axing
being
able
to
read
all
mail
in
the
enterprise,
you
could
read
specific
mailboxes
when
you're
securing
services
make
sure
you
use
certificates
instead
of
client
secrets,
secrets
worked.
A
Fine,
but
managing
secrets
is,
is
troublesome.
It's
just
a
string.
They
tend
to
get
checked
into
code
or
put
an
email
or
in
files
that
are
unencrypted.
We
prefer
set
certificates
because
the
management
at
least
exists
there.
And,
finally,
of
course,
if
you're
using
Azure
to
run
any
of
these
services
used
to
manage
identity
for
agile
resources,
that
way
your
developers
don't
have
to
do
any
secrets,
management
or
certificate
management
or
anything
else,
and
they
don't
have
anything
that
they
could
actually
lose.
So
there
are
no
secrets
to
lose
if
you
use
that
process.
A
Finally,
I
want
to
talk
about
protecting
your
apps.
Specifically,
we
are
seeing
attacks
that
are
targeted
specifically
at
applications
and
trying
to
break
those
applications.
For
the
first
thing,
for
example,
is
if
you
have
for
you
to
redirect
your
eyes,
but
this
is
the
address
you're
telling
us
to
send
your
token.
Make
sure
that
you
own
that
URI
that
we're
not
sending
it
somewhere
that
somebody
else
might
own
or
somebody
else
be
able
to
put
up
to
intercept,
make
sure
that
you,
you
you
own.
A
Those
redirects
make
sure
that
you're
keeping
your
list
well
maintained,
and
if
you
move
to
a
new
redirect
URI,
you
don't
leave
some
unused
or
unnecessary
reader
eye
hanging
out
there,
and
that
does
include
not
being
able
to
use
wildcards.
It
opens
all
kinds
of
different
security
holes,
which
is
why
we
don't
allow
their
usage
in
the
new
UI
and
and
v2
endpoints.
But
you
we
can
strongly
encourage
you
not
to
to
use
those
those
redirect.
Your
eyes
should
be
secure.
Uri
is
HTTPS,
etc,
so
that
they're,
secure
and
encrypted.
A
That
is
where
the
your
tokens
are
going
so
make
sure
that
that
is
what
you
provide
if
you're,
using
public
clients
or
or
clients
on
things
like
iOS
and
Android.
Primarily,
there
are
specific
platform
specific
to
our
eyes
for
you
to
use
and
they
enable
the
communications
between
the
default
browser.
That's
doing
your
your
collection
of
your
single
sign-on
and
signing
in
with
your
applications,
and
they
have
code
in
there
to
help
prevent
randomness.
A
If
you
have
an
isolated
web
page
in
here,
it
is
possible
for
you
to
use
a
very
specific
URI,
but
it
is
a
big
area
of
concern
from
us
to
make
sure
that
you
are
maintaining
and
handling
air.
You
eyes,
as
you
are
eyes
correctly.
Another
area
here
is
passwords
are
bad.
You
know
how
this
applies
to
apps
is
when
you're
using
client
secrets.
A
If
you're
going
to
use
client
secrets
instead
of
our
preferred
certificates,
our
managed
identity,
fragile
resources
make
sure
it's
a
strong
password.
There
was
an
ability
in
the
past
to
enter
in
weak
passwords
and
people
just
left
them.
We
have
seen
passwords
spray
attacks
against
applications,
so
make
sure
you
have
a
strong
unguessable
password
to
to
use
this
as
secret
key
again,
preferably
use
a
client
secret
credentials.
The
idea
behind
all
of
this
is
to
store
them
in
a
way
that
no
human
actually
has
to
touch
them
on
the
way
by.
A
A
A
In
the
back
of
your
mind
that
it
would
be
a
good
project
at
some
point
to
move
forward
from
a
Dell
and
V
1
into
M
cell
and
v2,
we
are
providing
a
number
of
upgrades,
a
guides
there
as
well,
so
I
apologize
I'm
a
couple
minutes
late
here,
but
that's
a
quick
look
at
some
best
practices
when
you
use
the
Microsoft
identity
platform.
I'll
stick
around
for
questions
and
I
do
appreciate
all
your
time.
Thank
you
very
much.
B
Thank
you
so
much
Kyle.
There
was
a
question
earlier
that
showed
up
with
a
delay
on
the
chat
window
from
dean
cross.
Are
there
any
tools
available
for
compliance
or
security
IT
pros,
so
that
they
can
use
to
evaluate
apps
to
confirm
that
they're
using
the
best
any
of
the
best
practices
that
you're
talking
about?
It's.
A
Something
that
worse
that
we're
starting
on,
but
we
don't
have
anything
packaged
up
yet,
but
we
are
starting
certainly
starting
to
look
at
what.
What
could
we
do
to
help?
You
find
some
of
this
information.
You
know
like
app
or
something
simple
like
apps,
that
don't
have
rotating
secrets
or
something,
but
it
is
something
we're
working
on
to
you
to
create
a
tool
for
that
right
now.
All
we
have
is,
you
know
the
scripts
that
are
out
there
or
the
scripting
languages.
B
Thank
you
feel
free
to
ask
any
other
questions.
If
not
thank
you
for
joining
us
today.
We
appreciate
you.
How
many
have
you
here,
hey
I,
have
one
more
question:
assuming
that
I,
let's
say:
I
have
a
front
end
and
the
back
end.
I
have
a
multitude
of
Micra
services
and
the
user
triggers
an
action
that
needs
to
basically
is
gonna
require
multiple
actions
on
user
behalf
across
many
micro-services.
B
A
Well,
it
depends
upon
a
lot
upon
the
design
of
your
micro
services
and
exactly
what
what
their,
what
their
different
logical
points
are.
I
mean
from
one
point
of
view
like
and
say:
well,
Microsoft
graph
just
happens
is
a
micro
service
right,
each
individual
workload
or
its
identity
or
our
exchange,
etc.
They
all
have,
you
know,
are
implemented
on
their
own.
They
have
all
the
different
time
spans
and
and
and
deal
with
in
the
interdependencies
we
use
one
API
family
for
all
of
Microsoft
graph
and
therefore
the
access
token
be
can
be
shared.
A
You
can't
share
an
access
token
if
they
go
by
different
API
identifiers.
So
if
it's
graphed
on
Microsoft
com
purses,
Kyle,
Microsoft
comm,
then
I
couldn't
possibly
share
that
access
token,
because
the
designers
have
said
these
are
two
separate
api's.
So
in
that
case
you
have
to
use
the
on
behalf
of
the
only
other
option
that
we
see
out
there
is
is
the
possibility
of
adopting
something
along
the
lines
of
a
trusted
sub
system.
Obviously
that
becomes
a
lot
more
harder
to
maintain
and
deal
with,
but
it
is
a
it
is
an
option.
A
So
what
you
have
to
look
at
is
you
know,
what's
the
right
logic
breakdown
of
these
API,
so
they
want
API
with
different
workloads
that
are
implemented
by
white
micro
services,
but
really
one
API,
in
which
case
access
tokens
are
the
same
or
is
it
really
did
a
whole
bunch
of
different
services
right
that
you're,
exposing
with
different
API
names,
so
that
might
dictate
one
top-level
choice
and
then
the
second
one
is
whether
or
not
what
are
the
inter
inter
dependencies
between
these
api's?
How
often
will
one
call
another?
A
You
know
if
they're
rapidly
calling
each
other
back
and
forth.
It
might
be
that
you
know
you
can
live
on
the
token
cache,
with
respect
to
how
long
they're
issued.
But
it's
a
question
of
where
your
your
throughput
concerns
I,
think
comes
up
for
me,
which
is
should
I
move
to
something
like
across
this
trusted
subsystem.
Well,
that
really
means
they're
only
calling
a
Const
each
other
in
a
very,
very
controlled
fashion,
or
do
I
go
with
a
series
of
different
access
tokens
because
they're
that
different,
how.
A
A
What
what
you
do
is
that
first
API
takes
the
access
token
it
was
given
and
its
own
client
credentials
goes
back
to
Microsoft
identity
and
says
I'd
like
an
access
token,
to
call
this
other
API,
please,
and
then
we
could
issue
that
on
behalf
of
token,
so
everything
happens
correctly,
so
that
the
second
API
that's
called,
doesn't
really
see
it
has
necessarily
meaning.
You
could
check
deeply
to
see
if
it
came
from
another
API,
but
it
sees
this
as
as
just
a
regular
API
call
to
itself
and.
A
It
gets
the
claims
that
the
that
API
designer
said
it
won't
they
need
so
the
two
claims
are
independent
of
each
other.
So,
for
example,
if
API
one
said
I
want
to
see
user
roles
for
this
an
API
and
API
two
to
didn't,
say
they
wanted
user
roles.
They
wouldn't
be
there.
But
if
you
API
two
said
I
want
to
see
groups,
they
won't
see
groups,
so
each
API
designer
decides
what
information
they
expect
to
see
in
the
tokens
they
get
ice.
B
A
A
A
C
A
A
C
A
C
Kyle,
so
my
question
is
I
mean
more
specific,
like
I.
Have
an
application
and
I
have
a
group
called
test
group
one
and
inside
that
I
have
a
nested
group.
This
group
too,
so
the
test
group,
one
I,
assigned
a
role
called
role
one.
So
if
the
user
inside
the
test
group
2,
which
is
a
nested
group
if
signed
in
to
an
application,
so
will
that
authentication
succeed?
Oh
we.
A
C
C
A
C
C
A
C
A
Actually
depends
a
we.
We
would
I've
seen
us
return
both
in
both
cases.
So
it's
something
you
have
to
look
out
for,
but
when
you
look
at
the
and
in
so
actually
to
be
fair
in
the
in
the
scopes,
so
here
you
will.
You
can't
occasionally
see
that
it's
asking
for
default,
but
most
of
the
time
we
were
pretty
good
about
telling
you
all
the
individual
scopes
that
it's
doing.
Okay,.
C
A
C
I
have
gone
through
this,
but
is
there
I
mean
when,
when
I
was
using
a
doll,
there
was
a
step-by-step
guide
line
on
how
to
migrate
an
existing
app
to
a
doll
like
you
have
to
use
this
library,
and
if
there
is
any
version
mismatch,
you
have
to
use
this
one.
So
there
was
a
step-by-step
guidance
so
like
that,
is
there
any
guidance
on
library?
I
mean
how
to
integrate
that
library?
If
you
are
already
using
at
all
I,
don't.