►
From YouTube: Microsoft identity platform community call-May 2020
Description
In May's Microsoft identity platform call, Navya Canumalla went into detail on MSAL Java and Python, including an overview, supported scenarios and calling patterns. Quickstart demo, token cache and ADAL to MSAL migration.
View presentation deck https://aka.ms/AA8kgjl
Resources:
MSAL Java https://aka.ms/msaljavadocs
MSAL Python https://aka.ms/msalpythondocs
Stay connected
Twitter https://twitter.com/microsoft365dev
YouTube https://aka.ms/M365DevYouTube
Blogs https://aka.ms/M365DevBlog
A
Good
morning,
everyone,
my
name-
is
na
vehicon
Amala
and
I'm,
a
program
manager
on
the
Microsoft
identity
platform,
specifically
working
on
authentication,
SDKs
and
developer
experiences.
Today,
I'll
introduce
you
to
the
Microsoft
authentication
libraries,
also
known
as
emcell
for
Java
and
Python
applications
and
show
you
how
to
quickly
get
started
with
them.
A
Let's
take
a
look
at
the
agenda.
I'll
start
with
the
brief
overview
of
emselves
and
the
benefit
followed
by
the
supported
scenarios
and
common
calling
patterns
in
Java
and
Python
application.
I'll
show
you
a
demo
of
the
QuickStart
experience
to
get
a
sample
app
up
and
running.
I'll
talk
about
token
caching
in
advanced
scenarios.
A
A
The
Microsoft
authentication
library
is
basically
an
authentication
SDK
that
enables
your
applications
to
authenticate
using
Microsoft
identities
such
as
work
accounts,
organizational
accounts
or
personal
accounts,
and
it
also
issues
access
tokens
that
allows
you
to
access.
Api
is
secured
on
the
Microsoft
identity
platform.
A
A
Another
benefit
that
emcell
provides
is
that
it
is
mainly
a
token
acquisition
library.
It
is
meant
to
be
used
in
client
applications
to
get
tokens
so
that
you
can
access
api's
here.
Client
applications
refer
to
any
kind
of
application
that
is
accessing
some
kind
of
a
back-end
service
or
an
API,
so
think
of
web
apps
desktop
apps
and
such
with
M
cell.
You
can
acquire
tokens
not
just
for
a
user's
identity,
but
also
as
the
applications
identity
based
on
your
scenario.
A
M
cell
provides
a
token
cache
and
it
takes
care
of
maintaining
this
cache
and
refreshing
the
token
before
they
expire
recently.
At
the
beginning
of
this
year,
we
announced
the
general
availability
of
M
cell
for
Java
and
M
cell
for
Python
libraries,
which
will
support
different
types
of
applications
that
can
be
built
in
Java
and
Python
ecosystem.
A
All
of
the
code
for
M
cell
is
open
source.
You
can
find
themselves
eateries
on
for
Java
and
Python
on
github,
do
go
check,
check
out
these
repositories
and
you
will
find
the
usage
and
wiki's
to
help
you
get
started.
If
you
have
any
feedback
and
questions
feel
free
to
open
issues
on
our
github
repositories,
we
actively
look
at
them
and
triage
them.
A
M
cell
Java
is
available
in
the
navin
repository
and
it's
distributed
under
the
name
of
M
cell
for
J
package.
You
can
install
this
package
by
adding
the
dependency
to
your
applications,
pom
dot,
XML
file.
If
using
maven,
if
you're
using
Gradle,
you
can
also
add
the
dependency
in
your
build
or
cradle
em
cell
Python
is
distributed
through
pi
pi,
and
you
can
install
this
package
using
the
PIP
installer
for
python.
A
Let's
talk
a
little
bit
about
the
supported
scenarios.
I
will
go
into
more
detail
in
further
slides,
so
Java
and
Python
applications
can
be
built
on
different
types
of
platforms
and
they're
there
of
different
varieties
of
applications.
Emcell
provides
support
for
these
emcell
for
Java
and
MSR
for
Python
can
be
used
to
build
application
on
the
Windows
Linux,
as
well
as
Mac
OS
platforms.
A
The
different
types
of
application
scenarios
supported
today
are
web
apps
desktop
apps,
like
apps,
that
run
in
the
operating
system
like
Windows,
Linux
and
Mac
OS
daemon
apps,
which
are
like
background
services
or
jobs
running
in
the
console
applications
without
a
browser,
for
example
IOT
apps
and
web
api's
in
the
core
object
model,
emcell
Java
and
emcell
Python
modeled
their
application
types
based
on
the
auth
client
definition,
namely
confidential
clients
and
public
lands.
The
confidential
clients
are
applications
that
run
on
servers
and
are
considered
difficult
to
access.
A
As
a
result,
they
are
secure
by
nature
and
are
capable
of
keeping
application
secret.
Secure
web
apps,
web
api's
and
services
or
daemon
apps
running
on
the
web
are
considered
confidential
trends
in
emcell.
You
can
create
an
instance
of
the
confidential
client
application
class
by
using
a
distinct
client,
ID
and
client
secret
public
lines
are
applications
that
run
on
devices
or
desktop
computers.
A
These
applications
are
not
to
be
trusted
with
maintaining
application
secret,
so
they
need
the
presence
of
an
authenticated
user.
In
order
to
make
secure,
Web
API
cons
in
M
cell,
you
can
create
an
instance
of
the
public
land
application
class
with
a
distinct
client
ID,
as
a
minimum
configuration
one
of
the
key
API
is
M
cell
provides
is
the
acquire
token
method.
These
methods
love
you
to
get
tokens
for
api's
in
different
application
scenarios.
We
will
look
at
the
details
of
these
application
scenarios
and
they're
calling
patterns
in
some
time.
A
B
A
B
A
So
there
I
see
that
there
are
more
than
just
Java
developers
that
are
like
dotnet
and
angular,
so
some
of
these
topics
would
still
apply
to
dotnet
as
because
we
on
the
M
cell
SDKs
try
to
keep
the
api's
consistent
as
well
as
keep
the
flows
that
are
implemented
the
same
across
these
application
scenarios.
So
some
of
this
stock
still
applies,
but
we
will
be
seeing
api's
and
code
very
specific
to
Java
and
Python.
A
So
thanks
Steven
for
reading
those
out
moving
on
we'll
go
a
little
deeper
into
the
application
scenarios
that
I
mentioned,
starting
with
the
web
app
scenario,
so
the
web
apps
are
considered
as
confidential
clients
in
themselves.
This
is
because
they
can
run
on
a
server
and
store
app
secret
security.
A
Consider
a
web
app,
for
example,
as
an
employee
dashboard
where
you
are
signing
in
employees
of
the
organization,
and
you
want
to
access
some
data
from
api's
for
this
employee.
So
here
is
a
some
of
the
code
that
you
would
write
in
Java
and
Python
M
cells
to
get
an
access
token
for
a
web
app
to
call
a
Web
API
emcell
implements
the
authorization
code
flow
in
this
flow.
An
authorization
code
is
obtained
when
the
user
signs
in
and
then
this
code
is
exchanged
for
an
access
token
to
call
the
Web
API.
A
Here
the
token
is
representing
the
identity
of
the
signed-in
user,
so
in
M
cell
you
would
start
with
instantiating
a
confidential
client
application
with
a
client,
ID
and
a
client
secret.
You
can
also
provide
an
authority
and
authority
here
is
basically
the
endpoint
of
which
includes
the
tenant
in
a
surety
where
you
want
to
authenticate
users
from
so
that
you,
you
are
optionally,
you
a
belated
string
here,
but
at
the
base
configuration
you
would
provide
a
client
ID
and
a
client
secret
to
instantiate
the
confidential
client
application.
A
And
then
you
can
set
up
the
authorization
code
parameters
for
the
flow
and
called
a
qui
token
method.
So
in
M
sense
we
follow
ApS
that
are
idiomatic
to
the
language,
so
in
M
Sal
Java
we
use
a
build
of
pattern,
whereas
an
M
cell
Python,
you
will
see
that
there
are
multiple
acquire
token
methods
based
on
the
flow.
However,
we
use
very
similar
constructs
and
the
core
object
model
are
close
so
so
that
it
is
seamless
for
you
to
work
with
multiple
themselves
and
multiple
languages.
A
A
You
can
see
your
existing
created
applications
but
I'm
going
to
start
with
the
new
app
registration,
and
let
me
give
it
the
name
like
some
name,
my
web
app
I'm
going
to
select,
you
can
select
the
different
types
of
account.
You
want
to
support.
Suppose
you
want
to
sign
in
users
only
within
your
current
azure
ad
directory.
You
can
do
that
if
you
want
to
expand
the
access
to
more
than
just
your
ad
accounts,
but
also
to
personal
or
any
Microsoft
identity.
A
A
So
here
you
will
find
the
detail,
QuickStart
steps
to
configure
and
run
your
Python
application.
But
the
cool
thing
is
here:
you
can
just
click
this
button
and
the
portal
experience
will
set
up
some
of
these
configuration
for
you,
so
over
here
I
am
going
to
be
adding
the
redirect
URI
for
this
web
application
and
it's
going
to
also
create
the
client
secret
for
me,
so
that
I
don't
have
to
go.
Do
that
on
another
tab
and
also
set
some
of
the
permissions
for
accessing
an
API.
A
A
It
gives
you
a
chance
to
note
down
the
client
secret
if
you
wish
to,
but
you
don't
necessarily
have
to
at
this
point,
because
it
does
configure
it
in
the
application.
But
if
you
want
to
use
the
secret
later,
you
might
want
to
note
it
down.
So
it
says
application
is
configured.
The
next
step
is
just
found
it
to
download
the
code
sample
so
quickly,
download
that
okay,
that's
downloaded
so
I'm
going
to
open
this
and
just
move
this
into
my
directory.
A
Okay,
so,
as
you
can
see,
the
client
ID
has
been
set
and
even
the
client
secret,
and
we
have
also
the
the
permissions
here
which
are
set
as
the
scope
parameter.
So
some
of
this
has
already
been
configured,
including
the
redirect
path,
and
this
was
all
set
when
we
created
that
when
we
click
that
button
in
the
portal
experience,
okay,
so
next
step
is
to
basically
just
copy
the
command
to
install
the
required
packages.
A
A
Okay
and
now
I'm
getting
a
consent
screen
after
I
log
in
to
consent
to
the
permissions
that
we
are
trying
to
access
so
in
this
case
I'm
trying
to
read
some
of
the
profile
information
from
Microsoft
graph
API
that
that
was
the
permission
that
was
set
for
this
application.
So
it's
a
loving
me
as
the
user
to
give
my
consent
to
that.
A
So
do
that
and
there
you
are
signed
in
it
says,
welcome
Navi
otter,
so
it
displays
my
username
here
so
that
shows
that
I'm
signed
in
now
I
can
go
ahead
and
make
the
graph
API
call.
So
let
me
do
that
and
there
it
returns
the
results
from
the
graph
API
call,
which
was
basically
to
list
some
of
the
users
in
this
demo
tenant.
So
here
it
lists
some
of
the
information
about
the
users
in
the
tenant
service
that
simple
to
get
it
up
and
running.
Oh
yeah,.
A
Yes,
this
is
an
app
very
new.
This
is
a
QuickStart
experience.
Revenue
only
created
this
app,
but
definitely
it
you
can
use
it
in
an
existing
app.
What
you
would
need
to
do
is,
let
me
just
show
you
the
yeah,
so
what
you
would
need
to
do
is
basically
install
the
here.
We
have
a
file
with
all
the
packages,
but
basically,
if
you
want
to
just
start
with
Python
app
for
M
cell,
you
can
just
install
pip
install
em
cell,
and
then
you
will
have
the
M
cell
package
installed
with
the
latest
version.
A
You
would
have
to
basically
import
the
M
cell
package
into
your
app
and
then
configure
some
of
the
confidential
client
application
if
it's
a
web
up
in
this
case
with
the
client
ID
and
the
client
secret,
which
is
already
configured
in
this
app.
But
you
would
basically
set
those
as
the
conflict
parameters
in
your
configuration
file
and
then
pass
it
into
this
confidential
client
application
class
to
instantiate
it
once
you
have
that
you
can
call
the
different
types
of
acquire
token
calls
and
methods.
A
So
in
this
case,
if
you
are
a
web
app-
and
you
want
to
do
this
for
a
user,
you
can
call
the
acquire
token
or
using
the
earth
code.
So
you
can
that's
I
actually
included
in
this
request
here,
but
you
can
use
the
different
acquire
token
methods
and
I'll
go
a
little
more
detail
into
the
calling
pattern
of
emcell
in
the
further
slight
hope
that
helps
answer
the
question
about
what
to
do.
If
you
already
have
an
existing
app
there.
B
A
Sure
so
specific
to
M
cell
is
just
the
M
cell
SDK.
We
are
at
I,
think
version
1.3,
which
is
the
latest
right
now,
but
yeah
you
can
provide
your
version
number
our
range.
These
are
the
things
here
are
more
for
the
framework
that
this
web
app
sample
is
using.
We've
used
flask
here
and
reviews
request,
but
you
can
change
that
based
on
what
is
applicable
to
your
application,
but
the
key
thing
required
for
M
cell
is
just
an
answer
package.
A
A
That's
a
great
question
so,
like
I
mentioned
before
emcell
is
a
token
acquisition
library
and
it
provides
you
some
of
the
api's
to
get
the
tokens
like
the
aqua
token
methods,
and
it
is,
it
can
be
used
with
the
Microsoft
identity
platform.
Specifically
now,
as
far
as
I
understand
spring
security
is
also
integrated.
It
is
possible
to
integrate
the
spring
security
with
the
Microsoft
identity
platform.
However,
you
would
have
to
configure
some
of
the
details
like
the
endpoint
that
you
need
to
provide
to
the
spring
security
for
the
Microsoft
identity
platform.
A
A
A
B
A
Yeah,
these
are
all
great
scenarios
and
I'm
happy
to
hear
these,
because
these
were
also
on
top
of
our
mind
for
the
next
set
of
samples
we
want
to
build.
So
it's
good
to
hear
that
this
is
what
everyone
is
interested
in.
So
thank
you
for
providing
that
feedback,
so
I'm
going
to
move
on
to
some
of
these
other
scenarios
and
quickly
go
through
some
of
the
details
here.
A
So
this
doesn't
require
an
user
to
be
present,
but
this
application
would
also
be
modeled
as
a
confidential
client
application,
since
it
runs
on
a
server
and
can
be
securely
maintaining
a
secret.
So
the
pattern
is
very
similar.
You
create
a
confidential
client
application
object
and
then
call
the
core
token
method.
By
setting
up
some
of
the
client
credential
parameters,
so
in
this
scenario
the
emcell
uses
a
client
credential
worth
flow.
This
flow
basically
uses
the
applications,
client,
ID
and
client
secret,
and
identifies
itself
to
the
identity
platform
to
get
a
token
for
the
API.
A
The
next
scenario
we
have
is
like
a
desktop
app
scenario,
so
desktop
apps
are
both
console
applications
as
well
as
some
of
the
native
applications
that
are
in
the
operating
systems
like
Linux,
Windows
and
Mac
apps.
In
this
scenario,
there
are
a
few
different
flows
that
can
be
used
but
I'm
covering
the
most
common
flow
and
the
most
recommended
flow
here,
which
is
using
the
authorization
code
flow
again.
This
is
very
similar
to
the
confidential
client
authorization
code
flow
and
a
quick
note
here.
A
The
desktop
apps
are
generally
public
client
applications
because
they
are
systems
which
are
their
applications
that
are
native
to
the
systems
which
are
openly
accessible
and
hence
they
are
not
considered
freely,
secure
and
able
able
to
maintain
secret.
So
you
would
here
instantiate
a
public
line,
application
instance
and
then
call
the
authorization
code
flow.
A
One
key
difference
between
this
and
the
confidential
client
flow
is
that
there
are
some
add
added
security
mechanisms
for
the
public
line
flow,
where
we
use
a
proof
of
e
for
code
exchange,
which
is
basically
like
a
cold
verifier,
but
these
are
more
covered
in
the
implementation
of
M
cell
and
you
don't
have
to
worry
about
it
as
developer
using
the
API.
You
just
need
to
set
up
a
public
line
application
instance
and
invoke
the
authorization
code
flow.
A
Another
type
of
application
that
ends
I'll
support
is
applications
without
browsers.
So
what
does
that
mean?
These
are
mainly
headless
applications
of
applique
without
a
web
browser
or
an
interface
where
a
user
can
interact
for
completing
the
authentication
most
of
the
user,
interactive
flows.
They
require
the
user
to
authenticate
in
our
web
page
with
the
login
information.
So
if
you
have
applications
like
IOT,
apps
or
another
example
is
like
and
a
command
line
app,
which
doesn't
have
an
interface,
you
can
use
this
flow
in
those
scenarios.
A
So
here
we
use
the
device
code
flow,
which
basically
happens
in
two
steps:
it
when
you
initiate
the
device
code
flow,
the
user
is
presented
with
a
URL
and
a
code
which
is
issued
by
our
ready.
So
you
can
take
the
user
is
asked
then,
to
take
this
code
and
enter
it
at
the
URL
specified
in
another
device,
such
as
a
smartphone
for
example.
A
So
they
can
open
their
web
browser
in
a
smart
phone
and
enter
the
code
once
they
enter
the
code
and
complete
the
authentication
flow
successfully
like
they
will
be
presented
with
the
usual
consent
screen
and
stuff.
So
once
they've
completed
the
authentication
they're
successfully,
then
they're
through
a
back-channel,
the
EM
cell
SDK
gets
an
access
token
issued
from
azure
ad
for
this
user
and
after
that
the
application
can
call
the
API
using
that
access
token.
So
this
is
another
flow
that
is
supported.
A
One
point
I
would
like
to
mention
which
I
think
I
missed
in
the
previous
scenario,
in
the
desktop
scenario,
is
that
there
are
some
other
flows
that
are
used
in
desktop
scenario
such
as
integrated
windows,
authentication
and
the
username
password
flow.
The
integrated
windows
authentication
flow
is
very
specific
to
Windows
machines
and
it's
mainly
implemented
to
take
advantage
of
a
domain
joined
machine
so
that
if
there
is
a
domain
joint
identity
that
can
be
leveraged
to
get
to
for
the
application
without
additional
user
interaction,
the
user
name/password
flow
is
not
exactly
a
recommended
flow.
A
That's
because,
in
this
flow
the
application
would
need
to
obtain
the
password
of
the
user,
and
that
is
highly
discouraged
to
applications
to
take
passwords
and
store
them
or
or
even
just
expose
the
passwords
to
the
application.
So
in
this
case,
we
don't
recommend
using
username
password
flow.
However,
it
takes
this
for
some
very
specific
and
special
scenarios,
such
as
DevOps
scenarios,
so
just
a
little
bit
about
those
are
other
flows
that
are
possible
in
the
desktop
Navya.
B
A
A
The
resource
owner
flow
is
just
another
name
for
the
user
name/password
flow.
Basically
here
the
resource
owner
is,
is
the
OAuth
terminology
for
therefore
referring
to
a
user,
so
a
resource
owner
would
be
represented
using
a
username
and
password.
So
it's
the
same
flow.
So,
yes,
we
do
support
it,
but,
as
I
said,
we
do
not
recommend
using
it
in
your
main
stream
scenarios
and
only
use
it
in
some
really
special
cases
like
DevOps
scenarios
are
where,
where
there
is
a
real
need
for
resource
owner,
hope
that
helps.
A
Okay,
moving
on
one
of
the
last
scenarios
that
I
want
to
talk
about
is
the
Web
API
scenario,
so
where
baby
is
are
interesting
because
they
have
a
bunch
of
different
scenarios.
We
already
touched
upon.
You
can
get
tokens
for
a
web
api
to
call
another
downstream
their
baby.
I-
and
that
is
the
scenario
that
emcell
focuses
on,
because
it's
a
token
acquisition
library.
So
in
this
case
you
have
an
API
like
a
back-end
service
or
an
API,
which
already
has
received
an
access
token
from
an
authenticated
client.
A
So
now
it
needs
to
take
this
access
token,
but
call
another
downstream
API.
In
order
to
do
that,
we
provide
the
on
behalf
of
flow
in
this
flow.
You
pay,
you
use
the
access
token
received
to
exchange
for
another
new
access,
token
specific
to
the
downstream
Web
API,
so
this
flow
works
in
the
context
of
a
user's
identity
and
again,
where
BPA's
are
also
confidential,
client
application.
So
you
would
need
to
set
up
the
confidential
client
with
the
client,
ID
and
the
client
secret,
so
that
is
the
on
behalf
of
flow.
A
A
Okay,
please
feel
free
to
keep
posting
your
answers
in
the
chat
window.
I
am
going
to
quickly
move
on
to
the
next
section,
which
is
I
mentioned.
That
I
would
talk
about
a
recommended
pattern,
especially
when
you
use
M
cell
in
user
interaction
scenarios.
So
in
these
scenarios
you
want
to
avoid
repeated
authentication,
prompts
to
the
user
and
want
to
optimize
for
that
as
much
as
possible
and
M
cell
provides
an
API
called
acquire
token
silent.
So
you
can
acquire
token
silently
using
this
method.
A
What
it
means
to
acquire
token
silently
is
that
when
you
call
this
method,
M
cell
checks
the
cash
for
a
token
that
exists
for
this
authenticated
user.
If
there
is
a
token
it
returns
it,
and
if
there
is
no
token-
or
there
is
a
token
that
is
about
to
expire,
it
will
even
do
a
refresh
and
return
that
token,
all
in
the
background
like
without
prompting
the
user.
A
But
for
any
reason,
if
this
silent
method
fails,
then
of
course
you
will
need
to
handle
that
and
invoke
and
interactive
one
of
the
interactive
token
acquisition
method
which
will
again
prompt
the
user.
So
that
is
a
recommended
pattern,
especially
in
web
apps
and
interactive
flows,
and
you
can
see
this
is
provided
both
by
himself
Python
and
Java,
and
most
of
our
M
cells
have
this
pattern.
So
that's
one
pattern
that
I
just
wanted
to
mention
as
a
best
practice
in
your
application.
A
So
we
just
poke
about
the
token
cache,
so
I
will
quickly
cover
a
little
bit
about
the
token
cache
the
token
cash
provided
by
himself
and
himself
Python
or
both
in-memory
token
cache,
and
they
last
for
the
duration
of
the
session.
So,
during
the
silent
token,
acquisition
that
I
just
spoke
about
and
Searle
will
check
for,
in
the
token
cache,
if
there
is
a
token
that
can
be
used
for
this
user
account
and
it
also
Maps
the
token
cache
by
the
users
account
if
there
is
no
token
available,
we'll
throw
a
failure.
A
But
if
there
is
a
token,
but
it's
close
to
expiration,
it
does
a
refresh
of
the
token
and
makes
a
request
to
renew
the
token
out
of
the
box.
The
token
Kashian
emcell
does
not
provide
serialization
and
a
persistent
token
cash.
However,
emcell
Java
and
M
cell
Python
provide
interface
which
allows
you
to
implement
custom
serialization
in
your
application.
A
If
you
choose
to
persist
it
between
different
application
instances,
also
note,
we
are
recently
developing
some
libraries
further
called
extension
libraries
for
Java
and
Python,
which
provides
secure
mechanisms
to
do
some
of
this
token,
serialization
and
persistence
across
multiple
platforms
like
Windows,
Linux
and
Mac.
So
do
check
out
these
extension
libraries
they're
an
early
stage,
but
you
can
definitely
check
them
out
and
we
will
be
providing
more
samples.
I
heard
that
as
a
request,
so
we
have
we've
noted
that
we
will
be
providing
more
samples
around
token
caching.
Soon.
A
Yeah,
so
that
that's
the
great
question
so
I
can
mention
that
is
all
taken
care
of
by
himself
for
you
as
long
as
you're,
using
the
pencil
token
cache,
you
don't
really
have
to
do
any
of
the
mapping
of
the
token
cache
for
multiple
access,
tokens
and
user
accounts.
All
of
that
is
handled
by
the
ensel
SDK
it
will.
It
has
a
cache
format
where
the
keys
are
mapped
based
on
the
user
account
and
a
bunch
of
different
attributes
which
include
the
different
access
token
for
api's,
as
well
as
the
user
accounts,
but
yeah
you.
A
It
does
not
give
you
the
persistence
out
of
the
box,
which
you
will
have
to
implement
you
like
into
a
file
system
or
into
a
reduce
cache,
but
definitely
you
don't
have
to
implement
all
the
mechanics
of
caching,
if
that
makes
sense,
that's
taken
care
of
by
himself.
So
that's
a
little
bit
about
the
token
cache.
We
can
definitely
think
of
more
questions
and
we
will
try
to
address
them
at
the
end.
A
The
last
section
I
want
to
talk
about
is
migrating
to
the
mcl
SDK.
So,
for
those
who
are
not
aware,
we
had
the
aedile
SDKs
before,
which
are
also
authentication
SDKs
for
the
Azure
Active
Directory,
and
these
were
used
in
a
lot
of
applications,
but
they
were
the
previous
set
of
libraries.
Today
we
are
doing
all
feature:
development
and
investments
in
the
mal
SDKs.
So
if
you
are
an
application
that
is
using
a
DES,
we
highly
recommend
and
that
you
move
your
applications
to
emcell
and
migrate
at
your
earliest
possible.
A
We
are
supporting
and
maintaining
a
diol
SDKs,
but
they
are
mostly
in
maintenance
mode
and
no
feature
development
is
happening
there,
so
it
is
highly
recommended
for
you
to
update
to
end
to
get
the
latest
innovation.
Apart
from
that,
em
cell
also
gives
you
some
further
benefits,
so
I
will
cover
some
of
the
key
differences.
You
want
to
note
between
needle
and
himself
when
you're
migrating
your
application.
One
of
the
key
differences
is
the
use
of
scopes.
A
A
So
scopes
are,
are
nothing
but
a
list
of
strings
which
are
representing
the
resource
and
the
permissions
associated
with
that
resource
that
you
want
to
request
the
token
for
so
you
would
need
to
specify
the
scopes
as
a
parameter
and
most
of
them
sell
api's,
which
you've
also
seen
a
little
bit
before.
Another
key
difference
is
in
Adel.
The
core
object
was
the
authentication
context
class.
This
represented
your
connection
with
of
the
application
to
Azure
Active
Directory.
A
A
The
other
important
point
is
that
emcell
introduces
the
accounts,
object,
so
Adel
had
an
user
class,
but
emcell
introduces
a
concept
of
account
where
a
single
user
can
have
multiple
accounts,
so
they
can
have
more,
not
more
accounts
with
different
Microsoft
identities,
for
example,
a
work
account
or
a
personal
account
can
represent.
You
can
be
there
for
the
same
user,
so
in
ensel.
You
have
the
benefit
of
this,
because
you
can
now
sign
in
multiple
accounts
into
your
application
and
have
the
experience
of
cashing
and
all
the
benefits
for
both
these
type
of
accounts.
A
So
that
is
a
new
thing
in
M
cell.
Another
aspect
with
respect
to
tokens
cashing
and
token
refreshing,
is
that
in
a
dial,
the
Refresh
tokens
were
all
exposed
to
the
developer
so
that
the
developer
could
go
and
implement
the
caching,
but
that
we
just
touched
upon
that
briefly
before
is
now
in
M
cell.
It
takes
care
of
all
the
token
caching
and
all
the
refreshing
of
tokens
for
you,
and
this
is
considered
more
secure
as
well.
So
we
do
not
expose
refresh
tokens
for
added
security.
A
Instead,
we
do
provide
the
interfaces
where
you
can
purchase
the
cash
and
serialize
the
cache,
but
it
handles
all
the
caching
mechanisms
and
refreshing
mechanisms
for
you.
Additionally,
M
cell
is
also
providing
you
an
API
which
will
allow
you
to
easily
migrate
the
Refresh
tokens
that
you
acquired
with
a
dell.
Previously,
it
will
allow
you
to
migrate
those
to
them,
sell
token
cache
format.
This
will
help
to
make
them
update
smoother
for
your
users
and
avoid
unnecessary,
prompts
and
breaking
experience
for
the
users
as
well.
A
So
that's
another
thing
that
M
cell
provides
that
you
can
take
advantage
of
today
to
update
your
application
for
more
detailed
migration
topic.
You
can
follow
the
migration
guide
in
our
Doc's
that
I've
mentioned
before,
and
you
can
see
how
to
update
your
apps
to
the
sell
SDKs
so
with
that
I.
That's
where
I
will
stop
and
open
it
up
for
more
questions
and
discussions.
So
if
there
are
any
questions
in
the
chat
window,
please
can
you
read
it
out
Steven
or
yeah.
B
B
A
question
right
now,
which
I'm
gonna
try
to
explain
so
I,
read
it
high
level
first,
so
that
this
person,
this
person,
is
asking
about
the
different
conventions
talking
about
scopes,
claims
and
roles
in
different
scenarios,
and
it
feels
it's
a
little
bit
confusing.
Scopes
are
presenting
in
AD
under
the
application
in
the
azure
portal,
claims
are
illustrating
the
judge,
MS
and
roles
in
a
Sree,
deep
and
not
POC.
So
here.
A
This
is
a
good,
very
good
question,
and
there
is
a
lot
of
ambiguity
here,
but
I
will
try
my
best
to
address
some
of
this.
So
scopes
are,
as
I
mentioned,
in
the
Microsoft
identity
platform.
We
refer
to
scopes
as
a
combination
of
the
Web
API
or
the
resource,
the
API
ID
or
API
URL,
with
the
specific
permissions
for
that
API.
So
one
example
of
that
is,
if
you
take
the
graphic
Microsoft
graph
API,
you
can
think
of
it
as
like.
A
Graphed
at
microsoft.com
is
the
API
URL,
followed
by
user
dot,
read
or
mail
dot
read,
which
are
the
scope
which
are
the
permissions.
So
a
combination
of
this
is
considered
as
the
scope
for
the
API,
and
these
are
passed
in
the
access
token
that
is
returned
to
you
from
Azure
ad,
so
that
you
can
that
these
scopes
are
checked
by
the
API
is
to
give
you
access
to
data
now
coming
to
claims.
These
are
some
of
the
informations
that
come
in
the
ID
token.
A
Specifically,
so
claims
are
basically
the
the
protocol
terminology
for
some
basic
information
about
the
users,
identity
or
replicas.
In
the
the
ID
token,
concept
comes
mostly
in
the
context
of
an
authenticated
or
signed
in
user,
so
azure
ad
also
issues
ID
tokens
when
your
user
signs
in
which
contains
some
basic
information
about
the
user,
like
username,
they're,
first-name
lastname,
some
email
or
phone
number,
some
of
the
basic
information
these
claims,
you
can
also
configure
them
to
add
more
additional
claims
in
the
platform,
but
that
would
have
to
be
configured
as
explicitly
by
your
admin.
A
So
that
is
what
claims
refers
to
and
I.
It's
mostly
a
concept
coming
from
the
open,
a
deep
root.
Now
the
third
part
was
about
roles.
So
roles
are
more
about
giving
authorization
to
a
specific
set
of
like
access
restrictions
to
a
specific
group
or
set
of
users.
So
you
can
assign
roles
to
users
or
applications
in
the
Microsoft
identity
platform.
This
would
again
have
to
be
configured
on
the
tenant
or
through
the
usher
portal
and
once
you've
configured
that
you
can
get
these
rules
as
then
you're
making
request.
Sir.
A
There
are
different
ways
to
get
this
role
information
and
you
can
incorporate
that
in
your
decisions
about
authorizing
access
to
your
applications.
So
when
a
user
authenticate,
you
can
get
some
information
about
their
role
in
addition
to
their
identity
and
make
a
decision
whether
you
want
to
let
them
access
the
application.
So
like
an
admin
role
or
already
just
a
reader
role,
you
can
have
these
different
rules
defined
now
the
ways
to
get
these
roles.
There
are
different
ways:
I'll
just
briefly
touch
upon
them.
B
Yes,
so
we
have
one
minute
left
and
a
couple
questions
I,
don't
know
if
we'll
get
to
both
of
them,
but
also
please
take
some
time
to
fill
out
the
post-event
survey
and
really
appreciate
it.
If
you
do,
that
will
be
helpful
for
us
in
the
future.
So
one
question
real
quick
is
a
client
class
client,
ID,
plus
secret
method,
uses
up
users,
application
permissions
which
which
require
a
very
high
privilege
and
cannot
be
granted
to
every
active
development.
What
is
the
best
way
to
allow
a
demon
app
with
this
permission
mode?
That's.
A
A
great
question-
and
that
actually
reminds
me
I-
wanted
to
mention
that
you
not
only
can
use
client
secret
and
the
client
credential
flow
that
I
talked
about.
You
can
even
have
certificates.
So
one
option
is
you
create
a
client
certificate
in
your
system,
and
that
can
be
that
is
actually
recommended
for
production.
Apps
is
to
create
a
client
certificate
now
to
address
the
question
specifically
about
having
more
secure
option.
Yes,
you
can.
A
We
do
have
the
concept
of
managed
identities
where
you,
as
the
application
owner,
don't
have
to
manage
either
client
secrets
or
client
certificates,
and
you
can
make
them
more
secure
by
not
having
to
manage
these
credentials
and
let
the
system
manage
it
for
you
and
that's
what
managed
identities
provides.
However,
a
quick
note
here:
we
do
not
support,
managed
identities.
Integration
in
emcell,
specifically,
we
do
have
other
SDKs
called
Azure
SDKs,
where
you
can
use
managed
identities
and
our
SDKs
do
leverage
emcell
under
the
hood.
A
B
A
So
this
is
where
the
on
behalf
of
flow
would
help.
So
if
you
have
one
API,
I'm
assuming
it
has
already
received
some
token
from
an
authenticated
client.
So
the
on
behalf
of
flow
works.
When
you
have
a
authenticated
user
in
a
client
and
you
have
called
a
back-end
API
and
now
this
API
wants
to
call
another
API
and
they
can
have
different
client
IDs
and
seek
results
actually
how
it
should
be.
A
But
if
you
want
to
call
the
other
API,
you
again
need
to
obtain
an
access
token
in
this
current
API
and
that's
exactly
what,
on
behalf
a
flow
allows
you
to
do
you
just
provide
that
access
token
that
you
just
received
to
this
flow
and
then
it
will
exchange
it
and
issue
you
another
token
for
the
new
API
that
you
want
to
call
and
as
always,
you
would
need
to
provide
the
Scopes
for
that
API
in
this
configuration,
when
you
are
configuring,
the
on
behalf
of
lu
hope,
that's
helpful.
All.