Observe the state of the AZA protocol interop. AZA leverages OpenID Connect to provide a standards-based approach for SSO to multiple native applications.
2. Mo#va#on
• Enterprise
employees
use
mul#ple
applica#ons
(combo
of
web
&
na#ve)
in
their
jobs
• Applica#ons
both
hosted
on-‐prem
&
SaaS
• Current
reality
is
that
an
SSO
experience
limited
to
the
browser
apps
• But
na#ve
applica#ons
becoming
more
and
more
prevalent
• Poten#ally
significant
usability
burden
for
employees
3. Default
OAuth
paNern
for
na#ve
applica#ons
• Employee
authen#ca#on/authorizes
each
applica#on
individually
• Authoriza#on
manifested
as
the
issuance
of
an
OAuth
token
to
each
na#ve
app
–
this
presented
on
subsequent
API
calls
to
corresponding
server
• Employee
interacts
with
each
OAuth
AS
(corresponding
to
each
API)
to
obtain
an
OAuth
token
4. Implica#ons
of
default
paNern
• Employee
bears
burden
of
authen#ca#ng/
authorizing
each
na#ve
applica#on
separately
• Even
if
done
infrequently,
may
be
unacceptable
• Each
SaaS
must
directly
support
OAuth
(running
an
Authoriza#on
Server)
• Enterprise
distanced
from
employee's
use
of
na#ve
applica#ons
5. Na#ve
App
SSO
Alterna#ve
• An
employee
is
able
to
collec#vely
authorize
each
na#ve
applica#on
on
device
in
one
step
• Rather
than
each
applica#on
individually
obtaining
OAuth
tokens
for
itself
the
tokens
are
obtained
on
behalf
of
those
na#ve
applica#ons
by
a
dedicated
'authoriza#on
agent'
(AZA)
• Employee
authorizes
the
AZA,
which
then
proceeds
to
obtain
for
other
applica#ons
the
necessary
access
tokens
• Once
handed
the
tokens,
na#ve
applica#ons
use
them
as
normal
on
API
calls
• For
user,
enables
an
SSO
experience
for
na#ve
applica#ons
6. AZA
Alterna#ve
6
Enterprise
SaaS
Device
Browser
Na#ve
SaaS
SaaS2
Na#ve
SaaS2
AS
AS
Client
Client
AZA
7. AZA
Alterna#ve
7
Enterprise
SaaS
Device
Browser
Na#ve
SaaS
SaaS2
Na#ve
SaaS2
AS
AS
Client
Client
AZA
AS
10. Implica#ons
1. Na#ve
apps
must
be
able
to
request
access
tokens
of
a
local
AZA
2. AZA
must
be
able
to
request
access
tokens
on
behalf
of
another
na#ve
applica#on
3. AZA
must
be
able
to
hand
over
access
tokens
to
na#ve
applica#on
4. RS
must
be
able
to
validate
access
tokens
(poten#ally
issued
by
a
remote
AS)
10
11. Standardiza#on
• Mul#ple
pieces
(from
different
providers)
implies
need
for
standards
• A
number
of
industry
players
working
to
profile/extend
OpenID
Connect
for
the
AZA<-‐
>AS
interac#on
– New
WG
being
formed
in
OpenID
Founda#on
• Related
but
separate
effort
to
standardize
App<-‐>
AZA
messaging
emerging
12. Interoperability
• We
are
demonstra#ng
interoperability
between
different
AZAs,
OAuth
ASs,
na#ve
applica#ons,
and
OAuth
RSs
• The
AZA<-‐>AS
protocol
is
based
on
OAuth
(not
the
eventual
OIDC-‐based
standard)
• MobileIron
&
Ping
also
implemented
a
back-‐
channel
authoriza#on
query
interface
12